Test Reporting & Summary Report — Software Testing Fundamentals

Mở đầu — vì sao bài này quan trọng

Hãy tưởng tượng bạn là một tester đã cày cuốc suốt ba tuần cho một release. Bạn chạy hàng trăm test case, log hàng chục bug, phối hợp với dev để fix, retest tới khuya. Rồi tới ngày họp go/no-go, sếp hỏi một câu ngắn gọn: "Release này an toàn để lên production chưa?" — và bạn ấp úng, kể lể một tràng "em test nhiều lắm, còn vài bug nhỏ, nhìn chung ổn ạ".

Đó chính là lúc công sức của bạn bị đánh giá thấp. Không phải vì bạn làm dở, mà vì bạn không biết báo cáo. Trong nghề QA, có một sự thật phũ phàng: stakeholder không nhìn thấy bạn test, họ chỉ nhìn thấy báo cáo của bạn. Nếu báo cáo mờ nhạt, cả tháng làm việc của bạn cũng mờ nhạt theo.

Test Reporting — và đặc biệt là Test Summary Report (TSR) — chính là sản phẩm cuối cùng mà một QA giao cho cấp trên. Nó là cầu nối giữa công việc kỹ thuật chi tiết (mà chỉ dân test hiểu) và quyết định kinh doanh (mà sếp, PM, khách hàng phải đưa ra). Một bản báo cáo tốt biến hàng nghìn dòng test log thành một câu kết luận rõ ràng: nên release hay không, và với rủi ro gì.

Bài này sẽ dạy bạn viết được bản báo cáo đó — không phải kiểu điền form cho có, mà là loại báo cáo khiến người đọc tin tưởng và ra quyết định được ngay.

Khái niệm cốt lõi

Test Reporting là gì và có mấy loại?

Test Reporting là hoạt động thu thập, tổng hợp và trình bày thông tin về tiến độ, kết quả và chất lượng của quá trình kiểm thử. Trong thực tế có hai nhóm báo cáo bạn cần phân biệt:

Test Progress Report (báo cáo tiến độ): viết trong khi cycle đang chạy, thường theo ngày hoặc theo tuần. Trả lời câu hỏi "hôm nay/tuần này chúng ta đang ở đâu?". Ví dụ: đã chạy 120/300 case, tìm được 18 bug, còn 5 bug blocker chưa fix.
Test Summary Report (báo cáo tổng kết): viết khi cycle/release kết thúc. Trả lời câu hỏi "kết quả cuối cùng ra sao, có nên release không?". Đây là tài liệu trọng tâm của bài học này.

Hãy nhớ sự khác biệt then chốt: Progress Report phục vụ quản lý công việc hằng ngày, còn Summary Report phục vụ ra quyết định release và lưu trữ lịch sử.

Test Summary Report — cấu trúc chuẩn theo IEEE 829

IEEE 829 là chuẩn quốc tế về tài liệu kiểm thử. Phần Test Summary Report của nó gợi ý một khung mà hầu hết công ty đều dựa theo (dù có thể rút gọn). Một TSR đầy đủ gồm các mục sau:

Test Summary Report Identifier — mã định danh và phiên bản của báo cáo (ví dụ: TSR-Payment-v2.4.1), để không nhầm lẫn giữa các release.
Summary (Tóm tắt điều hành) — release nào, giai đoạn nào, phạm vi test gì, và kết luận go/no-go. Đây là phần quan trọng nhất, thường nằm đầu để sếp đọc 30 giây là hiểu.
Variances (Sai lệch) — những gì khác so với kế hoạch ban đầu: test case bị cắt, môi trường thiếu, feature bị hoãn.
Comprehensive Assessment (Đánh giá độ bao phủ) — chúng ta đã test đủ chưa? Coverage bao nhiêu phần trăm so với Test Plan?
Summary of Results (Tổng hợp kết quả) — số liệu: bao nhiêu case pass/fail/blocked, bao nhiêu bug theo mức độ nghiêm trọng, bug nào còn tồn (open/deferred).
Evaluation (Đánh giá chất lượng) — nhận định tổng thể về chất lượng sản phẩm và mức rủi ro còn lại.
Summary of Activities (Tổng hợp hoạt động) — thời gian, nhân lực, môi trường đã dùng.
Approvals (Phê duyệt) — ai chịu trách nhiệm và ký duyệt bản báo cáo này.

Bạn không cần viết đủ 8 mục cho mọi dự án. Với đội Agile nhỏ, một TSR gọn gàng chỉ cần: Summary + kết luận go/no-go, Test Coverage, Bảng kết quả (pass/fail/blocked), Danh sách bug tồn đọng, và Đánh giá rủi ro.

Những chỉ số bắt buộc phải có

Một bản báo cáo không có số liệu chỉ là cảm tính. Những con số tối thiểu bạn phải đưa vào:

Test Execution Status: tổng số case, số Pass, Fail, Blocked, Not Executed — kèm phần trăm.
Pass Rate: tỷ lệ pass = Passed / Executed. Ví dụ 285/300 = 95%.
Defect Summary: số bug theo Severity (Critical/High/Medium/Low) và theo trạng thái (Open/Fixed/Deferred/Closed).
Open Defects còn tồn: đặc biệt là bug Critical/High chưa fix — đây là thứ quyết định go/no-go.
Requirement Coverage: bao nhiêu phần trăm yêu cầu đã có test case và đã được test.

Lưu ý: bài này không đi sâu vào cách tính từng metric phức tạp như Defect Density hay DDP — đó là chủ đề của bài riêng về Test Metrics. Ở đây bạn chỉ cần biết đưa số liệu nào vào báo cáo để nó thuyết phục.

Kết luận Go / No-Go — trái tim của báo cáo

Điều khiến TSR khác một bảng thống kê khô khan chính là khuyến nghị. Là QA, bạn không phải người ra quyết định cuối cùng (đó là việc của PM/Product Owner), nhưng bạn là người đưa ra khuyến nghị dựa trên bằng chứng. Khuyến nghị nên thuộc một trong ba dạng:

Go: chất lượng đạt tiêu chí exit, không còn bug Critical/High mở, đề xuất release.
No-Go: còn bug blocker/critical hoặc coverage quá thấp, đề xuất hoãn.
Conditional Go (Go có điều kiện): release được nhưng kèm điều kiện — ví dụ tắt tạm một feature, có kế hoạch hotfix, hoặc chấp nhận rủi ro đã được ký nhận.

Tình huống thực tế

Tình huống 1 — Sàn TMĐT và bản báo cáo cứu một quyết định sai

Một sàn thương mại điện tử tại Việt Nam (giả định tên ShopViet) chuẩn bị release tính năng "flash sale 12/12". Đội QA gồm 4 người test trong 10 ngày. Đến ngày go/no-go, PM có xu hướng muốn release vì "đã trễ deadline marketing rồi".

Team lead QA trình bản Test Summary Report như sau: đã chạy 420/450 case (93%), pass rate 91%. Nhưng phần Defect Summary phơi bày điều PM không để ý: còn 2 bug Critical đang mở — một bug khiến giỏ hàng bị nhân đôi số lượng khi user bấm nhanh hai lần trong lúc mạng chậm, và một bug khiến giá sale không áp dụng đúng với đơn dùng voucher chồng voucher.

Nhờ báo cáo trình bày rõ mức độ ảnh hưởng: "bug giỏ hàng có thể gây thất thoát hàng tồn kho và khiếu nại hàng loạt trong giờ cao điểm 0h ngày 12/12", PM đã đổi ý và chọn Conditional Go: release nhưng tạm khóa tính năng voucher chồng, và fix bug giỏ hàng bằng hotfix trước 0h.

Bài học: báo cáo tốt không phải là báo cáo đẹp, mà là báo cáo phơi bày đúng rủi ro vào đúng thời điểm ra quyết định. Con số pass rate 91% nghe rất ổn, nhưng chính 2 bug Critical mới là thứ đáng lên đầu báo cáo.

Tình huống 2 — Fintech và cái bẫy "pass rate 100%"

Một startup fintech ở TP.HCM (giả định PayNhanh) làm ví điện tử. Trong một release, tester junior nộp báo cáo với dòng đầu tiên đầy tự hào: "Pass rate 100%, tất cả 180 test case đều PASS, đề xuất Go".

Team lead đọc kỹ và phát hiện vấn đề ở mục Variances và Coverage: trong 180 case đó, có 35 case bị đánh dấu "Not Executed" nhưng bạn junior đã âm thầm bỏ ra khỏi tổng số, nên mẫu số bị bóp nhỏ lại. Ngoài ra, module "hoàn tiền khi giao dịch thất bại" hoàn toàn không có test case nào — tức coverage yêu cầu chỉ đạt khoảng 78%, không phải 100%.

Sau khi làm lại báo cáo trung thực, kết luận đổi thành No-Go cho tới khi bổ sung test cho luồng hoàn tiền. Ba ngày sau, chính luồng hoàn tiền lộ ra một bug nghiêm trọng — nếu release sớm, tiền khách có thể bị "treo" không hoàn về ví.

Bài học: một con số đẹp có thể là con số nói dối. Báo cáo phải luôn ghi rõ mẫu số (bao nhiêu case tổng, bao nhiêu chưa chạy) và độ bao phủ yêu cầu. Pass rate chỉ có ý nghĩa khi bạn biết nó được tính trên nền tảng nào.

Tình huống 3 — Outsourcing và bản báo cáo gửi khách hàng Nhật

Một công ty gia công phần mềm ở Hà Nội làm dự án cho khách hàng Nhật Bản. Khách yêu cầu một Test Summary Report cuối mỗi sprint, viết theo khung IEEE 829, gửi song ngữ. Ban đầu team gửi báo cáo kiểu "kể chuyện": vài đoạn văn mô tả đã test gì. Khách phản hồi ngay: "Tôi không đọc được rủi ro từ báo cáo này".

Team chỉnh lại: thêm bảng Defect Summary phân theo Severity, thêm biểu đồ trend số bug open qua từng sprint (sprint 1: 24 bug open → sprint 4: 6 bug open), và thêm mục Evaluation ghi rõ "residual risk: 3 bug Medium liên quan giao diện trên trình duyệt cũ, không ảnh hưởng chức năng thanh toán". Khách hàng lập tức hài lòng vì nhìn một trang là hiểu được xu hướng chất lượng đang tốt lên và rủi ro còn lại có thể chấp nhận.

Bài học: với stakeholder ở xa hoặc không rành kỹ thuật, trực quan hóa xu hướng (trend qua các sprint) và định lượng residual risk có sức thuyết phục hơn nghìn dòng mô tả. Báo cáo là công cụ giao tiếp, không phải nhật ký cá nhân.

Hướng dẫn từng bước

Đây là quy trình viết một Test Summary Report từ đầu tới cuối.

Bước 1 — Xác định người đọc và mục đích. Trước khi viết một chữ, hãy hỏi: ai sẽ đọc? PM kỹ thuật cần chi tiết bug; giám đốc chỉ cần một dòng go/no-go và mức rủi ro. Viết cho đúng đối tượng — thường bạn để phần tóm tắt điều hành lên đầu cho sếp, phần chi tiết ở dưới cho người kỹ thuật.

Bước 2 — Thu thập số liệu từ hệ thống. Lấy dữ liệu từ tool quản lý test (Jira/Xray, TestRail, Zephyr...): tổng case, số pass/fail/blocked/not-run, danh sách bug theo severity và status. Đừng ngồi đếm tay — số liệu phải truy xuất được và kiểm chứng được.

Bước 3 — Viết phần Summary (tóm tắt điều hành). Ba đến năm câu: release nào, phạm vi test, kết quả tổng quan, và khuyến nghị go/no-go. Ví dụ: "Release Payment v2.4.1, test từ 15–25/06. Đã chạy 285/300 case, pass rate 95%. Còn 1 bug High đang fix. Khuyến nghị: Conditional Go — release sau khi verify fix bug #4521."

Bước 5 — Lập bảng Defect Summary. Phân bug theo Severity (Critical/High/Medium/Low) và theo Status (Open/Fixed/Deferred). Làm nổi bật những bug Critical/High còn mở — đây là căn cứ chính cho go/no-go. Với bug Deferred, ghi rõ đã được ai chấp nhận hoãn.

Bước 6 — Đánh giá coverage và variances. Nêu phần trăm yêu cầu đã được test, những vùng chưa test (và tại sao), sai lệch so với Test Plan (case bị cắt, môi trường thiếu, thời gian rút ngắn).

Bước 7 — Viết phần Evaluation và khuyến nghị. Đây là nơi bạn thể hiện tư duy QA: dựa trên số liệu, chất lượng sản phẩm thế nào, rủi ro còn lại (residual risk) là gì, và bạn khuyến nghị Go / No-Go / Conditional Go kèm điều kiện cụ thể.

Bước 8 — Rà soát, gửi và lưu trữ. Đọc lại để loại bỏ mâu thuẫn số liệu, thêm ngày tháng và phiên bản, gửi cho stakeholder và lưu lại làm hồ sơ lịch sử. Bản TSR này sẽ vô cùng hữu ích khi cần truy vết "release đó chúng ta đã biết những rủi ro gì".

Lỗi thường gặp & mẹo

Lỗi 1 — Báo cáo toàn số, không có kết luận. Bạn liệt kê 300 case, 18 bug, rồi… hết. Người đọc không biết phải làm gì với đống số đó. Mẹo: luôn kết thúc bằng một khuyến nghị rõ ràng go/no-go và mức rủi ro.

Lỗi 2 — Che giấu tin xấu. Vì sợ bị đánh giá, tester làm nhẹ đi các bug nghiêm trọng hoặc giấu case chưa chạy. Đây là điều tối kỵ — khi bug nổ ra ở production, chính bạn chịu trách nhiệm. Mẹo: báo cáo trung thực là tài sản uy tín lớn nhất của QA. Tin xấu được báo sớm luôn tốt hơn tin xấu nổ muộn.

Lỗi 3 — Bóp méo pass rate. Loại case Not Executed ra khỏi mẫu số để pass rate đẹp hơn. Mẹo: luôn công khai tổng số case và số chưa chạy; tính pass rate trên số đã thực thi và nêu rõ điều đó.

Lỗi 4 — Viết dài dòng, không có tóm tắt. Sếp không có thời gian đọc 5 trang. Mẹo: áp dụng nguyên tắc "kim tự tháp ngược" — kết luận quan trọng nhất lên đầu, chi tiết ở dưới. Một trang tóm tắt điều hành là đủ cho lãnh đạo.

Lỗi 5 — Nhầm Severity với Priority khi báo cáo. Báo cáo gộp chung khiến sếp hiểu sai mức khẩn. Hai khái niệm này khác nhau (có bài riêng phân tích sâu). Mẹo: khi lập Defect Summary, tách rõ hai cột nếu stakeholder cần, đừng để lẫn.

Lỗi 6 — Không có phiên bản và ngày tháng. Sáu tháng sau không ai biết báo cáo này thuộc release nào. Mẹo: mỗi TSR phải có mã định danh, phiên bản, khoảng thời gian test và tên người lập.

Mẹo vàng — Trực quan hóa xu hướng. Một biểu đồ bug-trend qua các cycle (số bug open giảm dần) hoặc một burndown chart nói lên "chất lượng đang tốt lên" hiệu quả hơn mọi câu chữ. Stakeholder tin vào đường xu hướng.

Bài tập thực hành

Bài tập 1 — Viết một Test Summary Report ngắn. Giả sử bạn vừa test xong release "Đăng nhập bằng số điện thoại + OTP" của một app đặt đồ ăn. Dữ liệu: tổng 80 case, 72 pass, 5 fail, 3 blocked (do server OTP chập chờn), 2 bug High đang mở (OTP đôi khi gửi trễ >60s; đăng nhập sai 5 lần không bị khóa tài khoản), 4 bug Medium đã fix. Hãy viết một TSR khoảng nửa trang gồm: Summary + go/no-go, bảng execution, Defect Summary, và Evaluation. Tự đưa ra khuyến nghị và lập luận cho nó.

Bài tập 2 — Phát hiện báo cáo gian dối. Một đồng nghiệp nộp báo cáo: "Pass rate 98%, đề xuất Go". Bạn nhìn kỹ thấy: tổng 200 case nhưng 60 case Not Executed, và module thanh toán chưa có case nào. Hãy viết 3–4 câu phản biện chỉ ra điểm sai và đề xuất kết luận đúng.

Bài tập 3 — Chuyển số liệu thành khuyến nghị. Cho bảng: Critical: 0 open, High: 1 open (đang fix, dự kiến xong trong 2h), Medium: 4 open (đã được PO chấp nhận deferred), coverage 96%. Bạn sẽ khuyến nghị Go, No-Go hay Conditional Go? Viết phần Evaluation kèm residual risk.

Gợi ý tự chấm: một bài làm tốt luôn có (1) mẫu số rõ ràng, (2) bug nghiêm trọng được nêu bật, (3) một kết luận dứt khoát, và (4) rủi ro còn lại được định lượng.

Tóm tắt

Test Summary Report là sản phẩm cuối cùng và cũng là "bộ mặt" của công việc QA trước stakeholder. Những điều cốt lõi cần nhớ:

Phân biệt Progress Report (trong cycle, quản lý tiến độ) và Summary Report (cuối cycle, ra quyết định release).
Cấu trúc chuẩn dựa theo IEEE 829: định danh, tóm tắt, sai lệch, độ bao phủ, kết quả, đánh giá, hoạt động, phê duyệt — có thể rút gọn cho Agile.
Luôn có số liệu có mẫu số rõ ràng: execution status, pass rate, defect summary theo severity/status, và coverage.
Trái tim của báo cáo là khuyến nghị go/no-go — dựa trên bằng chứng, kèm định lượng residual risk.
Trung thực tuyệt đối: không giấu tin xấu, không bóp méo pass rate. Uy tín là tài sản lớn nhất của tester.
Viết theo kim tự tháp ngược, trực quan hóa xu hướng, ghi rõ phiên bản và ngày tháng để lưu trữ lịch sử.

Khi bạn viết được một bản báo cáo mà sếp đọc 30 giây là ra quyết định được, bạn đã bước từ "người chạy test" lên "người cố vấn chất lượng". Đó chính là bước ngoặt nghề nghiệp của một QA giỏi.