Làm thế nào để viết bug dễ hiểu và hiệu quả

Bài viết được sự cho phép của tác giả To Thi Van Anh

Log bug là một công việc quan trọng và không thể tránh được trong kiểm thử phần mềm, một bug được log tốt, giúp cho người đọc có thể dễ dàng nhìn ra được vấn đề, không phải mất nhiều thời gian để tìm hiểu và trao đổi qua lại quá nhiều lần, bên cạnh đó cũng là để phòng ngừa và phát hiện những vấn đề nghiêm trọng xảy ra, liên quan và ảnh hưởng trực tiếp đến chất lượng sản phẩm phần mềm.

Về mặt lý thuyết, có lẽ các bạn đều biết được rằng bug đưa lên thì cần phải ngắn gọn súc tích nhưng vẫn phải đảm bảo cung cấp đủ các thông tin cần thiết. Ô mà như thế nào là ngắn gọn mà vẫn đầy đủ thông tin? Haha, mời các bạn bớt chút thời gian đọc tiếp nha!

Yếu tố tâm lý: Đóng góp – đừng ra lệnh

Khi test mà bắt được con bug nào, tester vui mừng bao nhiêu thì Dev buồn bấy nhiêu. :)) Vì thế hãy luôn mang một tinh thần và mục tiêu là cùng đóng góp để xây dựng một sản phẩm chất lượng, đừng gay gắt ra lệnh, nó dễ làm ảnh hưởng đến tâm lý người nhận và dễ gây căng thẳng giữa hai bên.

Đừng log trùng bug

Một vấn đề khác, đó là việc log bug bị trùng, nguyên nhân thì do chủ quan hay khách quan đều có, nhưng dù là gì đi nữa thì bạn cũng nên hạn chế thấp nhất vấn đề này, một vài lần xảy ra sẽ khiến dev “mất niềm tin” ở bạn ngay. Vì vậy, cần kiểm tra và lọc kỹ thông tin trước khi log bug, một vài chục bug ta có thể nhớ được chứ khi đã lên đến hàng trăm thì không thể chủ quan được!

Xem thêm các việc làm tuyển dụng Tester hấp dẫn tại TopDev

Cung cấp thông tin chi tiết, đầy đủ: What, How, When.

Điểm quan trọng nữa đối với việc log bug, đó là bạn phải cung cấp được thông tin liên quan đến bug đó như là điều gì đã xảy ra, nó đã xảy ra như thế nào nào? ở đâu, khi nào?

Ví dụ: bug này xảy ra khi bạn đã thực hiện các bước với test data như thế nào, và bạn đã thực hiện nó ở phần chức năng nào của hệ thống. Để từ đó người đọc sẽ hình dung, dễ dàng tái hiện và tìm bug theo mô tả này của bạn hơn.

Mỗi bug nên tập trung vào một vấn đề thôi

Trong một bug bạn chỉ nên tập trung vào một vấn đề cụ thể mà bạn gặp đó thôi, đừng nghĩ là mất công log một bug này nên là tranh thủ gom vài vấn đề vào chung luôn cho đỡ phải log tiếp, như vậy làm cho các vấn đề trở nên rắc rối, khó nắm bắt, nhiều khi bị lan man mất nhiều thời gian để có thể giải quyết và close được bug.

Một vài lưu ý lớn

Mỗi công ty/đội dự án lại có các cách quản lý bug khác nhau, các biểu mẫu và cách báo cáo khác nhau. Nhưng nhìn chung thì log bug chúng ta cũng đều phải đảm bảo và lưu ý một số yếu tố dưới đây:

1. Bug id: Yếu tố này giúp việc quản lý, tìm kiếm dễ dàng và nhanh chóng hơn. Đặc biệt đối với project mà số lượng bug trở nên quá lớn qua các build version.

2. Tiêu đề của bug: Đây sẽ là phần mà thường là ta sẽ đọc đầu tiên trước khi mở bug đó ra và đọc tiếp các mô tả bên trong, do đó phần này nên mô tả một cách khái quát nhất, đủ để người đọc có thể hình dung ra được vấn đề nhanh nhất có thể. Giúp người đọc có thể hiểu được và biết được là bug đã được fix hay đã gặp lần nào bao giờ chưa.

3. Mức độ nghiêm trọng của bug: Khi bug xảy ra, bạn có thể đánh giá độ nghiêm trọng của lỗi để gán cho nó trạng thái tương ứng, các trạng thái này có thể là Critical, Major, Minor, … tùy từng hệ thống, thường thì sẽ dựa vào chỉ số này để ưu tiên các bug nào sẽ phải được/nên được fix trước.

4. Môi trường/Nền tảng/Device test: Ở đây ta cần phải đưa ra thông tin cụ thể việc xảy ra bug đó khi bạn test trên môi trường nào, sử dụng device test nào: ví dụ như test trên Window 7, Chrome latest version…. Hay iPhone 7, iOS 9…., vì đôi khi thì bug đó chỉ xảy ra ở một số môi trường đặc biệt nào đó thôi, việc cung cấp các thông tin này cũng giúp cho đội Dev có thêm thông tin để tìm được ra được các vấn đề.

5. Mô tả lỗi: Phần này cung cấp thông tin đầy đủ và chi tiết về lỗi đã xảy ra, giúp cho Dev hiểu hơn về vấn đề. Đưa ra các bước theo đúng tuần tự thực hiện để có thể tái hiện lỗi:

• Điều kiện đầu vào: Bao gồm các bước chuẩn bị, test data…
• Test steps: Các bước thực hiện, nên đánh số 1, 2, 3, …
• Kết quả mong đợi: Kết quả đúng cho case này là gì?
• Kết quả thực tế: Thực tế nó đã xảy ra như thế nào, cần mô tả rõ ràng và đầy đủ kết quả thực tế đã xảy ra nhé!

Bạn có thể sử dụng dấu ngoặc vuông [ ] để chỉ tên chức năng thực tế trên hệ thống để dễ Dev dễ hình dung nhé!

6. Tài kiệu đính kèm: “Một hình ảnh bằng hàng nghìn lời nói”, do đó bạn nên đính kèm theo mỗi bug các hình ảnh liên quan trực tiếp đến nó, có thể highlight vùng lỗi lên để người đọc dễ quan sát hơn, hoặc bạn cũng có thể quay một video các bước đã thực hiện, cách này sẽ giúp ích rất nhiều trong việc tái hiện và hiểu bug. Ngoài ra nếu bạn có thể lấy được các log file thì cũng có thể đính kèm lên cùng với bug, rồi các tài liệu tham khảo liên quan khác, nếu cần thiết.

Một lưu ý nữa là bạn cần đảm bảo là đã sử dụng bản build test và điều kiện phù hợp tương ứng với test cycle. Và nhớ đọc kỹ lại một lượt bug để đảm bảo không mắc các lỗi về diễn đạt hay chính tả nữa nha.

Kiểm tra kỹ hơn trên các máy test khác để đảm bảo là nó không phải chỉ gặp vấn đề ở mỗi máy của bạn thôi, còn trên máy của người khác vẫn không vấn đề gì. Rồi cũng phải đảm bảo là bug này có thể tái hiện lại được.

Khi log một bug cần luôn phải nhớ rằng mô tả cần ngắn gọn, rõ ràng, dễ hiểu, cung cấp đầy đủ thông tin cần thiết, để có thể dễ dàng tái hiện bug, tránh mất thời gian để trao đổi quá nhiều lần. Điều này giúp bạn có ấn tượng tốt trong mắt các bạn Dev, mặc dù biết là bạn log bug thì họ cũng không hề vui vẻ gì! Hehe

Bài viết gốc được đăng tải tại vananhtooo.wordpress.com

Có thể bạn quan tâm:

• Kỹ năng debug cơ bản
• Làm thế nào để Test Jersey Rest API với JUnit?
• Chuẩn bị gì khi phỏng vấn vị trí kỹ sư kiểm thử phần mềm?

Xem thêm Việc làm Developer hấp dẫn trên TopDev