Cách viết test case chuẩn cho fresher: template, ví dụ thực tế và checklist tránh sai lầm
2 tháng trước · 12 phút đọc
Test case là gì và tại sao cần viết đúng ngay từ đầu?
Mình nhớ lần đầu được giao viết test case cho tính năng đăng nhập. Nghĩ đơn giản: nhập đúng thì vào được, nhập sai thì báo lỗi. Xong. Submit ngay.
Kết quả? Dev review xong hỏi lại: "Bạn test trường hợp để trống email chưa? Test password có khoảng trắng ở đầu chưa? Test copy-paste password từ clipboard chưa?" Mình không biết trả lời thế nào. Và đó là lúc mình hiểu: viết test case không phải liệt kê những gì mình nghĩ ra được, mà là bao phủ mọi tình huống người dùng thực sự sẽ gặp.
Test case (kịch bản kiểm thử) là một tài liệu mô tả cụ thể: làm gì, với điều kiện nào, và kết quả mong đợi là gì. Đơn giản như một công thức nấu ăn - nếu bạn ghi "nêm gia vị vừa ăn" thì người khác không thể làm theo được. Phải ghi "thêm 1 thìa muối, 2 thìa nước mắm".
Tại sao cần viết đúng ngay từ đầu? Vì test case không chỉ để bạn test - nó còn để:
- Người khác đọc và reproduce (tái hiện lại) bug khi bạn vắng mặt
- Dev biết chính xác bạn đã test gì, còn thiếu gì
- PM/QA Lead review và đánh giá chất lượng công việc của bạn
Viết mơ hồ = người khác không reproduce được = bug không được fix. Mình từng gặp trường hợp này, mất thêm 2 ngày đi lại giải thích.
Test case rõ ràng giúp cả team hiểu đúng, không mất thêm thời gian giải thích
Bạn không cần biết code để viết test case tốt. Chỉ cần tư duy logic và tỉ mỉ - hai thứ người trái ngành hoàn toàn có thể học được.
Cấu trúc chuẩn của một test case
Mọi công ty có template hơi khác nhau, nhưng 6 trường sau là bắt buộc - thiếu một trong số này, test case của bạn sẽ bị trả lại.
| Trường | Ý nghĩa | Ví dụ |
|---|---|---|
| Test Case ID | Mã định danh duy nhất | TC_LOGIN_001 |
| Tiêu đề | Mô tả ngắn bạn đang test gì | Đăng nhập với email và password hợp lệ |
| Điều kiện tiên quyết | Cần chuẩn bị gì trước khi test | Tài khoản đã đăng ký, email đã xác nhận |
| Các bước thực hiện | Step-by-step cụ thể | 1. Mở trang login. 2. Nhập email. 3. Nhập password. 4. Click nút Đăng nhập |
| Kết quả mong đợi | Expected Result - sẽ thấy gì nếu đúng | Chuyển về trang dashboard, hiển thị tên user |
| Kết quả thực tế | Actual Result - điền sau khi test | Để trống trước khi test, điền sau |
Có một trường thứ 7 nhiều công ty dùng: Mức độ ưu tiên (Priority: High/Medium/Low). Trường này giúp team biết test cái nào trước khi deadline.
6 trường bắt buộc - thiếu một cái là test case chưa đạt chuẩn
Lưu ý về Test Case ID: Đặt tên có hệ thống ngay từ đầu. Công thức phổ biến: [Module]_[Loại]_[Số thứ tự]. Ví dụ: TC_LOGIN_001, TC_REGISTER_002, TC_SEARCH_001. Khi project có hàng trăm test case, việc đặt tên đúng giúp bạn tìm lại nhanh hơn nhiều.
Lưu ý về Kết quả thực tế: Trường này để trống lúc viết, chỉ điền sau khi thực sự chạy test. Đừng điền sẵn - đó là sai lầm mình hay thấy ở fresher mới.
Ba loại test case cần biết: positive, negative và edge case
Đây là phần nhiều fresher bỏ qua nhất - và cũng là lý do bug lọt production nhiều nhất.
Positive test case (kịch bản đúng): Test với dữ liệu hợp lệ, đúng như người dùng thông thường làm. Ví dụ: đăng nhập với email đúng định dạng, password đủ ký tự. Đây là loại dễ nhất, nhưng chỉ test mỗi loại này thì chưa đủ.
Negative test case (kịch bản sai): Test với dữ liệu sai, thiếu, hoặc không hợp lệ. Mục đích là kiểm tra hệ thống xử lý lỗi đúng cách không, chứ không phải kiểm tra nó chạy được. Ví dụ: đăng nhập với password sai, để trống email, nhập email không có @.
Tại sao quan trọng? Vì người dùng thực tế hay làm sai hơn là làm đúng. Nếu hệ thống không xử lý tốt, họ sẽ thấy màn hình lỗi trắng, hoặc tệ hơn - ứng dụng crash.
Edge case (trường hợp biên): Những tình huống cực đoan hoặc hiếm gặp nhưng có thể xảy ra. Đây là loại khó nghĩ ra nhất, và cũng là nơi bug ẩn nhiều nhất. Ví dụ: password dài 100 ký tự, email có dấu chấm liên tiếp, tên người dùng có emoji, copy-paste từ Word có ký tự đặc biệt ẩn.
Mình từng bỏ qua edge case "password có khoảng trắng ở đầu và cuối" vì nghĩ ai mà nhập vậy. Kết quả: có user phàn nàn không đăng nhập được dù gõ đúng password - hóa ra họ copy từ email có khoảng trắng thừa. Bug đó mất 1 ngày để trace.
Ba loại test case cần viết đủ - thiếu edge case là nơi bug hay ẩn nhất
Thực tế khi đi làm, với mỗi tính năng, mình hay chia theo tỉ lệ: 40% positive - 40% negative - 20% edge case. Không cần cứng nhắc, nhưng hãy chắc chắn bạn có cả ba loại trước khi submit.
Ví dụ thực tế: viết test case cho chức năng đăng nhập
Lý thuyết đủ rồi - mình sẽ viết thực tế để bạn nhìn vào và làm theo được ngay.
App mình dùng làm ví dụ: trang đăng nhập thông thường với 2 trường email + password và nút "Đăng nhập".
TC_LOGIN_001 - Đăng nhập thành công (Positive)
- Điều kiện tiên quyết: Tài khoản
[email protected]/Test@1234đã tồn tại và được xác nhận email - Các bước:
- Mở trình duyệt, truy cập trang
/login - Nhập email:
[email protected] - Nhập password:
Test@1234 - Click nút "Đăng nhập"
- Mở trình duyệt, truy cập trang
- Kết quả mong đợi: Trang chuyển về
/dashboard, hiển thị tên "Người dùng test" ở góc trên phải
TC_LOGIN_002 - Đăng nhập với password sai (Negative)
- Điều kiện tiên quyết: Tài khoản
[email protected]đã tồn tại - Các bước:
- Mở trang
/login - Nhập email:
[email protected] - Nhập password:
SaiPassword123 - Click nút "Đăng nhập"
- Mở trang
- Kết quả mong đợi: Hiển thị thông báo lỗi "Email hoặc mật khẩu không đúng", không tiết lộ cụ thể cái nào sai (lý do bảo mật)
TC_LOGIN_003 - Đăng nhập với email để trống (Negative)
- Điều kiện tiên quyết: Không cần
- Các bước:
- Mở trang
/login - Để trống ô email
- Nhập password:
Test@1234 - Click nút "Đăng nhập"
- Mở trang
- Kết quả mong đợi: Hiển thị thông báo lỗi ngay dưới ô email "Vui lòng nhập email", không submit form
TC_LOGIN_004 - Đăng nhập với password có khoảng trắng đầu/cuối (Edge case)
- Điều kiện tiên quyết: Tài khoản
[email protected]/Test@1234đã tồn tại - Các bước:
- Mở trang
/login - Nhập email:
[email protected] - Nhập password:
Test@1234(có 1 khoảng trắng trước và sau) - Click nút "Đăng nhập"
- Mở trang
- Kết quả mong đợi: Hệ thống tự trim khoảng trắng và đăng nhập thành công hoặc hiển thị lỗi rõ ràng - tùy quyết định của team
4 test case mẫu cho một tính năng đăng nhập - đủ cả 3 loại
Mình muốn bạn chú ý TC_LOGIN_004: kết quả mong đợi có hai khả năng. Đây là trường hợp bạn cần hỏi BA (Business Analyst) hoặc PM trước khi test, không tự đoán. Tự đoán rồi điền sai kết quả mong đợi là sai lầm phổ biến nhất của fresher.
Template test case - tải về và dùng ngay
Viết test case bằng tay từ đầu mỗi dự án rất tốn thời gian. Mình thường chuẩn bị sẵn một file template rồi duplicate ra cho từng tính năng.
Template dưới đây có đầy đủ các cột cần thiết, kèm hàng dữ liệu mẫu để bạn nhìn vào điền theo:
File gồm 3 sheet:
- Sheet 1 - Template trống: Cấu trúc chuẩn để bạn bắt đầu ngay
- Sheet 2 - Ví dụ Login: 8 test case mẫu cho chức năng đăng nhập (positive + negative + edge)
- Sheet 3 - Ví dụ Tìm kiếm: 6 test case mẫu cho chức năng search sản phẩm
Template có sẵn ví dụ - xem mẫu rồi tự điền theo tính năng của bạn
Một vài lưu ý khi dùng template:
Cột Status có 4 giá trị: Pass, Fail, Blocked, Not Tested. Nhiều fresher chỉ biết Pass/Fail, bỏ qua Blocked - là trạng thái khi bạn không test được vì lý do bên ngoài (môi trường lỗi, tính năng khác chưa xong, thiếu dữ liệu test). Điền Blocked thay vì để trống giúp QA Lead biết còn bao nhiêu test case chưa chạy.
Cột Priority dùng High/Medium/Low. Nguyên tắc: tính năng ảnh hưởng đến thanh toán, đăng nhập, dữ liệu cốt lõi → High. Tính năng UI nhỏ, text hiển thị → Low.
Những sai lầm phổ biến nhất khi viết test case - và cách tránh
Mình tổng hợp lại từ kinh nghiệm review test case của nhiều fresher. Hầu hết mắc cùng một vài lỗi sau.
Sai lầm 1: Viết bước quá chung chung
❌ "Nhập thông tin đăng nhập và click đăng nhập"
✅ "Nhập email: [email protected] vào ô Email. Nhập password: Test@1234 vào ô Password. Click nút màu xanh 'Đăng nhập'."
Quy tắc: Người không biết app này vẫn làm theo được. Nếu cần hỏi lại - bước đó chưa đủ cụ thể.
Sai lầm 2: Kết quả mong đợi mơ hồ
❌ "Đăng nhập thành công"
✅ "Trang chuyển hướng về /dashboard trong vòng 2 giây. Header hiển thị avatar và tên 'Người dùng test'. URL thanh địa chỉ thay đổi thành /dashboard."
Kết quả mong đợi phải quan sát được - không phải cảm nhận.
Sai lầm 3: Chỉ test happy path
Đây là lỗi mình đã kể ở đầu bài. Tính năng đăng nhập có ít nhất 10-15 test case, không phải 2-3. Nếu bạn viết ít hơn 5 test case cho một tính năng cơ bản - hãy xem lại.
Sai lầm 4: Quên điều kiện tiên quyết
Test case cần dữ liệu có sẵn (tài khoản test, sản phẩm trong giỏ, đơn hàng đang xử lý...) mà không ghi ra thì người khác không chạy được. Mình từng gặp test case "Kiểm tra hủy đơn hàng" mà không ghi cần đơn hàng ở trạng thái nào, phải hỏi đi hỏi lại 3 lần.
Sai lầm 5: Dùng từ nhập nhằng
Tránh: "nhập đúng", "nhập sai", "kết quả tốt", "hiển thị bình thường". Những từ này ai đọc cũng hiểu khác nhau. Thay bằng số liệu, nội dung cụ thể, hành vi quan sát được.
5 sai lầm phổ biến - tránh được hết thì test case của bạn đã trên trung bình
Thấy danh sách dài thì hơi nản, mình hiểu. Nhưng thật ra chỉ cần nhớ một câu: "Người khác đọc mà không cần hỏi lại được không?" Câu đó là bộ lọc cho mọi test case bạn viết.