BÍ KÍP VIẾT TEST CASE

Lời Nói Đầu: Test Case là gì?

Hãy tưởng tượng Test Case giống như một "Công thức nấu ăn". Bạn viết ra công thức này, đưa cho một người hoàn toàn không biết gì về hệ thống, họ cứ làm theo từng bước A, B, C thì sẽ ra được món ăn (kết quả) đúng như ý bạn. Nếu món ăn ra sai vị, tức là hệ thống đang có lỗi (Bug)!

Một bảng Test Case chuẩn sẽ được chia làm 4 nhóm thông tin chính sau đây:

PHẦN 1: THÔNG TIN NHẬN DIỆN (Đang test cái gì?)

Đây là phần giúp bạn quản lý hàng ngàn test case mà không bị rối.

STT (Mã Test Case): Giống như số CCCD của kịch bản đó. Phải là duy nhất.
- Ví dụ: TCSG_QLVB_001 (Test Case Sài Gòn _ Quản Lý Văn Bản _ Số 001).
Mã chức năng / Tên chức năng: Gắn với nhóm tính năng lớn.
- Ví dụ: F1002 / Thêm mới văn bản đi.
Loại test: Hệ thống có nhiều tầng, bạn phải xác định mình đang test phần nào:
- Giao diện (UI): Nút bấm có đúng màu không? Chữ có ngay ngắn không?
- Chức năng (Functional): Bấm lưu có lưu được không?
- API: ~~(Như bài trước mình đã học),~~ test xem dữ liệu trả về từ máy chủ có chuẩn không.
Tên trường hợp kiểm thử (Tiêu đề): Phải ngắn gọn, đi thẳng vào vấn đề. Đọc 1 câu là biết đang test cái gì.
- Ví dụ MẪU CHUẨN: "Kiểm tra hiển thị chức năng Thêm mới dự thảo văn bản trình ký" hoặc "Kiểm tra giá trị mặc định của trường Đơn vị soạn thảo".

PHẦN 2: BỐI CẢNH & CHUẨN BỊ

Bạn không thể test chức năng "Đăng xuất" nếu chưa "Đăng nhập". Đây là lúc cần đến:

Tên tác nhân chính (Actor): Ai là người thực hiện hành động này? (VD: Cán bộ, Quản trị viên, Khách). Mỗi người sẽ có quyền hạn khác nhau.
Điều kiện trước (Pre-condition): Tình trạng hệ thống hoặc dữ liệu BẮT BUỘC PHẢI CÓ trước khi bắt đầu test.
- Ví dụ: "Tài khoản cán bộ đã đăng nhập thành công và đang đứng ở màn hình Thêm mới văn bản đi".
- Ví dụ (với API): "Phải có token truy cập của tài khoản hợp lệ".

PHẦN 3: HÀNH ĐỘNG THỰC TẾ

Đây là phần cốt lõi, yêu cầu viết rõ ràng, rành mạch.

Mô tả các bước thực hiện: Viết theo dạng đánh số 1, 2, 3... Không viết văn xuôi dài dòng.
- Ví dụ:
  1. Nhấn vào dấu +
  2. Chọn chức năng "Thêm mới"
Test Data (Dữ liệu kiểm thử): Nếu bước thực hiện yêu cầu nhập liệu, bạn phải cung cấp luôn dữ liệu để người test nhập.
- Ví dụ: Tài khoản: admin, Mật khẩu: 123456, File đính kèm: tailieu.pdf.

PHẦN 4: KẾT QUẢ

Kết quả mong đợi (Expected Result): ĐÂY LÀ CỘT QUAN TRỌNG NHẤT. Sau khi làm xong các bước trên, hệ thống BẮT BUỘC phải phản hồi như thế nào? Cần mô tả chi tiết: Hệ thống chuyển đi đâu? Hiển thị thông báo gì? Trạng thái dữ liệu ra sao?
- Ví dụ: 1. Hệ thống chuyển đến màn hình "Thêm mới dự thảo văn bản trình ký". 2. Các trường nhập liệu hiển thị đúng label, placeholder, mặc định rỗng.
Kết quả thực tế (Actual Result): Chỗ này để trống khi viết. Khi nào Tester chạy thực tế thì mới điền vào xem nó có đúng như "Kết quả mong đợi" không.
Kết quả lần 1 / Lần 2 (Pass/Fail/Untest): * Pass (Đạt): Kết quả thực tế = Kết quả mong đợi.
- Fail (Không đạt): Có lỗi (Bug), cần báo Dev sửa.
- Untest: Chưa test tới.

🎯 3 NGUYÊN TẮC VÀNG ĐỂ CÓ MỘT TEST CASE "XỊN"

Độc lập (Atomic): Một Test Case chỉ nên kiểm tra MỘT thứ duy nhất. Đừng gộp "Kiểm tra Thêm, Sửa, Xóa" vào chung một dòng. Lỡ tính năng Sửa bị lỗi, bạn sẽ không biết đánh trạng thái dòng đó là Pass hay Fail.
Rõ ràng, không dùng từ mơ hồ: Không dùng các từ như "Hiển thị đẹp", "Tốc độ nhanh", "Thông báo phù hợp". Hãy viết chuẩn xác: "Hiển thị đúng màu đỏ", "Tốc độ dưới 3 giây", "Hiển thị thông báo 'Tạo mới thành công'".
Tư duy phá bĩnh (Happy path & Unhappy path): Đừng chỉ test những trường hợp người dùng nhập đúng (Happy path). Hãy test cả những lúc người dùng cố tình làm sai (Unhappy path) như: Nhập sai mật khẩu, bỏ trống ô bắt buộc nhập, upload file quá dung lượng...