Log bug là công việc cơ bản và thường xuyên của một Tester/QA engineer, cơ bản và thường xuyên đến nỗi mà nó lại là việc ít được dành đủ sự quan tâm nhất. Các khóa học về Testing/ Quality Assurance hầu như chỉ đề cập tới hành động và tần suất của việc log bug chứ không nêu ra những yêu cầu khắt khe về quy trình và chất lượng của bug được log. Các yêu cầu này, tùy vào mô hình phát triển phần mềm và tiêu chuẩn chất lượng ở các tổ chức khác nhau lại khác nhau và có vẻ như đối với một số tổ chức ứng dụng Agile thì các yêu cầu này bị bỏ qua hoặc xem nhẹ.
Là một kĩ sư phần mềm (Software Engineer) được học bài bản về Quality Assurance và đã có thời gian làm việc trong cả mô hình Waterfall lẫn Agile, tôi có học hỏi và rút cho mình được một số kinh nghiệm mà nếu áp dụng một cách linh hoạt và thuần thục thì sẽ tăng cao tính chuyên nghiệp cho dự án, khiến cho việc quản lí dự án dễ dàng hơn và tạo điều kiện tốt hơn để hỗ trợ cho các Developers trong việc fix bug.
Hầu hết các dự án Agile đều sử dụng một vài hệ thống quản lý thông dụng như Redmine hoặc Jira, bởi vậy ở đây tôi sẽ lấy Jira làm chuẩn để triển khai các yêu cầu trong việc Log bug.
Dưới đây là một template lý tưởng cho một bug ticket được tạo mới trên Jira:
Summary
• <content>
Expected result
• <content>
Actual result
• <content>
Environment
• Hardware: <content>
• Software: <content>
Precondition
• <content>
Reproduction Steps
• Step 1: <content> => Result of Step 1 <OK/NG> <further note>
• Step 2: <content> => Result of Step 2 <OK/NG> <further note>
...
• Step n: <content> => Result of Step n <OK/NG> <further note>
Recover action
• <content>
Remarks
• <content>
Version
• <content>
Log bug như thế nào cho đúng?
1. Hãy chắc chắn rằng ticket type phải được chọn là "Bug" hoặc "Defect
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:
2.1 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ớ. Ví dụ như nếu tôi muốn tìm một Bug về việc hình ảnh không được phóng to hết cỡ trong khung trình chiếu, tôi chỉ cần gõ từ khóa "stretch" hoặc "zoom" vào ô Searchbox của Jira và Ticket sẽ được lọc ra. Thật dễ dàng phải không nào?
2.2 Đính kèm Tags trong Ticket Name
Việc phân biệt các bug bằng Tags là cách là cổ điển nhưng rất hiệu quả. Trước khi log bug, hãy chú ý xem xét xem bug đó là bug [LOGIC] hay bug [GUI], bug [FRONTEND] hay [BACKEND], bug của [WEB] hay [ANDROID] hay [IOS] app. Tùy đặc thù dự án, bạn hãy chọn các Tags phù hợp. VIệc đặt các Tags lên đầu của Ticket name sẽ rất hữu ích trong việc sắp xếp và tìm kiếm, cũng dễ dàng hơn cho PM phân công Task cho các Developers.
Ví dụ: QA log một bug với tên là "[UPLOAD FILE] [LOGIC] [FRONTEND] [WEB] Cannot complete uploading a file while 2 tabs are openned" sẽ giúp PM dễ dàng hiểu rằng đây là bug của function Upload trên Webapp, do config của Frontend và là lỗi logic nên cần một frontend Dev có kĩ năng code logic tốt xử lí.\
3. Summary không nên bị bỏ qua
Dù phần này không có nhiều giá trị trong thực tế sử dụng của dev, nhưng lại rất có giá trị đối với QA và PM khi mà số lượng bug của dự án trở nên quá nhiều hoặc khi có nhiều hơn một QA tham gia test. Việc tóm tắt nội dung bug một cách dễ hình dung trong khoảng 1-3 dòng sẽ giúp cho việc duyệt, lọc và tìm kiếm bug trở nên dễ dàng hơn rất nhiều, trách trường hợp trùng lặp bug hoặc dev không hình dung được bug.
4. Expected Result cần 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.
- Expected Result trong bug ticket cần được viết rõ, chi tiết, gãy gọn. Expected Result của cùng một tổ hợp hành động trên các màn hình khác nhau cần được ghi chú rõ ràng tránh nhầm lẫn.
5. Actual Result cần được 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.
Ví dụ:
(Expected) Button should return to normal after uploading is done.(Actual) Button does not return to normal after uploading is done
- Các Actual Result trên các màn hình khác nhau cũng cần được tách ra và ghi chú riêng rẽ.
6. Environment cần được 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ó)
Ví dụ:
(1) Input "abcxyz@gmail.com" to email textbox => OK. "abcxyz@gmail.com" is displayed on email textbox.
(1) Input into password textbox as blank => OK.
(2) Click on [Log In] button => NG. No error message is displayed.
9. Recover Actions là đầu mối quan trọng
Recover Actions là những hành động để khôi phục trạng thái hoạt động bình thường của sản phẩm hoặc làm bug biến mất tạm thời. Việc điều tra ra Recover Actions không phải luôn luôn cần thiết nhưng đối với những hệ thống phức tạp thì lại là manh mối quan trọng để tìm hiểu nguyên nhân gốc rễ và cách khắc phục bug.
Việc dành thời gian điều tra Recover Actions cũng cho thấy Tester đầu tư nhiều thời gian và cẩn trọng trong việc log bug.
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.
Ghi chú thêm:
- 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.
- 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.
- 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.
- 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.
- 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.
Via viblo
