Sanity Testing
Kiểm tra nhanh và có trọng điểm vào đúng phần vừa được sửa hoặc vừa thêm, xem nó có hoạt động hợp lý không trước khi bỏ công test sâu và chạy hồi quy.
Định nghĩa
Dev vừa fix 5 defect và bảo build mới đã sẵn sàng. Thay vì lao vào chạy 120 case, QC dành 40 phút kiểm đúng 5 chỗ vừa sửa cộng vài chỗ liên quan. Nếu 3 trong 5 chỗ vẫn sai, trả build luôn. Đó là sanity testing — hẹp, sâu, và tiết kiệm.
Sanity test soi đúng vùng vừa thay đổi để quyết định có đáng test tiếp hay không.
Khi nào nên chạy
- Ngay sau khi nhận build vá lỗi, trước khi bắt đầu vòng test đầy đủ.
- Sau một hotfix trên môi trường PROD hoặc UAT.
- Khi thời gian còn quá ít trước giờ release và phải quyết định nhanh.
- Sau khi đổi cấu hình liên quan tới một chức năng cụ thể, ví dụ đổi hạn mức hoặc đổi tài khoản kết nối cổng thanh toán.
Tình huống nào chạy cái gì
| Tình huống | Nên chạy |
|---|---|
| Nhận build mới hoàn toàn từ dev | Smoke |
| Vừa fix 4 defect ở module báo cáo | Sanity vào module báo cáo |
| Chuẩn bị release lên PROD | Regression bộ chính |
| Hotfix cấu hình lúc 22h | Sanity chỗ vừa đổi, regression rút gọn quanh vùng ảnh hưởng, rồi smoke trên PROD |
| Nâng cấp phiên bản database | Regression rộng, không cắt |
Sanity thường không có bộ case cố định. Nó dựa vào phán đoán của QC: chỗ này sửa xong thì còn cái gì quanh đây dễ vỡ. Vì thế nó phụ thuộc kinh nghiệm người chạy nhiều hơn hai loại kia.
Ví dụ thực tế
Nhà phân phối dược, kho lạnh ở Bình Chánh. Dev vừa fix xong lỗi làm tròn số lô, build mới lên lúc 4 giờ chiều và ca kiểm kê bắt đầu lúc 6 giờ. QC có đúng hai tiếng.
Sanity 35 phút, đi theo đường mà số lô chạy qua: tạo phiếu xuất, hủy phiếu, xem tồn, xem sổ chi tiết, chạy báo cáo tồn cuối ngày cho hai kho.
Kết quả là tồn đã đúng nhưng sổ chi tiết vẫn còn dòng bút toán rác. Fix chưa trọn. Nếu QC chỉ mở đúng màn hình tồn kho và thấy số đẹp rồi đóng defect, cái dòng rác kia sẽ tới tay kế toán vào ngày chốt sổ — thời điểm tệ nhất để phát hiện.
Ranh giới với retest
Retest là chạy lại đúng test case đã fail. Sanity rộng hơn một chút: chạy case đó, cộng thêm vài thao tác quanh đấy mà QC nghi ngờ có liên đới. Trên Jira, cả hai đều diễn ra ở bước chuyển defect từ Fixed sang Verified, nên nhiều người coi là một. Chuẩn thì tách, thực tế thì QC làm luôn cả hai trong một lượt.
Mẹo khi đi làm
Khi từ chối một build sau sanity, đừng viết "build lỗi, trả lại". Ghi rõ chạy những gì, chỗ nào còn sai, và chỗ nào chưa kịp kiểm. Dev cần biết phần chưa kiểm để không tưởng rằng phần đó đã ổn.
Còn nếu bạn là BA và đang đứng giữa: khi sanity fail liên tục ba lần cho cùng một defect, đừng để cái vòng lặp đó tiếp diễn thêm. Kéo dev, QC ngồi lại 20 phút xem cả hai có đang hiểu cùng một kỳ vọng hay không. Phần lớn các vòng lặp kiểu đó hóa ra không nằm ở code, mà nằm ở chỗ hai bên đang hiểu khác nhau về kết quả mong đợi.
