BÍ KÍP VIẾT TEST CASE

PHẦN 1: THÔNG TIN NHẬN DIỆN

Đây là phần giúp 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: 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Ị 

• 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Ế 

• 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"

1. Độ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.

2. 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'".

3. 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...