Đừng để Test Case trở thành “mật mã” mà hãy viết ngắn gọn, đúng và đủ

Nhiều người lầm tưởng rằng viết Test Case (TC) càng dài, càng chi tiết là càng tốt. Thực tế, những bộ TC “đồ sộ” nhưng mơ hồ thường gây lãng phí thời gian và bỏ lỡ những lỗi nghiêm trọng.

1. Những “hố đen” thường gặp khi viết Test Case

Hãy điểm qua những lỗi khiến đồng đội (Dev/QA) phải “đau đầu”:

• Nội dung (Title) mơ hồ: Tiêu đề kiểu “Test chức năng Login” hay “Kiểm tra lỗi nhập liệu”. Đọc xong không ai biết bạn đang định test cái gì cụ thể (Trường hợp đúng hay sai? Login bằng cái gì?).

• Các bước (Steps) thiếu hụt: Nhảy cóc các bước chuẩn bị dữ liệu hoặc giả định người đọc đã biết hết rồi. Kết quả: Người khác không thể tái hiện (reproduce) được case đó.

• Kết quả mong đợi (Expected Result) chung chung: Ghi vỏn vẹn “Hệ thống hoạt động bình thường” hoặc “Hiện thông báo lỗi”.

  Câu hỏi đặt ra: “Bình thường” là gì? Thông báo lỗi nội dung cụ thể ra sao? Màu sắc, vị trí thế nào?

• Dữ liệu (Test Data) không rõ ràng: Ghi “Nhập số lớn”. Dev sẽ hỏi: “Lớn là bao nhiêu? 1 tỷ hay 100 tỷ?”.

2. Cách viết Test Case “Chuẩn không cần chỉnh”

Một Test Case tốt cần tuân thủ tiêu chí Lean & Mean (Gọn gàng và Sắc bén).

2.1. Tiêu đề (Title): Công thức [Hành động] + [Đối tượng] + [Kết quả]

Thay vì viết lan man, hãy sử dụng cấu trúc khẳng định để người đọc biết ngay mục đích.

• Sai: Kiểm tra việc đăng nhập khi sai pass.

• Đúng: Đăng nhập thất bại khi nhập sai mật khẩu 3 lần.

2.2. Các bước (Steps): Đủ để tái hiện, không thừa lời

Sử dụng các động từ hành động mạnh (Click, Input, Select…). Đừng viết thành văn xuôi.

1. Truy cập trang /login.

2. Nhập Email đúng format.

3. Nhập Mật khẩu sai.

4. Nhấn nút “Đăng nhập”.

2.3. Kết quả mong đợi (Expected Result): Phải có tính “định lượng”

Kết quả phải cụ thể để bất kỳ ai cũng có thể đối chiếu (Pass/Fail) một cách khách quan.

• Sai: Hiện lỗi.

• Đúng: Hệ thống hiển thị toast message màu đỏ: “Mật khẩu không chính xác” và focus vào vào ô mật khẩu.

3. Bảng so sánh: TC “Cũ kỹ” với TC “Hiện đại”

4. Bí kíp để Test Case “Ngắn mà Chất”

Để bộ TC của bạn vừa chuyên nghiệp vừa tiết kiệm thời gian, hãy áp dụng 3 quy tắc sau:

1. Sử dụng Checklist cho các bước lặp lại: Thay vì viết 10 TC cho 10 loại file upload khác nhau, hãy viết 1 TC khung và kèm theo một Bảng dữ liệu (Data Table) các loại file (PNG, JPG, PDF…).

2. Tách biệt Pre-condition (Điều kiện tiên quyết): Đừng đưa việc “Đăng nhập” hay “Tạo tài khoản” vào các bước thực hiện. Hãy đưa chúng lên phần điều kiện để tập trung vào mục tiêu chính của case.

3. Một mục tiêu cho mỗi Case: Đừng gộp quá nhiều kiểm tra vào một TC. Nếu bước 2 lỗi, bạn sẽ không bao giờ thực hiện được các kiểm tra ở bước 4, 5.

Lời kết

Viết Test Case không phải là để lấp đầy bảng Excel, mà là để tạo ra một bản đồ điều hướng cho chất lượng sản phẩm. Một bộ TC tốt sẽ giúp Dev tin tưởng để fix bug và giúp dự án không bị “vỡ trận” khi bàn giao.

Đây là mẫu Test Case Template được tối ưu hóa để khắc phục triệt để các lỗi “chung chung” mà chúng ta vừa thảo luận. Mẫu này tập trung vào tính rõ ràng, dễ theo dõi và có thể áp dụng ngay trên Excel, Google Sheets hoặc các công cụ quản lý test như Jira.

1. Mẫu Test Case Standard (Dạng Bảng)

2. Giải thích các cột để viết “Đúng và Đủ”

Để mẫu này phát huy tác dụng, bạn cần lưu ý cách điền nội dung vào 3 cột “tử huyệt” sau:

– Cột Title (Tiêu đề)

• Quy tắc: Tuyệt đối không viết “Test chức năng A”.

• Mẹo: Hãy viết như một lời khẳng định. Nếu bước kiểm tra này thành công, điều gì xảy ra?

• Ví dụ: “Hiển thị lỗi khi bỏ trống trường bắt buộc” thay vì “Test validation”.

– Cột Test Data (Dữ liệu)

• Tại sao cần: Để tránh việc mỗi Tester thử một kiểu dẫn đến kết quả khác nhau.

• Nội dung: Ghi rõ con số, loại file, ký tự đặc biệt hoặc trạng thái tài khoản.

• Ví dụ: Thay vì ghi “File ảnh lớn”, hãy ghi “File .JPG > 10MB”.

– Cột Expected Result (Kết quả mong đợi)

• Quy tắc: Chia nhỏ các điểm cần kiểm tra (Point of Verification).

• Nội dung: Phải bao gồm cả Phản hồi hệ thống (Thông báo, chuyển hướng) và Dữ liệu thực tế (Lưu vào DB thành công, gửi mail thành công).

3. Cách tổ chức Test Case cho dự án thực tế

Thay vì viết hàng nghìn dòng Excel rời rạc, bạn nên tổ chức theo cấu trúc:

1. Smoke Test Set: Tập hợp ~10-20 case quan trọng nhất (Login, Checkout…). Nếu bộ này Fail, dừng test toàn bộ.

2. Functional Test Set: Các case chi tiết cho từng tính năng.

3. Regression Test Set: Các case dùng để test lại sau khi có bản update mới.