17/09/2026
Một feature thanh toán có thể có rất nhiều test case cho trường bắt buộc, định dạng dữ liệu, độ dài và thông báo lỗi.
Tất cả đều pass, nhưng hệ thống vẫn có thể tạo hai giao dịch khi người dùng nhấn thanh toán liên tục. Giá khuyến mãi vẫn có thể tính sai. Số lượng tồn kho vẫn có thể không được cập nhật sau khi đơn hàng thành công.
Test case nhiều chưa chắc đã phát hiện những rủi ro quan trọng nhất.
Có những lúc mình viết hàng trăm test case nhưng vẫn bỏ sót điều cần quan tâm. Nhìn lại mới thấy vấn đề không nằm ở việc mình viết chưa đủ nhiều, mà nằm ở cách mình đánh giá chất lượng của bộ test case.
Nhiều tester đang đặt bốn khái niệm sau cạnh nhau như thể chúng có cùng ý nghĩa.
Khái niệm 1: Test case quantity
Đây là số lượng test case mình đã viết hoặc đã chạy.
Con số này giúp team ước lượng khối lượng công việc, nhưng chưa cho biết bộ test có kiểm tra đúng chỗ hay không. Mười test case tập trung vào một rule quan trọng có thể tạo ra nhiều giá trị hơn một trăm test case lặp lại quanh những tình huống ít ảnh hưởng.
Khái niệm 2: Test coverage
Test coverage cho biết những phần nào của sản phẩm, requirement, trạng thái hoặc luồng sử dụng đã được kiểm tra.
Ví dụ, với thanh toán, tester cần nhìn cả lúc tạo đơn, áp mã giảm giá, chọn phương thức thanh toán, nhận kết quả và cập nhật trạng thái đơn hàng. Nếu nhiều test case chỉ xoay quanh màn hình nhập thông tin thẻ, số lượng tăng nhưng coverage của toàn flow vẫn còn thiếu.
Khái niệm 3: Risk coverage
Risk coverage trả lời câu hỏi: những lỗi có khả năng xảy ra và gây ảnh hưởng lớn đã được kiểm tra tới đâu?
Với cùng một feature thanh toán, lỗi màu nút chưa đúng và lỗi trừ tiền hai lần đều là bug. Tuy nhiên, ảnh hưởng của hai lỗi rất khác nhau. Tester cần dành nhiều thời gian hơn cho giao dịch trùng, sai số tiền, mất dữ liệu hoặc trạng thái thanh toán không đồng nhất.
Khái niệm 4: Business coverage
Business coverage nhìn vào giá trị và rule quyết định feature có thực sự phục vụ đúng mục tiêu kinh doanh hay không.
Ví dụ, hệ thống có thể xử lý thanh toán đúng về mặt kỹ thuật nhưng áp sai điều kiện khuyến mãi, cho phép dùng voucher quá số lần hoặc bán sản phẩm đã hết hàng. Flow vẫn chạy, nhưng kết quả kinh doanh đã sai.
Vì vậy, một bộ test case tốt không được đo bằng việc có bao nhiêu dòng trong file.
Điều cần nhìn là bộ test case đã đi qua những phần quan trọng của flow chưa, đã kiểm tra các vùng rủi ro lớn chưa và đã kiểm tra đúng business rule chưa.
Khi cần chọn test case, mình thường bắt đầu bằng bốn bước:
Bước 1: Xác định mục tiêu quan trọng nhất của feature.
Bước 2: Liệt kê những cách feature có thể thất bại.
Bước 3: Đánh giá khả năng xảy ra và mức ảnh hưởng của từng rủi ro.
Bước 4: Chọn test case tập trung vào rủi ro cao trước, sau đó mới mở rộng sang những phần còn lại.
Cách này không làm số lượng test case trở nên vô nghĩa. Số lượng vẫn cần để theo dõi và ước lượng. Tuy nhiên, nó nên là kết quả của quá trình phân tích, không phải mục tiêu để tester cố làm cho thật nhiều.
Lần tới khi review một bộ test case, thay vì chỉ hỏi “Đã đủ case chưa?”, bạn có thể hỏi:
“Nếu chỉ được giữ lại những case giúp đảm bảo chất lượng và quản lý rủi ro cho người dùng và business nhiều nhất, mình sẽ giữ case nào?”
Câu trả lời sẽ cho bạn thấy bộ test đang nhiều hay đang thực sự có giá trị.
Mình có sẵn framework để chọn test case theo risk để bạn xác định vùng cần ưu tiên và phân bố thời gian test. Bạn comment từ khóa RiskMap, mình sẽ gửi qua tin nhắn.
Nếu thấy góc nhìn này hữu ích, bạn follow Sunny Nhận Ra để mình chia sẻ thêm những kinh nghiệm thực tế về tư duy test và chuyện nghề.
Cảm ơn bạn đã đọc bài viết của mình.
