Người dùng và số liệu
Quality metrics
Khoảng mười hai con số là đủ để biết hệ chất lượng đang tốt lên hay xấu đi. Nhiều hơn thì không ai đọc, ít hơn thì có chỗ mù.
Nội dung bài
Thuật ngữ trong bài (22)
- acceptance criteria · tiêu chí nghiệm thu
- quality gate · cổng chất lượng
- CI · tích hợp liên tục
- commit · điểm lưu thay đổi
- merge · gộp nhánh
- pipeline · dây chuyền tự động
- bug · lỗi
- coverage · độ phủ test
- defect · khiếm khuyết
- regression · lỗi tái phát
- release · bản phát hành
- rollout · đưa bản mới ra người dùng
- dashboard · bảng theo dõi
- ANR · app không phản hồi
- cold start · khởi động nguội
- device tier · bậc thiết bị
- P95
- analytics · đo hành vi người dùng
- crash-free · tỷ lệ không sập
- API · giao diện lập trình
- backend · phần máy chủ
- endpoint · điểm gọi
Quy tắc chọn chỉ số
Một chỉ số chỉ được vào dashboard khi trả lời được câu này: khi nó đi sai hướng, ai làm gì?
Không trả lời được thì bỏ. Chỉ số không gắn với hành động chỉ tạo cảm giác đang kiểm soát, trong khi thực tế là đang nhìn một cái bảng đẹp.
Hệ quả: dashboard của dự án dừng ở khoảng mười hai con số. Một dashboard năm mươi chỉ số là một dashboard không ai mở.
Mười hai chỉ số của Alliance App
| Nhóm | Chỉ số | Hướng tốt | Nguồn | Nhịp soát |
|---|---|---|---|---|
| Ổn định | Crash-free sessions | Tăng | Crash reporting | Hằng ngày |
| Ổn định | ANR rate | Giảm | Android vitals | Hằng ngày |
| Chất lượng | Số bug production mỗi release | Giảm | Bug tracker | Mỗi release |
| Chất lượng | Defect leakage | Giảm | Bug tracker | Hằng tháng |
| Test | Tỷ lệ pass của regression suite | Ổn định ở mức cao | CI | Mỗi release |
| Test | Flaky test rate | Giảm | CI | Hằng tuần |
| Test | Thời gian phản hồi của CI | Giảm | CI | Hằng tuần |
| Performance | Cold start P95 | Giảm hoặc giữ | Android vitals, Xcode Organizer | Mỗi release |
| Backend | API P95 của luồng chính | Giảm hoặc giữ | Log server | Hằng tuần |
| Nghiệp vụ | Tỷ lệ đăng nhập thành công | Tăng | Analytics | Hằng ngày |
| Nghiệp vụ | Tỷ lệ thanh toán thành công | Tăng | Analytics | Hằng ngày |
| Release | Số lần phải dừng rollout hoặc vá gấp | Giảm | Sổ release | Hằng tháng |
Ngưỡng báo động của từng chỉ số nằm ở Performance budget và Production monitoring, không lặp lại ở đây.
Mười hai chỉ số này chỉ là phần sức khoẻ của quy trình. Danh sách đầy đủ những gì sổ tay phải đo, kèm chỗ giữ ngưỡng của từng con số, ở Chưa đo được thì chưa kiểm soát được.
Ba chỉ số ít dùng nhưng đáng dùng nhất
Defect leakage
Tỷ lệ bug lọt qua toàn bộ hàng rào kiểm soát và tới tay user.
Defect leakage = bug phát hiện ở production / (bug phát hiện trước release + bug ở production)
Ví dụ: QA tìm được 100 bug, production phát sinh 5
5 / 105 = 4,76%
Giá trị tuyệt đối gần như vô nghĩa — nó phụ thuộc vào việc đội ghi bug kỹ tới đâu. Xu hướng mới có nghĩa. Chuỗi 10% → 8% → 5% → 2% qua bốn quý nói rằng hàng rào đang dày lên thật.
Đây là chỉ số tổng hợp tốt nhất cho Tư duy Shift Left: nó đo trực tiếp thứ mà shift left hứa hẹn.
Flaky test rate
Test lúc xanh lúc đỏ mà code không đổi. Tác hại không nằm ở bản thân bài test hỏng — nó nằm ở chỗ nó dạy cả đội thói quen bỏ qua tín hiệu đỏ. Sau vài tuần sống chung với flaky test, một lần đỏ thật cũng sẽ bị bấm chạy lại.
Quy trình xử lý:
- Phát hiện: cùng commit, chạy lại cho kết quả khác → đánh dấu flaky.
- Cách ly ngay khỏi pipeline chặn, đưa vào nhóm riêng.
- Sửa trong tối đa hai tuần.
- Không sửa được trong hai tuần thì xoá. Test không tin được là nợ, không phải tài sản.
Mục tiêu: flaky test rate dưới 1% và không có bài nào nằm trong khu cách ly quá hai tuần.
Thời gian phản hồi của CI
Từ lúc đẩy code tới lúc biết kết quả. Đây là chỉ số ít ai theo dõi nhưng ảnh hưởng tới mọi thứ khác: pipeline chạy 40 phút không phải là một quality gate, nó là thứ người ta học cách né — bằng cách gộp nhiều thay đổi vào một lần đẩy, bỏ qua kết quả, hoặc merge trước khi CI xong.
Ngưỡng mục tiêu nằm ở bài Tư duy Shift Left.
Coverage không chỉ là code coverage
Code coverage là loại coverage dễ đo nhất, nên nó bị dùng thay cho tất cả các loại còn lại. Bức tranh đầy đủ:
| Loại coverage | Câu hỏi nó trả lời |
|---|---|
| Requirement coverage | Mỗi acceptance criteria có ít nhất một testcase chưa? |
| Critical flow coverage | Các luồng sống còn đã có automation chưa? |
| API coverage | Mỗi endpoint đã có contract test và test lỗi chưa? |
| Device coverage | Tier 1 đã chạy đủ trong release này chưa? |
| Code coverage | Bao nhiêu phần trăm dòng code được chạy qua khi test? |
Hai dòng đầu quan trọng hơn dòng cuối rất nhiều. Requirement coverage 100% với code coverage 60% an toàn hơn nhiều so với chiều ngược lại.
Đọc chỉ số cho đúng
- Nhìn xu hướng, không nhìn một điểm. Một tuần xấu có thể do một release lớn. Ba tuần xấu liên tiếp là một vấn đề.
- Chỉ số không gắn lên đầu người. Khi một con số trở thành thước đo đánh giá cá nhân, nó ngừng đo cái nó định đo: đội sẽ tối ưu con số chứ không tối ưu chất lượng. Ví dụ dễ thấy nhất là ép code coverage — kết quả là hàng loạt test không assert gì.
- Chỉ số đi sai hướng hai kỳ liên tiếp thì mở một hạng mục sửa, có người nhận, có hạn. Không làm gì thì việc theo dõi chỉ số cũng chẳng để làm gì.
Giới hạn
- Mười hai chỉ số này giả định đã có crash reporting, analytics và CI. Chưa có thì việc cần làm trước là gắn công cụ, không phải chọn KPI.
- Một số chỉ số cần vài tháng dữ liệu mới đọc được xu hướng. Đừng ra quyết định lớn dựa trên bốn tuần đầu.
- Danh sách này soát lại mỗi quý: chỉ số nào ba quý liền không dẫn tới hành động nào thì bỏ khỏi dashboard.