Đo lường chất lượng kiểm thử (Test Metrics) trong dự án ERP doanh nghiệp: chọn đúng chỉ số, tránh đo sai hành vi

1. Tóm tắt nhanh & vì sao dự án ERP cần bộ chỉ số kiểm thử

VinaERP là hệ quản trị doanh nghiệp (ERP) lớn phục vụ hàng trăm khách hàng doanh nghiệp, gồm các module liên kết chặt: Kế toán, Bán hàng, Kho, Mua hàng, Nhân sự. Một nghiệp vụ đơn giản như 'duyệt phiếu chi' có thể chạm tới ba module cùng lúc — nếu kiểm thử lỏng lẻo, một lỗi nhỏ có thể tạo ra bút toán sai lệch dây chuyền trên toàn hệ thống sổ sách. Ở quy mô này, 'cảm thấy ổn' không còn đủ; đội QA cần một bộ chỉ số định lượng để biết chính xác module nào rủi ro, quy trình nào đang chậm cải thiện, và khi nào có thể tự tin release.

2. Chọn đúng metric theo mục tiêu — đừng đo cho có

Sai lầm phổ biến nhất khi đo lường chất lượng kiểm thử là bắt đầu từ 'chúng ta có công cụ đo được cái này, vậy đo luôn' thay vì bắt đầu từ mục tiêu. Cách làm đúng theo khung GQM (Goal — Question — Metric): trước tiên xác định MỤC TIÊU cụ thể (ví dụ 'giảm lỗi sản xuất ảnh hưởng module Kế toán'), sau đó đặt CÂU HỎI cần trả lời ('module nào đang có mật độ lỗi cao bất thường?'), rồi mới chọn METRIC phù hợp để trả lời câu hỏi đó (Defect Density theo module). Nếu đi ngược — chọn metric trước rồi tìm lý do đo — bạn dễ có một núi báo cáo đẹp nhưng vô dụng cho việc ra quyết định.

Với dự án ERP như VinaERP, các mục tiêu thường gặp và metric tương ứng: giảm rủi ro sản xuất ở module tài chính → Defect Density + DRE theo module; tăng tốc độ xử lý sự cố production → MTTR theo mức độ nghiêm trọng; đảm bảo nghiệp vụ quan trọng không bị bỏ sót khi test → Test Coverage theo yêu cầu/luồng nghiệp vụ; theo dõi sức khoẻ bộ hồi quy → Pass Rate kết hợp xu hướng theo thời gian. Không có chỉ số nào 'vạn năng' — luôn xuất phát từ câu hỏi cụ thể đội đang cần trả lời.

3. Defect Density — công thức & cách diễn giải đúng

Defect Density (mật độ lỗi) đo số lỗi tìm được trên một đơn vị kích thước sản phẩm — thường là KLOC (nghìn dòng code), nhưng với dự án nghiệp vụ như ERP, đội QA VinaERP thường quy đổi theo SỐ LƯỢNG USE CASE hoặc SỐ MÀN HÌNH NGHIỆP VỤ của từng module để dễ so sánh giữa các module có độ phức tạp khác nhau. Công thức: Defect Density = Số lỗi tìm được ÷ Kích thước sản phẩm.

VI DU: Defect Density theo module - Sprint 24 (VinaERP)
Module Ke toan   : 24 loi / 12 use case = 2.0 loi/use case
Module Ban hang   : 18 loi / 20 use case = 0.9 loi/use case
Module Kho        : 9  loi / 15 use case = 0.6 loi/use case
Module Nhan su     : 6  loi / 18 use case = 0.3 loi/use case
=> Ke toan co mat do loi cao gap 2-6 lan cac module khac -> can uu tien
   review lai thiet ke test case va tang so gio kiem thu cho module nay.

Diễn giải đúng Defect Density đòi hỏi ngữ cảnh, không chỉ nhìn con số thô. Mật độ lỗi CAO không phải luôn xấu — có thể vì module đó nghiệp vụ phức tạp hơn (Kế toán có nhiều quy tắc tính toán, bút toán kép), hoặc vì đội test module đó đang làm việc kỹ hơn hẳn các module khác. Ngược lại, mật độ lỗi THẤP không phải luôn tốt — nó có thể phản ánh module đó bị test hời hợt, thiếu ca kiểm thử, chứ không hẳn là chất lượng thật sự cao. Vì vậy Defect Density nên luôn được đọc CÙNG với Test Coverage của module đó.

4. DRE (Defect Removal Efficiency) — đo hiệu quả lọc lỗi trước release

DRE đo tỉ lệ phần trăm lỗi được phát hiện và xử lý TRƯỚC khi release, so với tổng số lỗi (bao gồm cả lỗi phát hiện SAU release trong một cửa sổ thời gian cố định, thường 30 ngày). Công thức: DRE = Lỗi trước release ÷ (Lỗi trước release + Lỗi sau release trong 30 ngày) × 100%. Đây là chỉ số phản ánh trực tiếp HIỆU QUẢ của toàn bộ quy trình kiểm thử — không chỉ riêng công của tester mà cả review thiết kế, code review, kiểm thử tự động.