1. Giới thiệu

Bạn đã bao giờ viết hàng chục test case, ghi chép rất đầy đủ… nhưng khi quay lại chính test case đó sau vài tuần, bạn… chẳng hiểu mình viết gì chưa?

Tôi từng nghĩ viết test case chỉ đơn giản là hoàn thành task được giao. Nhưng chính trải nghiệm thực tế đã dạy tôi rằng: viết test case không đơn giản như vậy.

Tình huống thực tế Tôi từng viết test case cho tính năng đăng ký tài khoản:

• Điền form ✅
• Xác nhận OTP ✅
• Xử lý lỗi ✅

Checklist đầy đủ, task được đóng ✅. Nhưng rồi:

• 🟣 Regression Sprint sau tôi không hiểu mình viết gì.
• 🟣 Junior tester mới vào team test sai flow.
• 🟣 Developer fix bug xong quay sang hỏi tôi: “Expected result đoạn này cụ thể là gì vậy bạn?”

Tôi cười trừ… vì chính tôi cũng… không chắc mình viết gì.

2. Tôi nhận ra vấn đề là gì?

Test case tôi viết:

• ✅ Đủ thao tác
• ❌ Thiếu context
• ❌ Thiếu dữ liệu
• ❌ Thiếu expected rõ ràng
• ❌ Thiếu khả năng reuse

3. Thế nào là test case thiếu context?

• Không nói rõ trạng thái hệ thống trước khi test.
• Không có dữ liệu cụ thể cần chuẩn bị.
• Không nêu rõ expected result cụ thể.
• Không chỉ ra mục tiêu kiểm thử là gì.
• Không có ghi chú giải thích nếu bước nào dễ gây hiểu nhầm.

4. Tôi thay đổi cách viết test case như thế nào?

✅ Bắt đầu mỗi test case với câu hỏi:

• Ai sẽ đọc?
• Người khác có test lại chính xác không?
• Test case này còn dùng được sau 3 tháng không?

✅ Mỗi test case đều có:

• Điều kiện đầu vào rõ ràng.
• Expected result cụ thể.
• Dữ liệu test minh họa (vd: user, email, mã OTP…).
• Ghi chú nếu có bước nào dễ gây hiểu lầm.

5. Kết quả sau khi cải thiện test case

✅ Junior tester đọc test case là test đúng ngay từ lần đầu.

✅ Dev đọc test case hiểu logic, không cần QA giải thích.

✅ Regression tiết kiệm thời gian, dùng lại gần như nguyên trạng.

✅ Chính tôi bớt stress, không phải sửa lại chính test case mình viết trước đó.

💡 Bài học rút ra

Test case không phải là bằng chứng “tôi đã test”. Test case là tài sản chất lượng của team – là thứ đảm bảo hệ thống được kiểm soát ổn định lâu dài.

Thử thách dành cho bạn

❓Nếu bạn nghỉ phép một tuần – Test case bạn viết có giúp người khác tiếp tục test chính xác không?

✍️ Hãy chọn một test case bạn từng viết, kiểm tra lại:

• Có trạng thái đầu vào không?
• Có dữ liệu test không?
• Expected rõ ràng chưa?
• Một người mới hoàn toàn có thể test được không?

Tổng kết

✅ Viết test case không chỉ để mình đọc hiểu, mà để:

• Giúp dev hiểu logic.
• Giúp junior test đúng.
• Giúp regression tiết kiệm thời gian.
• Giúp QA team giữ chất lượng bền vững.

Test case tốt giúp team ít bug hơn – ít stress hơn – sản phẩm chất lượng hơn.