Testing report là gì

Là một tester không có nghĩa là bạn luôn luôn cần phải tạo bug và tồng hợp tình hình testing để gửi tới các bên liên quan . Có hai loại test report chính :

• Bug report để report cho một bug xảy ra trên app bạn đang làm
• Test report để tóm tắt tình hình của app mà bạn đang làm.

I. Bug report

1. 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 đó. 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.

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

II. Testing report

Nếu là một tester giỏi và sau vài năm kinh nghiệm, bạn sẽ được mong đợi để viết một Test Report hiệu quả; một báo cáo thể hiện rõ nhất tình hình của app mà bạn đang làm. Một testing report tốt, bạn cần phải được xây dựng dựa trên các yếu tố sau:

1. Biết các đối tượng:

Biết ai sẽ là người nhận được và dựa vào các Test Report và những quyết định nào sẽ được thực hiện dựa trên nó, là rất quan trọng. QA leader cần những thông tin chi tiết về những gì đã được test và những gì đã được tìm thấy, bởi vì quản lý muốn xem tiến trình kiểm tra tổng thể. Một số thông tin chung còn lại là cho tất cả các loại Test Report nhưng các mẫu khác nhau được sử dụng cho các đối tượng khác nhau.

2. Cung cấp thông tin chi tiết nhưng không quá nhiều

Một số yếu tố đóng một ảnh hưởng trong các văn bản của Test Report. Như tôi đã nói, các chi tiết được cung cấp trong Test Report phụ thuộc vào người nhận và thông tin họ cần nhận được. Trong khi cung cấp thông tin chi tiết, chắc chắn rằng bạn không cung cấp quá nhiều chi tiết và những mục bạn chọn đều phải được xác minh và dễ hiểu.

3. Luôn luôn cung cấp đủ thông tin của các task đã hoàn thành hôm nay và lên plan cho ngày mai.

Một Test Report nên luôn luôn bao gồm hai điều chính: Nhiệm vụ thực hiện và nhiệm vụ phải làm. Vào lúc bắt đầu của một Test Report, khi bạn cung cấp các task done, người đọc report sẽ clear về báo cáo hơn. Ngoài ra, các task tương lai sẽ giúp các leader hay manager biết các nhiệm vụ và sẽ cung cấp cho họ một lựa chọn để thay đổi tasks ưu tiên, nếu cần thiết.

4. Luôn luôn chia sẻ road blocks

Test Report phải luôn luôn đề cập đến các road blocks, nếu có. Đó là một cách tốt cho người đọc (ở cấp độ nào) để có được sự rõ ràng về lý do tại sao các công việc không được hoàn thành và những vấn đề gì đang phải đối mặt. Các road blocks cho phép các thành viên khác giúp bạn. Road blocks cho phép bạn quay lại và cung cấp tài liệu tham khảo cũng như là vấn đề tại sao bạn không thể hoàn thành nhiệm vụ.

5. Đọc và sửa nó

Không bao giờ được vội vàng để gửi báo cáo. Bất cứ điều gì được viết nên đọc lại ít nhất một lần. Trong khi đọc và sửa, bạn có thể nhận ra:

• Bạn muốn truyền đạt cái gì khác hoặc một cách khác nhau.
• Bạn thêm một số điểm nhiều quá.
• Bạn có thể viết rằng đoạn như điểm nhấn để làm cho nó dễ dàng hơn để đọc và hiểu được.
• Bạn quên kiểm tra chính tả.
• Bạn đã không bao gồm tất cả những người yêu cầu trong danh sách email.
• Bạn đã được làm việc trên một số nhiệm vụ khác nữa.
• Bạn đã được cung cấp một bản cập nhật cho một số nhiệm vụ cũ.

6. Thực hành để làm cho nó tốt hơn

Luôn luôn cố gắng để làm cho các Test Report tốt hơn cho người đọc báo cáo của bạn. Tìm kiếm online để cho các mẫu tốt hơn, xem report khác với tư cách là khán giả, đọc báo cáo của người khác và tìm điểm tốt để bạn có thể bao gồm trong Test Report của bạn. Một báo cáo súc tích và ngắn gọn sẽ rất hữu ích cho người đọc báo cáo của bạn.

III. Kết luận

Như vậy, Test Report không phải là một tài liệu quá dài, bao gồm tất cả các mảnh thông tin và có định dạng cứng nhắc. Bởi vì các Test Report sẽ luôn luôn thay đổi theo những hiện thực mới nhất, sửa đổi và các yêu cầu. Trong khi viết một Test Report, xác định các độc giả, nhu cầu của họ và tiếp tục cập nhật cho đến khi bạn đạt được một giải pháp khả thi.

Ngoài ra, duy trì một kích thước báo cáo hợp lý bằng cách cung cấp các tài liệu tham khảo như kế hoạch kiểm tra và sử dụng một phụ lục để biết thông tin dài như lỗi.

Một Test Report chính xác, dễ đọc, ngắn, linh hoạt và hành động là con đường để đi!