- What is the Bug?
- Là những sai lầm do con người tạo ra
- Là những hành vi của hệ thống không hoạt động đúng theo thiết kế hoặc không đáp ứng yêu cầu của người dùng
- The objectives of Report Bug
- “The point of writing problem report (bug report) is to get bugs fixed” – By Cem Kaner.
- Đánh giá tình trạng chất lượng sản phẩm và hoạt động đảm bảo chất lượng sản phẩm trong dự án.
- Một số vấn đề khi log Bug
- Bug ngôn từ không rõ ràng, không rõ nghĩa và dễ gây hiểu lầm.
- Bug đang không đầy đủ thông tin
- Thông tin Bug chưa chính xác:
- Bug không mô tả rõ điều kiện xảy ra lỗi => Không tái hiện được Bug
- Điền sai thông tin (Priority, Serverity) => Đánh giá sai mức độ chất lượng sản phẩm
=> Đa số việc log bug chỉ đang đáp ứng việc Fix bug chứ chưa đáp ứng cho việc quản lý Bug.
- Information in good bug
| Nội dung | Ý nghĩa | Điền khi nào? | Ai điền? | Điền như thế nào? |
| BugID | Để định danh một bug, không nhầm lẫn với bug khác | Khi tạo bug | Tester | ID phải là duy nhất. Thường các công cụ quản lý bug (Redmine, Jira,…) đều tự sinh ID bug nên chúng ta không phải điền |
| Subject | Khái quát vấn đề được nêu trong bug, thường xuyên được đọc nhất | Khi tạo bug | Tester | – Mô tả ngắn gọn vấn đề, vị trí xảy ra vấn đề và điều kiện xảy ra vấn đề- Nhấn mạnh vấn đề xảy raFormat: [Vị trí bug xảy ra] [Khái quát vấn đề] [Điều kiện xảy ra vấn đề]Nên: [Màn hình Login] User không bị lock khi đã login failed quá 5 lầnKhông nên: [Màn hình Login] khi đã login failed quá 5 lần, User vẫn không bị lock |
| Description/Step to produce | Mô tả cách thức tái hiện ra bug | Khi tạo bug | Tester | – Bao gồm 4 thành phần:+ Điều kiện tiền đề+ Các step tái hiện+ Kết quả thực tế+ Kết quả mong đợi+ Bản build- Cần bố cục rõ ràng, điền đầy đủ thông tin- Cần tái hiện lại khoảng 2-3 lần theo step đã define để đảm bảo rằng dev có thể dễ dàng tái hiện- Có thể gắn thêm test data (hình ảnh, video) để dễ dàng cho việc tái hiện |
| Environment | Môi trường mà bug xảy ra | Khi tạo bug | Tester | – Bao gồm 2 thành phần:+ Thông tin server test+ Thông tin về thiết bị test: Thiết bị, hệ điều hành, độ phân giải màn hình, browser,….- Cần bố cục rõ ràng, điền đầy đủ thông tin, thường phần này sẽ được viết cuối cùng trong mục Description |
| Evidence | Bằng chứng, lời giải thích trực quan về mô tả lỗi giúp developer dễ dàng hiều rõ hơn về lỗi | Khi tạo bug | Tester | – Đối với bug type = GUI thì nên đính kèm ảnh và highlight các khu vực cần chú ý, dẫn mắt người xem đến vùng bị lỗi- Đối với các bug phức tạp, có thể tạo video |
| Similar & Impact | Trên quan điểm của người kiểm thử, đưa ra các phán đoán về bug tương tự hoặc logic có thể bị ảnh hưởng từ việc fix bug này. | Khi tạo bug | Tester | – Liệt kê các trường hợp tương tự (đã kiểm chứng hoặc chưa) để developer lưu ý khi fix bug- Lưu ý các logic có thể bị ảnh hưởng- Thường viết luôn trong Description, bên dưới mục kết quả mong đợi |
| QC Activity | Giai đoạn phát hiện ra lỗi | Khi tạo bug | Người log bug (Tester, Developer, BA,…) | – Bao gồm các thành phần:+ Code review: Lỗi tìm ra bởi hoạt động review code của team.+ Unit Test: Lỗi tìm ra bởi hoạt động unit test của team+ Integration Test: Lỗi tìm ra bởi hoạt động integration test của team+ System Test: Lỗi tìm ra bởi hoạt động system test của team+ Document Review: Lỗi tài liệu tìm ra bởi hoạt động review của team+ Acceptance Review: Lỗi tìm ra bởi hoạt động review nghiệm thu sản phẩm từ khách hàng, hoặc người chịu trách nhiệm review nghiệm thu+ Acceptance Test: Lỗi tìm ra bởi hoạt động test nghiệm thu sản phẩm từ khách hàng, hoặc người chịu trách nhiệm test nghiệm thu.+ Other Test: Lỗi tìm ra bởi hoạt động test khác |
| Bug Type | Phân loại lỗi theo test type | Khi tạo bug | Tester | – Bao gồm các thành phần:+ GUI: Các bug về giao diện hiển thị+ Function: Các lỗi về logic của item, chức năng không hoạt động đúng như tài liệu yêu cầu mô tả+ Non-function: Các lỗi về liên quan đến các yêu cầu phi chức năng của hệ thống: performance, security,… |
| Is degrade? | Xác định xem bug có phải bị degrade bởi việc implement và fix bug khác để khoanh vùng phạm vi ảnh hưởng của lỗi tốt hơn | – Khi tạo bug- Sau khi điều tra bug | Tester, Developer | – Xác định kết quả test của test case ứng với bug trước đó rồi quyết định thông tin cần điền- Nếu không có test case ứng với bug, developer sẽ xác định bằng cách điều tra trong code |
| Reopen counter | Số lần bug được xác nhận chưa được sửa chưa triệt để sau khi được verify. Theo dõi hoạt động fix bug | Sau mỗi lần verify bug với kết quả NG | Tester | Mỗi lần verify bug mà kết quả bị NG thì +1 cho trường [Reopen Counter] (Đối với redmine) |
| Priority | Thứ tự ưu tiên của các lỗi mà dev cần fix, gắn liền với schedule của dự án | Khi tạo bug, cập nhật theo tình hình của dự án | Tester | – Mức độ ưu tiên mang tính chất chủ quan, phụ thuộc vào tình hình dự án thì sẽ phân loại độ ưu tiên cho các bug khác nhau, base theo severity, base theo thứ tự ưu tiên, mức độ quan trọng và tần suất sử dụng của chức năng, base theo tính chất khách hàng, base theo chiến lược phát triển của dự án,…- Bao gồm các thành phần theo thứ tự ưu tiên lớn đến bé:+ Immediately+ Urgent+ High+ Medium+ Low |
| Severity | Mức độ nghiêm trong của bug ảnh hưởng đối với hệ thống, doanh nghiệp, môi trường và cuộc sống của con người | Khi tạo bug | Tester | – Bao gồm các thành phần:+ Critical: Những lỗi nghiêm trọng khiến người dùng KHÔNG thể sử dụng được ứng dụng/hệ thống như hệ thống sập, dữ liệu bị mất, ứng dụng không cài đặt được…+ Major: Lỗi mà chức năng chính không đáp ứng yêu cầu sử dụng hoặc hoạt động sai khác với dự kiến. Lỗi giao diện sai khác quá nhiều so với design+ Medium: Sản phẩm hoặc ứng dụng hoạt động không đáp ứng tiêu chí nhất định hoặc vẫn còn bộc lộ một số hành vi không mong muốn, tuy nhiên các chức năng khác của hệ thống không bị ảnh hưởng.+ Minor: Lỗi không sai về mặt logic nhưng cần cải thiện để tăng tính tiện dụng, trải nghiệm tốt cho người dùng+ Suggestion: Đây thực chất không phải là lỗi. Tức là sản phẩm hoạt động bình thường theo đúng những gì hy vọng nhưng có thể bạn cho rằng nó gây bối rối hoặc không tuân theo chuẩn web/app…Optimize: – Là các bug cũ không thuộc các feature đang phát triển trong sprint- Là những requirement/case chưa được đề cập trong document |
| Function/Category | Phân nhóm bug theo chức năng/category | Khi tạo bug | Tester | – Phân nhóm bug theo category lớn- Ở đầu subject nên thêm prefix là tên chức năng/màn hình xảy ra lỗi |
| TCs of Bug | Bug được phát hiện ra từ bộ Test case đã tạo | Khi tạo bug | Tester | – Đánh dấu để có thể thống kê được có bao nhiêu bug không có test case tương ứng |
| Defect Origins | Nguồn gốc gây ra lỗi | Khi tạo bug, sau khi điều tra/phân tích bug | Tester | – Bao gồm các thành phần:+ Requirement: Requirement không rõ ràng, không đúng với yêu cầu của khách+ Design: Thiếu kế GUI sai yêu cầu+ Coding: Coding sai yêu cầu+ Testing: Các lỗi trong scope test mà bị lack sang phía khách hàng+ Deployment: Do quá trình deploy bản build bị lỗi+ Customer support:+ Other: Lỗi do các tác nhân khác như communicate, management,… |