Test Metrics — Defect Density, Coverage, DDP

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

Hãy tưởng tượng bạn là Test Lead trong một dự án ví điện tử, và sếp hỏi: "Chất lượng sản phẩm bây giờ thế nào? Tuần sau có dám release không?". Nếu bạn trả lời "Em thấy cũng ổn ổn ạ, team test khá kỹ rồi", thì gần như chắc chắn bạn sẽ nhận lại một ánh mắt nghi ngờ. Bởi vì "ổn ổn" không phải là ngôn ngữ mà quản lý, khách hàng, hay chính bản thân bạn có thể ra quyết định dựa trên đó.

Đây chính là lý do test metrics — các chỉ số đo lường kiểm thử — tồn tại. Metrics biến những cảm nhận mơ hồ ("code này nhiều bug lắm", "test gần xong rồi") thành con số cụ thể mà mọi người trong dự án đều hiểu giống nhau và có thể so sánh, theo dõi qua thời gian. Khi bạn nói "module thanh toán có defect density 8 lỗi/KLOC, cao gấp đôi trung bình dự án", câu chuyện lập tức trở nên nghiêm túc và có cơ sở hành động.

Trong bài này, chúng ta tập trung sâu vào ba nhóm chỉ số nền tảng mà bất kỳ QA nào cũng cần nắm vững: Defect Density (mật độ lỗi), Test Coverage (độ bao phủ kiểm thử), và DDP — Defect Detection Percentage (tỷ lệ phát hiện lỗi). Đây là bộ ba giúp bạn trả lời ba câu hỏi khác nhau: "Phần nào của sản phẩm nhiều lỗi nhất?", "Chúng ta đã test được bao nhiêu?", và "Team test giỏi đến mức nào trong việc bắt lỗi trước khi khách hàng bắt gặp?".

Lưu ý: đây không phải bài về toàn bộ hệ thống metrics QA (những chỉ số như test execution status, defect clustering hay Pareto đã có bài riêng). Chúng ta đào thật sâu vào ba chỉ số cốt lõi này để bạn hiểu bản chất, biết tính, biết diễn giải và — quan trọng nhất — biết những cái bẫy khi dùng chúng.

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

Defect Density — Mật độ lỗi

Defect Density đo số lượng lỗi trên một đơn vị kích thước của phần mềm. Công thức chuẩn:

Defect Density = Số defect / Kích thước module

Kích thước module thường được tính bằng KLOC (Kilo Lines Of Code — nghìn dòng code) hoặc Function Point (điểm chức năng). Ví dụ, một module có 12 lỗi và 4.000 dòng code (4 KLOC) sẽ có defect density = 12 / 4 = 3 lỗi/KLOC.

Con số này nói lên điều gì? Nó cho biết mức độ "dày đặc" lỗi trong một phần code, giúp bạn so sánh chất lượng giữa các module có kích thước khác nhau một cách công bằng. Một module 20 lỗi nghe có vẻ tệ, nhưng nếu nó có 50.000 dòng code thì density chỉ 0,4 lỗi/KLOC — thực ra rất tốt. Ngược lại, module chỉ 5 lỗi nhưng có 300 dòng code thì density là gần 17 lỗi/KLOC — báo động đỏ.

Về ngưỡng tham chiếu thường được ngành công nghiệp phần mềm sử dụng:

• 1–5 lỗi/KLOC: mức chấp nhận được đến tốt, điển hình cho phần mềm được kiểm soát chất lượng ổn.
• Dưới 1 lỗi/KLOC: chất lượng rất cao, thường thấy ở phần mềm y tế, hàng không, tài chính đòi hỏi khắt khe.
• Trên 10 lỗi/KLOC: mức đáng lo ngại — module này có thể được viết vội, thiếu review, hoặc yêu cầu quá phức tạp/mơ hồ. Đây là ứng viên hàng đầu cho refactor hoặc test bổ sung.

Hãy nhớ: những con số này là tham chiếu, không phải luật. Chúng phụ thuộc vào ngôn ngữ lập trình, độ phức tạp domain, và cách bạn đếm lỗi. Giá trị thực sự của defect density nằm ở việc so sánh — so giữa các module trong cùng dự án, hoặc so cùng một module qua các bản release.

Test Coverage — Độ bao phủ kiểm thử

Coverage trả lời câu hỏi: "Chúng ta đã test được bao nhiêu phần của thứ cần test?". Vấn đề là "thứ cần test" có nhiều nghĩa, nên có nhiều loại coverage khác nhau:

Requirement Coverage (bao phủ yêu cầu):

Requirement Coverage = (Số yêu cầu đã có test case / Tổng số yêu cầu) × 100%

Nếu dự án có 80 yêu cầu và bạn đã viết test case cho 72 yêu cầu, coverage = 90%. Đây là loại coverage mà QA quan tâm nhất, vì nó gắn với giá trị nghiệp vụ.

Test Case Execution Coverage (bao phủ thực thi):

Execution Coverage = (Số test case đã chạy / Tổng số test case) × 100%

Code Coverage (bao phủ code) — thường do developer/automation đo, gồm nhiều mức: Statement coverage (câu lệnh), Branch coverage (nhánh điều kiện), Path coverage (đường thực thi). Ví dụ statement coverage 85% nghĩa là 85% số dòng code được thực thi ít nhất một lần khi chạy test.

Điểm mấu chốt bạn phải khắc cốt ghi tâm: coverage cao KHÔNG đồng nghĩa với chất lượng cao. Code coverage 100% chỉ chứng minh mọi dòng code đã được "chạy qua", chứ không chứng minh mọi hành vi đã được "kiểm tra đúng". Bạn có thể chạy qua một hàm mà không hề assert (kiểm chứng) kết quả của nó. Coverage là điều kiện cần, không phải điều kiện đủ.

DDP — Defect Detection Percentage

DDP đo hiệu quả của hoạt động kiểm thử: trong tổng số lỗi tồn tại, team test bắt được bao nhiêu phần trăm trước khi sản phẩm đến tay người dùng.

DDP = (Số lỗi tìm thấy trước release / Tổng số lỗi) × 100%
Trong đó:
Tổng số lỗi = Lỗi tìm thấy trước release + Lỗi khách hàng phát hiện sau release

Ví dụ: trong một release, team QA tìm được 180 lỗi trước khi phát hành. Sau khi release 3 tháng, khách hàng và production báo về thêm 20 lỗi. Vậy:

DDP = 180 / (180 + 20) × 100% = 180 / 200 × 100% = 90%

DDP 90% nghĩa là team test đã "chặn" được 90% lỗi trước cửa, chỉ để lọt 10% ra ngoài. Đây là một trong những chỉ số phản ánh trung thực nhất năng lực của một đội test, vì nó đo bằng kết quả thực tế (lỗi lọt ra production) chứ không phải bằng nỗ lực (số test case viết được).

Lưu ý quan trọng về thời điểm: DDP chỉ đo được chính xác sau khi đã có một khoảng thời gian production đủ dài để lỗi ẩn lộ ra. Nhiều team dùng mốc 30, 60 hoặc 90 ngày sau release để "chốt" DDP của một phiên bản.

Tình huống thực tế

Ví dụ 1: Tiki và module giỏ hàng "nặng nề"

Một team QA làm việc trên nền tảng thương mại điện tử kiểu Tiki tổng hợp defect density cuối sprint và thấy bức tranh sau:

Nhìn con số tuyệt đối, "Giỏ hàng & Checkout" có 22 lỗi — nhiều nhất, ai cũng thấy. Nhưng defect density mới là thứ gây sốc: 7,9 lỗi/KLOC, cao gấp 5–7 lần các module khác, dù bản thân module này lại nhỏ nhất (chỉ 2,8 KLOC).

Diễn giải: một khối code nhỏ mà "gánh" 22 lỗi cho thấy logic bị nhồi nhét quá phức tạp — xử lý mã giảm giá, tính phí ship theo khu vực, gộp nhiều người bán, đồng bộ tồn kho — tất cả dồn vào chưa đến ba nghìn dòng code. Team quyết định không chỉ test kỹ hơn, mà đề xuất dev refactor tách module này ra, đồng thời ưu tiên nguồn lực test vào đây cho các sprint sau.

Bài học: Đừng chỉ nhìn số lỗi tuyệt đối. Defect density chuẩn hóa theo kích thước mới chỉ ra được "điểm nóng" thật sự cần can thiệp về mặt kiến trúc, không chỉ về mặt kiểm thử.

Ví dụ 2: Ví điện tử MoMo và bài học DDP đắt giá

Giả định một đội QA của sản phẩm ví điện tử tương tự MoMo tự tin release tính năng "chuyển tiền theo lịch hẹn". Trước release, họ đạt requirement coverage 100% và tìm được 145 lỗi. Sếp rất hài lòng với con số coverage tuyệt đối.

Nhưng sau release 60 ngày, tổng đài và hệ thống giám sát ghi nhận 38 lỗi từ production — trong đó có vài lỗi nghiêm trọng: giao dịch bị trừ tiền hai lần khi mạng chập chờn, và lịch hẹn bị lệch múi giờ với người dùng ở nước ngoài.

Tính DDP:

DDP = 145 / (145 + 38) × 100% = 145 / 183 × 100% ≈ 79,2%

DDP chỉ ~79% — nghĩa là cứ 5 lỗi thì có 1 lỗi lọt ra khách hàng. Với một sản phẩm tài chính, con số này là không thể chấp nhận.

Diễn giải: Coverage 100% đã tạo ra cảm giác an toàn giả. Vấn đề là 100% requirement coverage chỉ nói rằng mỗi yêu cầu có ít nhất một test case, chứ không nói các test case đó có phủ hết các tình huống biên, mạng yếu, hay đa múi giờ hay không. Những lỗi lọt ra đều thuộc nhóm kịch bản mà test case chưa đụng tới.

Bài học: DDP là "tấm gương soi" trung thực hơn coverage. Khi DDP thấp dù coverage cao, đó là tín hiệu rõ ràng rằng bộ test case đang thiếu chiều sâu — bạn cần bổ sung kỹ thuật thiết kế test cho các tình huống mạng yếu, biên giá trị và timezone (những chủ đề có bài học riêng trong khóa này).

Ví dụ 3: Startup fintech Đông Nam Á theo dõi DDP theo quý

Một startup fintech ở Singapore phục vụ thị trường Việt Nam và Indonesia quyết định theo dõi DDP qua từng quý để đánh giá đội QA đang tiến bộ hay thụt lùi:

Diễn giải: Xu hướng DDP tăng đều từ 79% lên 91% trong ba quý là bằng chứng định lượng rằng các cải tiến quy trình (thêm code review, đưa test vào pipeline CI, tăng test cho các luồng thanh toán) đang thực sự có hiệu quả. Điều quý giá không nằm ở một con số đơn lẻ mà ở đường xu hướng.

Bài học: Metrics phát huy sức mạnh lớn nhất khi được theo dõi liên tục qua thời gian. Một DDP 79% đứng một mình khó nói lên điều gì, nhưng chuỗi 79% → 86% → 91% kể một câu chuyện thuyết phục về đội ngũ đang trưởng thành.

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

Đây là quy trình thực tế để thu thập và sử dụng bộ ba chỉ số này trong dự án của bạn:

Bước 1 — Xác định mục đích trước khi đo. Hỏi rõ: bạn muốn trả lời câu hỏi gì? Tìm điểm nóng lỗi? Dùng defect density. Đánh giá độ đầy đủ của test? Dùng coverage. Đánh giá năng lực bắt lỗi của đội? Dùng DDP. Đừng đo chỉ vì "cần có báo cáo".

Bước 2 — Thống nhất định nghĩa và đơn vị. Với defect density: chọn KLOC hay function point, và thống nhất "một defect" là gì (chỉ tính bug đã được xác nhận, hay tính cả bug bị reject?). Với coverage: chọn loại coverage phù hợp (thường QA chọn requirement coverage). Với DDP: chốt mốc thời gian production để tính lỗi sau release (ví dụ 60 ngày).

Bước 3 — Thu thập dữ liệu từ nguồn tin cậy. Số lỗi lấy từ công cụ quản lý bug (Jira, Azure DevOps). Kích thước code lấy từ dev hoặc công cụ đếm dòng. Số yêu cầu lấy từ tài liệu requirement/backlog. Đảm bảo dữ liệu sạch — một bug bị đếm hai lần sẽ làm sai lệch mọi tính toán.

Bước 4 — Tính toán và chuẩn hóa. Áp dụng công thức. Với defect density, luôn tính theo từng module để có thể so sánh, đừng gộp cả dự án thành một con số vô nghĩa.

Bước 5 — Diễn giải trong ngữ cảnh, không đọc số trần trụi. Một module density 9 lỗi/KLOC không tự động là "tệ" — có thể nó là module phức tạp nhất và đang được test rất kỹ (nên tìm ra nhiều lỗi là điều tốt). Luôn hỏi "tại sao" đằng sau con số.

Bước 6 — Trực quan hóa và theo dõi xu hướng. Vẽ biểu đồ density theo module, DDP theo release. Xu hướng quan trọng hơn giá trị tuyệt đối tại một thời điểm.

Bước 7 — Biến số thành hành động. Metric không dẫn tới quyết định là metric lãng phí. Density cao ở đâu → dồn test hoặc đề xuất refactor ở đó. DDP giảm → điều tra quy trình test đang hổng chỗ nào.

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

Lỗi 1 — Coi coverage 100% là "đã test xong". Đây là ngộ nhận phổ biến nhất. Như ví dụ MoMo cho thấy, 100% coverage vẫn để lọt lỗi nghiêm trọng. Coverage đo độ rộng, không đo độ sâu và độ đúng của test.

Lỗi 2 — So sánh defect density giữa các dự án không tương đồng. Density của một app mobile viết bằng Swift không thể so trực tiếp với một hệ thống backend Java. Ngôn ngữ, domain, và cách đếm khác nhau khiến việc so sánh chéo dễ dẫn tới kết luận sai.

Lỗi 3 — Dùng metric để "trừng phạt" cá nhân. Nếu bạn dùng defect density để đánh giá developer, họ sẽ tìm cách "lách": báo cáo ít bug hơn, hoặc gộp nhiều bug thành một. Metric bị thao túng còn tệ hơn không có metric. Đây là hệ quả của định luật Goodhart: "Khi một chỉ số trở thành mục tiêu, nó không còn là chỉ số tốt nữa."

Lỗi 4 — Tính DDP quá sớm. Nếu bạn tính DDP ngay ngày release, mẫu số (lỗi production) gần như bằng 0, cho ra DDP giả tạo gần 100%. Phải chờ đủ thời gian production.

Lỗi 5 — Chỉ nhìn số tuyệt đối. 22 lỗi nghe đáng sợ, nhưng không có kích thước đi kèm thì vô nghĩa. Luôn chuẩn hóa.

Mẹo hữu ích:

• Kết hợp cả ba chỉ số để có bức tranh đầy đủ: coverage cao + DDP cao + density đã ổn định = tín hiệu thực sự đáng tin để release.
• Đặt ngưỡng cảnh báo tự động (ví dụ density > 8 lỗi/KLOC thì gắn cờ đỏ trên dashboard).
• Luôn kèm chú thích ngữ cảnh khi báo cáo metric cho quản lý, tránh để họ đọc số theo cách máy móc.
• Với đội nhỏ, đừng đo quá nhiều chỉ số cùng lúc — bắt đầu từ DDP và requirement coverage, hai chỉ số này cho giá trị cao nhất so với công sức bỏ ra.

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

Bài 1 — Tính defect density và tìm điểm nóng. Một dự án có bốn module với dữ liệu sau. Hãy tính defect density từng module và chỉ ra module nào cần ưu tiên can thiệp:

Bài 2 — Tính DDP. Trong release v2.3, team QA tìm được 232 lỗi trước khi phát hành. Sau 90 ngày, production ghi nhận thêm 29 lỗi. Tính DDP. Nếu mục tiêu công ty đặt ra là DDP ≥ 90%, release này có đạt không?

Bài 3 — Phân tích tình huống. Một team báo cáo: requirement coverage 100%, code coverage (statement) 95%, nhưng DDP chỉ 72%. Theo bạn, vấn đề nằm ở đâu và bạn sẽ đề xuất ba hành động cụ thể nào để cải thiện?

Bài 4 — Thảo luận. Sếp của bạn muốn dùng defect density của từng developer để xếp hạng thưởng cuối năm. Hãy viết 3–4 câu giải thích vì sao đây là ý tưởng rủi ro, dựa trên định luật Goodhart.

Gợi ý đáp án bài 1: Thanh toán = 7,5 lỗi/KLOC (cao nhất, ưu tiên số 1). Bài 2: DDP = 232/261 ≈ 88,9% — chưa đạt mốc 90%.

Tóm tắt

• Defect Density = số lỗi / kích thước module (KLOC hoặc function point). Giúp tìm "điểm nóng" lỗi một cách công bằng giữa các module khác kích thước. Ngưỡng tham chiếu: 1–5 lỗi/KLOC là ổn, trên 10 là đáng lo. Giá trị thật nằm ở việc so sánh, không phải con số đơn lẻ.
• Test Coverage đo độ bao phủ (requirement, execution, code). Nhớ kỹ: coverage cao không đồng nghĩa chất lượng cao — nó là điều kiện cần, không phải điều kiện đủ.
• DDP = lỗi tìm trước release / tổng số lỗi. Đây là chỉ số trung thực nhất về năng lực bắt lỗi của đội, đo bằng kết quả (lỗi lọt production) chứ không bằng nỗ lực. Phải chờ đủ thời gian production mới tính chính xác.
• Metrics chỉ có ý nghĩa khi được đặt trong ngữ cảnh, theo dõi qua thời gian, và dẫn tới hành động cụ thể. Đừng để metric bị thao túng (định luật Goodhart) hay tạo cảm giác an toàn giả.
• Bộ ba này trả lời ba câu hỏi khác nhau — "phần nào nhiều lỗi?", "test được bao nhiêu?", "bắt lỗi giỏi cỡ nào?" — và mạnh nhất khi dùng cùng nhau.