Test xong mà kết quả chỉ nằm trong đầu tester thì với phần còn lại của dự án, coi như chưa test.

Report không phải nghi thức gửi mail cho lead. Nó đưa thông tin về tiến độ, chất lượng và risk tới người cần ra quyết định. Người đọc có thể là Test Lead, Project Manager, Product Owner, dev, khách hàng hoặc đội vận hành; mỗi người cần độ chi tiết khác nhau.

Progress report

Progress report trả lời: chúng ta đang ở đâu so với kế hoạch?

Một bản ngắn thường có:

Ví dụ:

Checkout regression — build rc.3

- Executed: 42/60 tests
- Result: 35 passed, 5 failed, 2 blocked
- Blocker: payment sandbox timeout, PAY-184
- Risk: chưa chạy được refund và duplicate callback
- Next: retest 3 fixes và tiếp tục 18 tests còn lại sau khi sandbox ổn định

Đừng báo 80% complete nếu không nói 80% của cái gì. Một case payment kéo hai tiếng và một case kiểm tra label kéo hai phút không có trọng lượng giống nhau, nên phần trăm chỉ là tín hiệu, không phải chân lý.

Tần suất report tùy nhịp dự án. Team đã nhìn dashboard realtime và nói chuyện trong Daily Scrum thì không nhất thiết bắt mọi người gửi thêm một email giống hệt vào cuối ngày. Report tồn tại để giảm mù thông tin, không phải tăng số kênh phải cập nhật.

Test completion report

Khi một test level, sprint, milestone hoặc release đi tới điểm kết thúc, report cần trả lời câu lớn hơn:

Với bằng chứng hiện có, sản phẩm đang ở trạng thái nào và còn risk gì nếu đi tiếp?

Nội dung thường gồm:

  1. Scope và test basis: feature, requirement, build, environment nào nằm trong báo cáo.
  2. Khoảng thời gian và effort: test diễn ra khi nào, ai hoặc hệ thống nào tham gia.
  3. Coverage: requirement, risk, platform hoặc configuration nào đã và chưa được cover.
  4. Execution result: số test planned, executed, passed, failed, blocked, skipped.
  5. Defect: defect còn mở theo severity/priority, defect đã fixed và retest.
  6. Deviation: phần nào khác Test Plan và vì sao.
  7. Residual risk: điều gì chưa test, failure nào được chấp nhận, limitation nào còn lại.
  8. Kết luận hoặc recommendation: release, hoãn, release có điều kiện hay cần thêm bằng chứng.

Đừng gọi execution rate là coverage

Hai con số này hay bị trộn:

Execution rate = executed tests / planned tests
Pass rate      = passed tests / executed tests

Chúng hữu ích, nhưng 60/60 executed không tự động nghĩa là requirement coverage 100%. Có thể team viết thiếu test cho một business rule ngay từ đầu.

Coverage phải nói rõ coverage của cái gì: requirement, risk, branch, browser, device hay test condition. Pass rate cũng không đại diện trực tiếp cho chất lượng; 99 case cosmetic pass và một case thanh toán fail vẫn là một build rất đáng lo.

Automation report

Với automation, ngoài pass/fail còn phải nhìn:

Dashboard xanh sau ba lần retry không nên được kể như một lần pass sạch. Nếu report giấu instability thì tới lúc pipeline đỏ thật, chẳng ai còn tin nó nữa.

Viết cho người sẽ đọc

Lead cần detail để điều phối. Product Owner cần risk và ảnh hưởng business. Lãnh đạo có thể chỉ cần release recommendation cùng vài con số có ngữ cảnh.

Một report tốt thường có hai tầng:

Đừng dán nguyên export 200 dòng từ tool vào email rồi gọi đó là summary. Link tới dashboard hoặc file chi tiết, còn trong report nói rõ điều đáng chú ý.

Chốt lại

Report không làm sản phẩm tốt lên trực tiếp. Nó làm cho quyết định về sản phẩm bớt dựa vào cảm giác.

Nếu người đọc xong vẫn không biết đã test gì, chưa test gì và release bây giờ có risk nào, report đang thiếu phần quan trọng nhất dù bảng biểu có đẹp đến đâu.

Bài cuối của Manual Testing Foundation sẽ lướt qua các nhóm tool mà tester thường gặp và cách chọn tool theo công việc, thay vì học thuộc một danh sách logo.

Nguồn tham khảo