1) Bug report là gì ?

Để giải thích được câu hỏi đó, bạn cần hiểu được ý nghĩa của Bug, Bug report và Bug Reporting Software.

Vậy Bug là gì?

Trích từ wikipedia: “A software bug is an error, flaw, failure, or fault in a computer program or system that causes it to produce an incorrect or unexpected result or to behave in unintended ways.”

Hay ngắn gọn lại: "Software Bug là những sai lầm, hỏng hóc, lỗi, khiếm khuyết để tạo ra một kết quả sai, hoặc không lường đến được."

Theo lý thuyết, có thể coi nó như một thứ gì đó không hoạt động đúng theo thiết kế.

Vậy nếu giả sử cái phát sinh đó đó vốn dĩ không hề có trong thiết kế, vậy nó có phải là Bug? Đây chính là điều khiến người ta có khoảng trống để diễn giải nó theo nhiều cách, và phần lớn mâu thuẫn giữa dev và tester đều xuất phát từ vấn đề này.

Bug report là gì?

Giả sử 1 bug xuất hiện (tất nhiên là nó sẽ xuất hiện) người tìm ra Bug phải có thể report nó (bằng văn bản và gửi) cho người có liên quan để sửa lỗi đó.

Theo Yegor: Bug report nên giải thích được sản phẩm của bạn hỏng hóc chính xác là ở chỗ nào. Ông nói thêm rằng Bug report nên theo một quy luật tối giản như sau: "Nó như thế này, nó ĐÚNG RA phải hoạt động như thế khác. Fix đi." Nghe có vẻ đơn giản nhỉ, nhưng thực tế thì mọi sự lại không diễn ra suôn sẻ như vậy.

Tưởng tượng rằng bạn gặp phải 1 bug và muốn send bug report. Bạn sẽ trình bày những thông tin gì? Hầu như mỗi người đều có một câu trả lời của riêng mình, 9 người 10 ý.

2) Tại sao cần một bug report chuẩn?

Nếu bug report hiệu quả, tỉ lệ được fix của nó sẽ cao hơn. Việc fix bug phụ thuộc vào việc bạn report nó có hiệu quả hay không. Nó là một nghệ thuật, và bài viết này hướng dẫn bạn làm sao để trở thành một nghệ sỹ. “The point of writing problem report(bug report) is to get bugs fixed” – Cem Kaner.

Khi tester report bug không chính xác, dev có thể reject bug vì không thể tái hiện (reprod ) được bug. Điều này ảnh hưởng đến tự tin và cái tôi của tester (Và theo như mình thì tốt nhất là đừng có cái tôi nào hết. Kiểu bào chữa như "Tao report đúng mà", "Tao làm lại được mà", "Sao nó reject bug của mình", "Không phải lỗi của mình" ..v..v.. là rất có hại cho bản thân bạn và cần tránh)

3) Điều gì quyết định một bug report tốt?

Bạn sẽ thắc mắc rằng điều gì khiến cho một bug report tốt, và điều gì làm nó dở. Và tại sao cái dở lại nhiều hơn cái tốt?

Dưới đây mình sẽ liệt kê ra một số phát biểu về vấn đề này để tách biệt giữa một bug report tốt, và một bug report tệ:

• Bug report tốt chứa đủ thông tin để reprod và sửa lỗi.
• Bug report tệ không chứa đủ thông tin để reprod và sửa lỗi.
• Bug report tốt là một cách hữu hiệu để liên lạc giữa người report bug và người sửa bug.
• Bug report tệ thường quá dài, và là phương tiện thiếu hữu hiệu để liên lạc giữa những người liên quan.
• Bug report tốt được sửa nhanh.
• Bug report tệ không bảo giờ được fix.
• Bug report tốt được gửi đến đúng người chịu trách nhiệm.
• Bug report tệ thì chẳng gửi ai, hoặc gửi nhầm người.
• Bug report tốt mô tả đúng thứ gì cần sửa.
• Bug report tệ không chứa đủ thông tin chi tiết.
• Bug report tốt được gửi theo đúng cách.
• Bug report tệ gửi theo đủ cách, nhưng không đúng (qua facebook hay mail chẳng hạn)
• Bug report tốt tạo nên được tiền đề để phối hợp.
• Bug report tệ sẽ khiến người ta không chịu hợp tác.

Sau khi đọc xong bạn có thể biết được report của bạn tệ hay tốt rồi. Vậy làm sao để viết một bug report tốt?

I) Title rõ ràng

Khi dev đọc bug, thứ đầu tiên đập vào mắt là Bug title. Nó cũng là phần được đọc nhiều nhất, không phải là description. Một bug title tốt phải ngắn gọn và diễn tả được bug một cách tối giản. Ví dụ: Title kém : Notes don't display correctly Không chi tiết. Trong vòng 1 tháng sẽ không thể nhận ra được vấn đề đến từ đâu Title tốt : Text is truncated for 32nd and 64th notes So với title trước, title này cải thiện rất nhiều. Nó chỉ ra được vấn đề gặp phải và nơi xuất hiện của bug.

II) Có thể Reprod:

Nếu bug của bạn không thể reprod, nó sẽ không bao giờ được fix. Ghi rõ từng step. Không nhảy cóc, không tiết kiệm dòng. Nếu bạn hình dung là mình viết để cho một thằng nhỏ 5 tuổi cũng có thể tìm được bug, tức là bạn đã đi đúng hướng.

III) Be Specific:

Không viết luận trong description. Ngắn gọn và vào trọng tâm. Cố gắng viết ít chữ nhất có thể nhưng vẫn đầy đủ ý. Khi có 2 vấn đề trong cùng 1 step giống nhau, hãy tách ra 2 bug report. Khi có cùng 1 vấn đề trong 2 step khác nhau, hãy tách ra 2 bug report.

4)Format của một bug report tốt.

Đây là một format đơn giản của bug report. Tuỳ thuộc vào tool bạn đang dùng. Nếu bạn viết bug thủ công (excel...) thì có một số trường cần quan tâm đặc biệt, ví dụ như BUG ID hoặc priority.

Reporter: Tên và email của bạn Product: Tên của Application Under Test (AUT) Version: Version đang test. **Component:**Module lớn của app. Platform: Mô tả nền tảng bạn dùng để chạy sản phẩm. Vd: Android, PC ..v...v Operating system: Mô tả hệ điều hành bạn dùng để test sản phẩm. Vd: Windows 10, Android 4.4.2....v..v. Priority: Bug nên được fix khi nào? Thường thì sẽ được set từ P.1 tới P.5 trong đó P.1 là "Fix càng sớm càng tốt" và P.5 là "Cho vào backlog" Severity: Types of Severity: Blocker: Không thể tiếp tục test. Critical: App crash, mất data. Major: Lỗi chức năng nghiêm trọng. Minor: Lỗi chức năng nhỏ. Trivial: Lỗi UI, lỗi alignment..v..v. Enhancement: Request để thêm feature mới hoặc cải thiện feature có sẵn. Status: Khi mới được log in hệ thống, bug sẽ ở trạng thái new và tuỳ trường hợp mà thành Verified, Fixed, Won't Fix, Reopen..v..v. Cái này sẽ nói rõ hơn vào bài khác. Assign To: Người nhận trách nhiệm fix bug của bạn. Ở nhiều cty trường này được để trống để PM tự assign người. URL: URL xảy ra bug. Summary: Giới hạn trong 60 từ. Mô tả bug ở đâu và bug xảy ra thế nào. Description: Description của bug. Ở đây ta có thể dùng cách viết sau. Reproduce steps: Mô tả rõ ràng các bước để xảy ra bug. Tuyệt đối không giả dụ, không bỏ step. Cứ nghĩ là bạn đang viết cho một đứa nhỏ 5 tuổi đọc và tìm bug. Expected result: Chúng ta trông đợi cái gì. Actual result: Và chúng ta nhận được gì (I.E đây là bug)

Trên đây là những step quan trọng cần có trong 1 bug report. Bạn cũng có thể thêm trường Bug Type để mô tả dạng bug report.

Thường là:

1. Lỗi Coding
2. Lỗi Design
3. New suggestion
4. Documentation issue
5. Hardware problem

5) Kết luận

Bug report là một phần rất quan trọng và không thể thiếu trong khi thực hiện testing. Một Bug report được viết rõ ràng và rành mạch, sẽ luôn gây ấn tượng và hiệu ứng tốt hơn đối với một bug report sơ xài và cẩu thả. Làm cho người fix bug đó và cả người confirm lại bug đó không có cảm giác khó chịu khi phải đọc một bug report sơ xài. Hy vọng bài viết đã cung cấp được một số những khái niệm cơ bản và một vài gợi ý cho các bạn để các bạn có thể viết những bug reports tốt.

Nguồn: Usersnap & Softwaretestinghelp