Test case cho người mới: Cách viết, kiểm tra và tránh bỏ sót luồng quan trọng
3 tháng trước · 10 phút đọc
Test case là gì và tại sao phải viết đúng 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. Viết xong 5 dòng, submit, tự khen mình nhanh.
Kết quả? Sprint đó release, user phản hồi không đăng nhập được bằng email có chữ hoa. Bug nổ production. Dev phải hotfix. Và mình mới hiểu: test case không phải "ghi lại những gì bạn nghĩ", mà là "đảm bảo mọi thứ người dùng có thể làm đều được kiểm tra".
Test case là một kịch bản kiểm thử mô tả: bắt đầu từ điều kiện gì, thực hiện các bước nào, và kết quả mong đợi là gì. Nghe đơn giản, nhưng viết đúng - đủ - rõ thì cần thực hành.
Test case tốt giúp bất kỳ ai cũng reproduce được đúng kịch bản
Tại sao cần viết đúng ngay từ đầu? Vì test case là tài liệu dùng lại nhiều lần - mỗi sprint, mỗi regression cycle. Nếu viết mơ hồ, người khác không chạy được, dev không reproduce được bug, QA lead không review được. Tốn công viết lại gấp đôi sau đó.
Cấu trúc một test case chuẩn gồm những gì?
Nhiều bạn mới hay viết test case theo kiểu: "Đăng nhập đúng → Pass". Nghe có vẻ đủ, nhưng thiếu hẳn phần quan trọng nhất: ai chạy cũng phải hiểu, không cần hỏi thêm.
Một test case đầy đủ gồm 7 phần:
1. Test case ID - Mã định danh duy nhất. Ví dụ: TC_LOGIN_001. Dùng để tham chiếu khi báo bug, review, hoặc tìm kiếm lại.
2. Tiêu đề (Title) - Mô tả ngắn kịch bản đang test. Phải đọc là biết test cái gì. Ví dụ: "Đăng nhập thành công với email hợp lệ và mật khẩu đúng".
3. Precondition (Điều kiện trước) - Những gì phải có/đúng trước khi bắt đầu chạy test. Ví dụ: "User đã có tài khoản, chưa đăng nhập, đang ở trang login".
4. Steps (Các bước thực hiện) - Liệt kê từng bước rõ ràng, theo thứ tự. Mỗi bước là một hành động cụ thể. Không viết "nhập thông tin" mà phải "nhập email: [email protected] vào ô Email".
5. Test data (Dữ liệu test) - Dữ liệu cụ thể dùng để chạy test. Đừng để "nhập email hợp lệ" mà hãy ghi rõ "email: [email protected], password: Test@123".
6. Expected result (Kết quả mong đợi) - Điều gì sẽ xảy ra nếu hệ thống hoạt động đúng. Phải cụ thể: "Chuyển sang trang dashboard, hiển thị tên user góc phải" chứ không phải "đăng nhập thành công".
7. Priority (Mức độ ưu tiên) - Thường dùng: High, Medium, Low. Test case liên quan flow chính (happy path) luôn là High.
Thiếu precondition là lý do phổ biến nhất khiến test case không chạy được
Thiếu bất kỳ phần nào, test case sẽ gây hiểu nhầm. Mình hay thấy bạn mới bỏ precondition nhất - dẫn đến chạy test trong điều kiện sai, kết quả không đúng, mất thêm 30 phút debug tại sao không reproduce được.
Template test case và ví dụ thực tế cho tính năng đăng nhập
Lý thuyết đủ rồi, giờ xem ví dụ thực tế. Mình lấy tính năng đăng nhập web - tính năng gần như app nào cũng có, phù hợp để thực hành.
Dưới đây là template chuẩn và 2 test case mẫu:
Tải template test case (HTML interactive)
TC_LOGIN_001 - Happy path (luồng chính)
| Trường | Nội dung |
|---|---|
| Test Case ID | TC_LOGIN_001 |
| Tiêu đề | Đăng nhập thành công với email và mật khẩu hợp lệ |
| Precondition | User đã tạo tài khoản. Trình duyệt mở trang https://demo-app.com/login. Chưa đăng nhập. |
| Steps | 1. Nhập email: [email protected] vào ô "Email" 2. Nhập password: Test@123 vào ô "Mật khẩu" 3. Click nút "Đăng nhập" |
| Test Data | Email: [email protected] / Password: Test@123 |
| Expected Result | Chuyển sang trang /dashboard. Hiển thị tên "Nguyễn Văn A" góc trên phải. Không còn nút Đăng nhập trên header. |
| Priority | High |
TC_LOGIN_002 - Negative case (luồng lỗi)
| Trường | Nội dung |
|---|---|
| Test Case ID | TC_LOGIN_002 |
| Tiêu đề | Đăng nhập thất bại khi nhập sai mật khẩu |
| Precondition | Như TC_LOGIN_001 |
| Steps | 1. Nhập email: [email protected] 2. Nhập password sai: WrongPass123 3. Click "Đăng nhập" |
| Test Data | Email: [email protected] / Password: WrongPass123 |
| Expected Result | Không chuyển trang. Hiển thị thông báo lỗi: "Email hoặc mật khẩu không đúng". Ô password bị xóa trắng. |
| Priority | High |
Luôn viết cả happy path và negative case - thiếu một trong hai là bỏ sót luồng quan trọng
Bạn thấy không - expected result phải cụ thể đến mức "ô password bị xóa trắng". Nếu chỉ ghi "hiện thông báo lỗi", dev có thể hiện lỗi nhưng không xóa password, và bạn sẽ không biết đó có phải bug không.
Cách đọc requirement để không bỏ sót luồng quan trọng
Viết được 1-2 test case không khó. Khó là đọc requirement và nghĩ ra đủ các kịch bản cần test.
Mình hay dùng kỹ thuật "What if?" - đặt câu hỏi "Điều gì xảy ra nếu..." cho mọi bước trong flow.
Ví dụ với requirement: "Người dùng nhập email và mật khẩu để đăng nhập"
Câu hỏi What if:
- Email để trống?
- Password để trống?
- Email không đúng định dạng (thiếu @)?
- Email đúng định dạng nhưng chưa đăng ký?
- Password đúng nhưng email sai chữ hoa/thường?
- Nhập sai 5 lần liên tiếp?
- Nhập password có ký tự đặc biệt:
!@#$%? - User bị khóa tài khoản?
- Kết nối mạng bị mất giữa chừng?
Từ 1 requirement 12 chữ, bạn có thể ra 9-10 kịch bản test. Đây là lý do viết test case cần tư duy phá hoại - luôn nghĩ đến cách user làm sai, không chỉ cách làm đúng.
Tư duy "What if?" giúp tìm ra edge case mà requirement không đề cập
Ngoài What if, mình hay dùng thêm 3 nhóm kịch bản:
- Happy path: Mọi thứ đúng, flow chạy ngon
- Negative case: Input sai, thiếu, không hợp lệ
- Edge case: Ranh giới giới hạn - ví dụ password tối đa 20 ký tự thì nhập đúng 20, nhập 21 sẽ ra sao?
Không cần nhớ hết từ đầu. Chỉ cần giữ thói quen hỏi "What if?" trước mỗi test session, bạn sẽ dần tự nhiên nghĩ ra các case.
Checklist lỗi phổ biến khi viết test case lần đầu
Mình đã review khá nhiều test case của bạn mới, và lỗi thường lặp đi lặp lại. Không phải lỗi kiến thức - mà là lỗi thói quen. Kiểm tra bài test case của bạn theo checklist dưới đây:
Tải checklist kiểm tra test case
Lỗi 1: Expected result quá mơ hồ
- ❌ "Hiển thị thông báo lỗi"
- ✅ "Hiển thị thông báo 'Email hoặc mật khẩu không đúng' màu đỏ dưới ô password"
Lỗi 2: Bỏ precondition Test case không có precondition khiến người chạy không biết cần chuẩn bị gì. Mình từng thấy bạn chạy test case "đổi mật khẩu" mà không đăng nhập trước - kết quả crash ngay bước 1, không biết là bug hay setup sai.
Lỗi 3: Chỉ viết happy path Hầu hết bạn mới chỉ viết "nhập đúng → thành công". Nhưng phần lớn bug được phát hiện đến từ negative case và edge case, không phải happy path. Bắt buộc phải có ít nhất 1 negative case cho mỗi tính năng.
Lỗi 4: Steps quá chung
- ❌ "Nhập thông tin đăng nhập"
- ✅ "Nhập email: [email protected] vào ô Email. Nhập password: Test@123 vào ô Mật khẩu."
Lỗi 5: Không ghi test data cụ thể Nếu test data là "email hợp lệ", người chạy sau sẽ dùng email khác - kết quả có thể khác nhau hoàn toàn. Ghi rõ dữ liệu cụ thể là bắt buộc.
Lỗi 6: Bỏ sót luồng exception Ví dụ: user đang đăng nhập mà hết session, mất mạng, server timeout. Những luồng này hay xảy ra thực tế nhưng ít ai test.
Mỗi lỗi nhỏ trong test case có thể gây miss bug quan trọng khi regression
Bạn không cần tránh hết 6 lỗi ngay lần đầu. Mình khuyên: đọc lại test case vừa viết và hỏi "Người khác đọc mà không cần hỏi mình thêm câu nào thì test case đó đạt." Đó là tiêu chuẩn thực tế.
Bắt đầu thực hành từ đâu?
Biết lý thuyết xong, bước tiếp là thực hành - và thực hành trên dự án thật (hoặc gần thật) mới thấm.
Mình gợi ý lộ trình 3 bước cho bạn mới:
Bước 1: Dùng template, không tự nghĩ format Download template ở phần trên, điền vào từng ô. Đừng lo format đẹp - lo nội dung đúng trước. Sau 5-10 test case, bạn sẽ nhớ cấu trúc mà không cần nhìn template.
Bước 2: Chọn 1 app quen thuộc để thực hành Không cần app phức tạp. Lấy Shopee, Facebook, hoặc bất kỳ app bạn dùng hàng ngày. Chọn 1 tính năng - ví dụ: thêm sản phẩm vào giỏ hàng - và viết đủ 3 loại case: happy path, negative, edge case.
Bước 3: Nhờ người khác đọc test case của bạn Đây là bước quan trọng nhất. Đưa cho bạn bè (không cần biết IT) đọc và hỏi: "Em có hiểu cần làm gì không?" Nếu họ phải hỏi lại - test case cần viết lại.
Thực hành trên app quen thuộc giúp tập trung vào kỹ thuật viết, không bị phân tâm bởi nghiệp vụ lạ
Và đừng lo nếu test case đầu tiên còn thiếu sót. Mình review lại test case hồi năm đầu, cũng thấy đủ lỗi như đã kể ở phần trên. Quan trọng là mỗi lần viết xong, tự hỏi: "Người đọc có cần hỏi thêm mình câu nào không?"
Nếu không - bạn đang tiến bộ đúng hướng.
Comment bên dưới test case đầu tiên bạn viết (copy vào comment là được), mình sẽ review và cho feedback cụ thể nhé.