1. Phải chắc chắn rằng ticket type phải được chọn là "Bug" :

 Yêu cầu này là để có thể dễ dàng filter tìm kiếm và trích xuất ra danh sách các bug mà không lẫn với các loại Task khác.

2. Ticket Name phải được chú trọng:

       Việc tìm kiếm một bug khi dự án đã vận hành trong thời gian dài sẽ gây tốn rất nhiều effort và khó chịu. Bởi vậy hãy áp dụng các phương pháp sau đây để giúp tìm kiếm một bug cụ thể dễ dàng hơn:

3. Ticket Name cần ngắn gọn, dễ hiểu và bao gồm các từ khóa:

• Ticket Name cần phải là một câu hoàn chỉnh nêu lên vấn đề phát sinh và điều kiện phát sinh vấn đề đó (nếu đã xác định được).

Ticket Name cần phải bao gồm các từ khóa quan trọng và dễ nhớ.

 

4. Expected Result  phải hợp lý:

• Expected Result là kết quả được mong chờ của một hành động hoặc tổ hợp hành động được thực hiện trên sản phẩm. Kết quả mong chờ này chủ yếu dựa trên Requirement của khách hàng. Tuy nhiên khi Requirement không đủ chi tiết hay thiếu rõ ràng, thiếu hợp lý thì QA cần phải dựa trên quan điểm người dùng (common senses) để đánh giá và xác định một mức phản hồi chấp nhận được (compromise) mà khách hàng không phản đối và dev cũng cảm thấy đồng tình.

 

5. Actual Result phải  mô tả chi tiết:

• Tốt nhất, Actual Result nên được viết lại dựa trên mẫu câu của Expected Result để người đọc dễ dàng phân biệt chúng với nhau.

6. Môi trường nên liệt kê đầy đủ:

       Hardware: Bug được tái hiện trên những hệ máy nào (laptop/mobile)? Bug xảy ra                                            trên kích cỡ màn hình bao nhiêu (? x ?)?

 

• Software: Bug đã được tái hiện trên hệ điều hành nào? (Windows/Ubuntu/OSX/Android/iOS)? Bug xảy ra trên trình duyệt cụ thể nào không (Chrome/Firefox/Safari/IE)?

 

7. Precondition không kém phần quan trọng:

• Trước khi bug xảy ra thì bạn đang ở màn hình nào?

• Khi bug xảy ra thì bạn đã đăng nhập theo roll account nào (member/admin/…)?

• Bạn đang sử dụng chức năng nào dưới nền thì bug xảy ra (chạy video/music/…)?

• Bug chỉ xảy ra khi có những điều kiện gì thỏa mãn (một lỗi khác xảy ra trước/chuyển màn hình theo một trình tự cụ thể/sự thay đổi về phần cứng hay config thiết bị/…)?

8. Reproduction Steps là các bước chi tiết để tái hiện bug:

• Hãy đảm bảo rằng các bước thực hiện phải chi tiết, chính xác, ngắn gọn, đầy đủ thông tin (có thể kèm theo loại thiết bị gây lỗi, account xảy ra lỗi, tên của test data,…)

• Các bước thực hiện nên cover toàn bộ quá trình tái hiện bug, bao gồm cả các bước tái tạo Precondition

• Cần confirm kết quả của từng bước (OK/NG) kèm theo những biểu hiện khác mà bạn cho là quan trọng (nếu có)
   

 

10. Remarks chỉ ra những biểu hiện lỗi tương tự:

         Trong một hệ thống phát triển phần mềm chuyên nghiệp thì kĩ năng reuse code là bắt buộc, cũng bởi thế mà một đoạn code lỗi có thể gây ra bug ở nhiều nơi khác nhau. Remarks là nơi để Tester ghih chú lại những màn hình có biểu hiện bug tương tự, giống một phần hoặc toàn bộ, và những biểu hiện bất đồng nhất giữa các môi trường khác nhau.
Ví dụ:

• Bug also occurs on Template List, Image Set List and Profile page.

• Bug occurs on all browsers accept Chrome.

11. Version là phiên bản sản phẩm mà bug được phát hiện:

• Việc ghi chú lại phiên bản sản phẩm mà bug được phát hiện sẽ giúp người quản lí xác định được quá trình tiến hóa của sản phẩm.

• Kèm với việc đánh dấu lại phiên bản mà bug được fix sẽ giúp đơn giản hóa việc theo dõi nếu như có Degrade bug xảy ra.

* Sau đây là 1 ví dụ về logbug của dự án FAFU

http://dev.deha.vn:8082/T4314

Ghi chú thêm:

1. Trên đây là Template lý tưởng mà một Bug Ticket nên được viết. Tất nhiên, trong mô hình thuần Agile với số lượng team member nhỏ hơn thì có thể đơn giản hóa hoặc thu gọn lại.

2. QA/Tester nên có sự trao đổi, hội ý với các dev để tìm hiểu thêm về bug và thống nhất ý kiến về giải pháp trước khi log bug.

3. Bug Ticket cần được assigned cho Dev hoặc PM sau khi được tạo ra. QA hoặc PM sẽ quyết định xem bug được add thẳng vào Sprint hiện tại hoặc được đặt trong Backlog tùy vào độ ưu tiên và tính nghiêm trọng.

4. Dev cần chuyển status của Bug Ticket từ TO DO sang PROGRESSING sau khi bắt đầu fix bug, và sẽ assign lại cho QA khi bản vá đã được approved/merged/deployed.

5. QA sau khi confirm bản vá của bug sẽ phải ghi chú lại version mà Bug được fixed và chuyển Bug Ticket thành DONE. Nếu bản vá chưa xử lí triệt để được Bug, QA có thể assign lại Bug Ticket cho Dev.