Test Coverage
Tỉ lệ phần đã được kiểm thử so với phần cần kiểm thử, tính theo yêu cầu, theo chức năng hoặc theo dòng code. Con số này chỉ có nghĩa khi nói rõ đang phủ trên cái gì.
Định nghĩa
Sếp hỏi: test tới đâu rồi. Trả lời "chạy được 263 case" là chưa trả lời gì cả, vì 263 case đó có thể phủ hết nghiệp vụ, mà cũng có thể xoay quanh đúng ba màn hình. Test coverage là cách nói cho có nghĩa: đã phủ được bao nhiêu phần của cái cần phủ.
Độ phủ chỉ có nghĩa khi gắn với một cái mẫu số cụ thể: phủ trên yêu cầu, trên chức năng, hay trên code.
Có mấy loại độ phủ
- Requirement coverage: bao nhiêu phần trăm yêu cầu đã có ít nhất một test case. Đây là loại BA quan tâm nhất.
- Test case execution coverage: bao nhiêu phần trăm case đã được chạy trong đợt này.
- Code coverage: bao nhiêu phần trăm dòng lệnh hoặc nhánh điều kiện được chạy qua khi test. Do dev đo bằng công cụ, gắn với unit test.
Còn một loại thứ tư ít nơi làm mà làm thì rất đáng: risk coverage, tức là các rủi ro đã liệt kê trong test plan đã được kiểm tới đâu.
Lẫn lộn mấy loại này trong cùng một câu là chỗ dễ nói sai nhất. Code coverage 85% không nói lên rằng nghiệp vụ đã được phủ, vì code có thể chạy đúng một logic sai.
Ma trận truy vết yêu cầu
Cách đơn giản nhất để biết mình phủ tới đâu là bảng RTM: mỗi yêu cầu một dòng, cột bên phải là các test case tương ứng.
| Mã yêu cầu | Mô tả ngắn | Test case | Trạng thái |
|---|---|---|---|
| FR-ORD-01 | Tạo đơn hàng từ giỏ | TC-ORD-001 tới 006 | Pass |
| FR-ORD-02 | Hủy đơn khi chưa xuất kho | TC-ORD-010, 011 | 1 fail |
| FR-ORD-03 | Tách đơn khi thiếu hàng | (trống) | Chưa có case |
| FR-PAY-07 | Thanh toán bằng ví | TC-PAY-014 tới 021 | Pass |
Dòng FR-ORD-03 chính là lý do người ta làm bảng này. Trước khi có RTM, yêu cầu đó chưa từng được test mà cả đội vẫn yên tâm, vì ai cũng đang nhìn con số 263 case.
Ví dụ thực tế
Tỉ lệ pass cuối SIT là 96%. Báo cáo đẹp, ai nhìn cũng gật. Rồi BA ngồi ghép RTM cho hệ thống quản lý hợp đồng bảo hiểm của một đại lý 37 nhân sự: 118 yêu cầu chức năng, 14 cái không ánh xạ tới bất kỳ test case nào. Trong 14 cái đó có nghiệp vụ tái tục hợp đồng, thứ mà đại lý dùng hằng tuần.
Lý do rất đời: nghiệp vụ tái tục được bổ sung ở phiên bản tài liệu thứ ba, QC vẫn viết case theo phiên bản thứ hai. Chẳng ai làm sai quy trình, chỉ là không có bước đối chiếu lại. Sau đó đội thêm 22 test case và tìm ra 5 defect, một cái mức High.
Con số 100% và cái bẫy của nó
Phủ 100% yêu cầu là mục tiêu hợp lý. Phủ 100% mọi tổ hợp đầu vào là chuyện bất khả thi, ISTQB gọi thẳng đây là một trong bảy nguyên lý: kiểm thử toàn bộ là không thể.
Có ba cái bẫy hay gặp:
- Coi độ phủ là chỉ tiêu để báo cáo đẹp. Cách gian lận rất dễ: viết case sơ sài nhưng nhiều, gán vào mọi yêu cầu, con số lên 100%.
- Đếm case đã viết thay vì case đã chạy. Hai chuyện khác nhau.
- Quên phủ luồng ngoại lệ, vì tài liệu yêu cầu vốn chỉ mô tả luồng thuận. Coverage theo tài liệu đạt 100% mà hệ thống vẫn vỡ khi mất mạng giữa chừng.
Việc của BA
Đánh mã cho từng yêu cầu ngay từ lúc viết tài liệu, kiểu FR-ORD-01. Việc này mất thêm mười phút và tiết kiệm hàng giờ về sau, vì nó là cái móc để nối yêu cầu với test case, với defect, với dòng trong biên bản nghiệm thu.
Trước khi kết thúc mỗi giai đoạn test, dành nửa buổi ngồi cùng QC rà RTM. Bạn tìm dòng trống. Chỉ vậy thôi. Nửa buổi đó thường lôi ra được vài yêu cầu chưa ai từng test, mà không có nó thì tới lúc khách hỏi mới biết.
