Đối với một tester, việc log bug là một công việc diễn ra thường xuyên và log bug cũng là phương thức giao tiếp cùng dev về chức năng, ứng dụng, sản phẩm đang phát triển chung. Ngoài ra danh sách bug được tạo ra cũng là một cách thức để quản lý chất lượng của các chức năng, ứng dụng, sản phẩm. Chính vì vậy, làm sao để nâng cao kỹ năng log bug cũng là một điều rất quan trọng mà mọi tester cần quan tâm đến.

I. Nguyên nhân bug bị từ chối và giải pháp:

1. Hiểu sai yêu cầu:

Vì một lý do bất kỳ nào đó, tester đã không hiểu đúng yêu cầu, chắc chắn rằng khi tester không thể chứng minh được bug đó nằm trong yêu cầu thì bug đó sẽ bị từ chối. Giải pháp: Không có giải pháp nào là hoàn hảo trong trường hợp này ngoại trừ chính bạn. Nắm thật chắc yêu cầu và luôn đứng trên phương diện người dùng để đưa ra cách xử lý hợp lý nhất.

2. Quá trình thực hiện yêu cầu:

Khi tester đã biết yêu cầu cụ thể trước đó sẽ được thực hiện theo cách XYZ. Nhưng trong khi phát triển, dev thấy rằng không thể thực hiện theo cách XYZ ban đầu và cần phải thực hiện thành ABC nhưng điều đó chưa được truyền đạt tới tester. Do đó, khi tester nhận thấy yêu cầu đã không được thực hiện đúng và log bug theo yêu cầu cũ. Những bug như vậy cũng sẽ bị từ chối. Giải pháp: Luôn trao đổi về các chức năng đang phát triển cùng dev và các bên liên quan để luôn nhận được yêu cầu mới nhất.

3. Không có yêu cầu rõ ràng:

Đối với những chức năng, ứng dụng, sản phẩm mà yêu cầu không được làm rõ, mọi người đều tự do chấp nhận yêu cầu theo cách riêng của mỗi người và điều này dẫn đến những giả định cá nhân khác biệt. Khi tester thấy không hài lòng với kết quả nhận được và thực hiện log bug đó thì kết quả là bug đó cũng sẽ bị từ chối. Giải pháp:

• Làm theo chức năng tương tự đã có trong hệ thống trước đó.
• Thảo luận cùng dev và đứng trên phương diện người dùng để đưa ra giả định sát nhất
• Nếu không thể thảo luận cùng nhau thì có thể gửi khách hàng xác nhận lựa chọn nào trong các lựa chọn đó là điều họ mong muốn

4. Thay đổi yêu cầu:

Khi tester không được thông báo về những thay đổi trong yêu cầu, nhiều bug sẽ được log và cuối cùng bị từ chối. Giải pháp: Trước khi thực hiện test một chức năng nào, nên đọc lại các yêu cầu, các QnA và trao đổi được lưu lại liên quan đến chức năng đó.

5. Hiểu về phạm vi:

Trong khi kiểm thử, tester bắt đầu kiểm thử một cái gì đó không được coi là có thể kiểm chứng được tại thời điểm cụ thể hoặc không nằm trong tiêu chuẩn của sản phẩm. Những bug kiểu này cũng sẽ bị từ chối. Giải pháp:

• Nắm rõ yêu cầu để đưa ra được phạm vi phù hợp
• Đứng trên phương diện người dùng để thao tác

6. Môi trường kiểm thử:

Một ứng dụng hay một sản phẩm là một sự kết hợp của nhiều yêu cầu phần cứng và phần mềm lớn và nhỏ. Khi môi trường kiểm thử không thích hợp hoặc bị thiếu hụt, sẽ xảy ra bug. Sau khi được điều tra kỹ hơn và nguyên nhân là do vô ý quên một vài chi tiết nhỏ trong môi trường kiểm thử thì những bug này cũng sẽ bị từ chối. Giải pháp:

• Tạo checklist tương ứng về môi trường cho các ứng dụng và sản phẩm
• Chắc chắn đã thiết lập đầy đủ và đúng môi trường trước khi thực hiện kiểm thử

7. Dữ liệu kiểm thử ( test data ) được sử dụng:

Dữ liệu kiểm thử được sử dụng để kiểm thử không phù hợp với yêu cầu. Giải pháp: Trước khi log bug nên chắc chắn đã sử dụng đúng dữ liệu kiểm thử

8. Bug trùng lặp:

Bug đã được tester nào đó log, tuy nhiên do chưa kiểm tra lại nên tester khác thực hiện log thêm. Những bug trùng lặp cũng sẽ bị từ chối. Giải pháp:

• Title của bug nên log kèm [Prefix] là tên của chức năng hoặc mã chức năng
• Thảo luận cùng tester khác hoặc tự check lại danh sách bug thông qua [Prefix]

9. Mô tả bug không đúng:

Khi dev không thể hiểu, không thể tái hiện được bug vì nội dung bug đã không được mô tả chính xác và yêu cầu chi tiết không được làm rõ. Những bug như vậy cũng sẽ bị từ chối. Giải pháp:

• Mô tả bug dưới dạng step by step
• Mô tả rõ ràng giữa hiện trạng (Actual) và mong muốn (Expected)
• Mô tả rõ Precondtion, môi trường, tần suất

10. Các bug không thể tái hiện lại được:

Trong khi log bug, tester đã không chú ý đến tần suất của bug để đảm bảo xem bug đó là lặp đi lặp lại hay chỉ xuất hiện một cách ngẫu nhiên. Với những bug xảy ra ngẫu nhiên thì tần suất tái hiện rất thấp và những bug như vậy, khi không thể tái hiện sẽ bị từ chối. Giải pháp: Trong mô tả bug cần nêu rõ tần suất (những bug có tần suất thấp sẽ được ưu tiên thấp )

II. Gợi ý nội dung bug nên có:

Một bug đủ tốt để giảm thiểu việc bị từ chối, nên bao gồm:

Subject [Prefix 1][Prefix 2] Mô tả ngắn gọn nội dung bug ( Với [Prefix 1]: Mã chức năng hoặc tên chức năng [Prefix 2]: Môi trường cụ thể [iOS] hoặc [Android] hoặc [Chrome] hoặc [IE] ... )

Description: [Preconditon] (Điều kiện tiền đề trước khi thực hiện ) [Step] (Dạng step by step) [Actual result] ( Mô tả chính xác hiện trạng đang gặp ) [Expected result] ( Mô tả rõ ràng mong muốn cụ thể ) [Test Enviroment] ( Môi trường xảy ra bug ) [Frequency] ( Tần suất xảy ra bug ) [Test Data] ( Dữ liệu đã sử dụng (nếu có) )

Status: ( New / ReOpen ) Related task: ( Thông tin về chức năng liên quan ) Assignee: ( Người cần xử lý ) Priority: ( Độ ưu tiên Low / Normal / High / Urgent / Immediate )

Nguồn tham khảo: http://www.softwaretestinghelp.com/why-your-bugs-are-getting-rejected/