Test Case(TC)
Một ca kiểm thử cụ thể gồm tiền điều kiện, các bước thao tác, dữ liệu đầu vào và kết quả mong đợi, để hai người khác nhau chạy đều ra cùng một kết luận đúng hay sai.
Định nghĩa
Viết test case tức là viết bản hướng dẫn cho một người chưa từng làm nghiệp vụ này: họ chạy theo và biết chắc kết quả đúng hay sai. Đủ chi tiết để người chạy khỏi phải đoán, đủ ngắn để họ không bỏ qua nửa sau. Cân bằng chỗ đó là nghề.
Một test case tốt có kết quả mong đợi rõ tới mức không cần hỏi ai cũng biết là pass hay fail.
Các trường bắt buộc
| Trường | Nội dung |
|---|---|
| Test Case ID | TC-PAY-014 |
| Chức năng | Thanh toán đơn hàng bằng ví điện tử |
| Tiền điều kiện | Tài khoản user_test_03 đã liên kết ví, số dư 200.000đ, giỏ hàng có 1 sản phẩm giá 150.000đ |
| Dữ liệu đầu vào | Mã OTP hợp lệ 123456, phương thức thanh toán: Ví |
| Các bước | 1. Vào giỏ hàng, bấm Thanh toán. 2. Chọn ví điện tử. 3. Bấm Xác nhận. 4. Nhập OTP, bấm Tiếp tục. |
| Kết quả mong đợi | Đơn chuyển trạng thái Đã thanh toán, số dư ví còn 50.000đ, hệ thống gửi 1 email xác nhận, ghi 1 bản ghi giao dịch với mã đơn tương ứng |
| Kết quả thực tế | (điền khi chạy) |
| Trạng thái | Pass / Fail / Blocked / N/A |
| Ghi chú | Liên kết tới yêu cầu FR-PAY-07 |
Ba trường hay bị viết ẩu nhất: tiền điều kiện, dữ liệu và kết quả mong đợi. Kết quả mong đợi ghi kiểu "thanh toán thành công" là chưa dùng được — thành công thì số dư còn bao nhiêu, có email không, bản ghi nào được sinh ra.
Viết bao nhiêu case cho một chức năng
Không có con số chuẩn. Dùng kỹ thuật thiết kế cho đỡ đoán mò:
- Phân vùng tương đương: số tiền hợp lệ, số tiền âm, số tiền vượt hạn mức — mỗi vùng một case, đừng chạy 20 giá trị cùng vùng.
- Giá trị biên: hạn mức 20.000.000đ thì test 19.999.999, 20.000.000 và 20.000.001.
- Bảng quyết định: khi có nhiều điều kiện kết hợp, ví dụ loại khách và loại voucher và kênh thanh toán.
- Chuyển trạng thái: đơn hàng đi từ Mới sang Đã thanh toán sang Đang giao, và các bước nhảy không hợp lệ.
Ví dụ thực tế
Bao nhiêu case là đủ cho một chức năng đổi điểm thưởng? QC của chuỗi cà phê 287 cửa hàng trả lời bằng 12 case, toàn luồng thuận. Sau buổi review với BA thì thành 31, và 19 case mới đều là ngoại lệ: điểm vừa đủ so với ngưỡng, điểm hết hạn đúng ngày đổi, đổi điểm rồi hủy đơn, hai thiết bị cùng đổi trong 2 giây, khách đã đổi tối đa 3 lần trong ngày.
Trong đợt SIT, 6 defect tìm thấy thì 5 cái nằm trong nhóm 19 case đó. Đổi 90 phút review lấy 5 defect không lọt xuống SIT. Sòng phẳng mà nói thì không có buổi họp nào trong sprint đó có giá bằng.
Vai trò của BA
BA không viết test case thay QC, nhưng phải review. Bạn đọc để tìm ba thứ: case nào hiểu sai nghiệp vụ, quy tắc nào chưa có case nào phủ, và kết quả mong đợi nào mâu thuẫn với tài liệu.
Nếu tài liệu của bạn có acceptance criteria viết dạng Given/When/Then, việc này nhẹ hẳn: mỗi tiêu chí gần như ánh xạ thẳng thành một hoặc vài test case. Bạn cũng dễ trả lời câu hỏi kinh điển của khách trong UAT: cái này đã test chưa, test case nào.
Lỗi hay gặp
- Viết test case phụ thuộc nhau: case 5 chỉ chạy được nếu case 4 vừa chạy xong. Chạy lẻ hoặc chạy song song là gãy.
- Trộn nhiều mục tiêu vào một case, dài 25 bước. Fail ở bước 9 thì phần sau không ai biết đúng sai.
- Không ghi dữ liệu cụ thể, để "nhập số tiền bất kỳ". Người chạy sau nhập số khác, kết quả khác.
- Copy case cũ rồi sửa tiêu đề mà quên sửa kết quả mong đợi. Cái này lọt qua review rất dễ, đọc kỹ phần expected khi review.
