Tác giả
Mẫu test case thì tìm đâu cũng có. Tải một file Excel về, điền vào là xong.
Thiết kế ca kiểm thử là một trong bốn nhóm việc của một tester — nếu chưa rõ ba nhóm còn lại, đọc Manual testing là gì.
Vấn đề là test case điền đúng mẫu vẫn có thể vô dụng. Và người viết thường không biết, cho tới lúc ai đó cầm test case của mình chạy thử rồi quay lại hỏi năm câu.
Bài này có mẫu, có ví dụ đầy đủ, và phần chính là bốn lỗi khiến một test case đúng mẫu vẫn không dùng được.
Test case là gì?
Test case là mô tả một tình huống kiểm thử, đủ chi tiết để người khác làm lại được y hệt và ra cùng một kết luận.
Chữ quan trọng nhất trong câu trên là người khác. Nếu chỉ bạn hiểu, đó là ghi chú cá nhân — hữu ích cho bạn hôm nay, vô dụng cho cả đội sau ba tuần.
Đó cũng là phép thử đáng tin nhất. Đưa test case cho một đồng nghiệp chưa từng làm chức năng đó. Họ chạy hết mà không hỏi lại câu nào thì test case đạt. Họ hỏi một câu thì đã có một chỗ thiếu.
Một test case cần những gì?
- Mã — để trích dẫn khi báo lỗi, và khi cần chạy lại đúng ca đó
- Tiêu đề — đọc một dòng biết đang kiểm thứ gì
- Điều kiện trước — trạng thái phải có sẵn trước khi bắt đầu bước 1
- Dữ liệu — giá trị cụ thể dùng để nhập
- Các bước — từng bước, mỗi bước một hành động
- Kết quả mong đợi — điều đáng lẽ phải xảy ra
- Kết quả thực tế — điều đã xảy ra, điền lúc chạy
Bảy trường này là phần cốt lõi. Mỗi công ty thêm bớt vài trường: mức ưu tiên, người thực hiện, phiên bản áp dụng, liên kết tới mục nào trong tài liệu yêu cầu. Thêm gì thì thêm, nhưng bảy trường trên thiếu cái nào cũng gây rắc rối cụ thể.
Một test case viết đủ
Lấy chức năng đăng nhập, vì ai cũng hình dung được. Giả định trong tài liệu yêu cầu có quy tắc: sai mật khẩu 5 lần thì khoá tạm tài khoản.
Mã: DN-005
Tiêu đề: Sai mật khẩu 5 lần liên tiếp thì tài khoản bị khoá tạm
Điều kiện trước: Đã có tài khoản a@test.com, trạng thái đang hoạt động,
chưa có lần đăng nhập sai nào trong 24 giờ qua
Dữ liệu: Email a@test.com
Mật khẩu sai: 111111
Mật khẩu đúng: Abc@12345
Các bước: 1. Mở trang đăng nhập
2. Nhập email và mật khẩu sai
3. Bấm Đăng nhập
4. Lặp lại bước 2 và 3 cho tới lần thứ 5
5. Nhập email và mật khẩu ĐÚNG, bấm Đăng nhập
Kết quả mong đợi: Sau lần thứ 5: hệ thống báo tài khoản bị khoá tạm và
nói rõ khoá trong bao lâu.
Ở bước 5: vẫn bị chặn, không vào được, dù mật khẩu đúng.
Ba chỗ đáng để ý:
- Dữ liệu là giá trị cụ thể: Không phải "nhập mật khẩu sai" mà là
111111. Người khác chạy lại thì dùng đúng giá trị đó, và nếu kết quả khác nhau thì loại trừ được ngay nguyên nhân dữ liệu. - Điều kiện trước nhắc tới cả những lần đăng nhập sai trước đó.: Bỏ câu này thì ca kiểm thử chạy được lần đầu, chạy lại lần hai thất bại vì tài khoản đã có 3 lần sai từ hôm qua — và mất nửa buổi để hiểu vì sao.
- Kết quả mong đợi nói cả điều không được xảy ra: Bước 5 mới là bước quan trọng nhất của cả ca. Thiếu nó thì lỗi "khoá rồi nhưng nhập mật khẩu đúng vẫn vào được" đi qua mà không ai bắt — và đó chính là loại lỗi khiến quy tắc khoá tài khoản trở nên vô nghĩa.
Về con số 5 và câu "nói rõ khoá bao lâu": chúng phải lấy từ tài liệu yêu cầu. Nếu tài liệu không nói, đó là một câu hỏi cần đặt ra, không phải chỗ để tự quyết.
Bốn lỗi khiến test case thành vô dụng
1. Viết chung chung.
❌ Kiểm tra chức năng tìm kiếm hoạt động đúng
Đúng là gì? Tìm bằng từ khoá nào? Ra bao nhiêu kết quả thì đạt? Sắp xếp theo thứ tự nào?
Test case này ai chạy cũng ra kết luận khác nhau, nên nó không kiểm được gì. Nó chỉ tạo cảm giác đã có test case.
Cách sửa: mỗi test case phải trả lời được câu "làm gì, với dữ liệu gì, và kết quả nào thì đạt".
2. Nhồi nhiều thứ vào một ca.
Một test case kiểm mười điều thì khi nó thất bại, không ai biết thất bại ở điều nào. Báo cáo thành "DN-005 fail" và lập trình viên phải đọc lại cả mười bước để đoán.
Nó còn một hậu quả tệ hơn: khi điều thứ ba thất bại, bảy điều còn lại thường không được kiểm tiếp. Chúng biến mất khỏi phạm vi test mà không ai ghi nhận.
Một ca, một điều cần kiểm.
3. Kết quả mong đợi mơ hồ.
❌ Hệ thống báo lỗi
Báo lỗi gì? Nội dung câu thông báo thế nào? Hiện ở đâu — trên đầu trang hay cạnh ô bị lỗi? Nội dung đã nhập có được giữ lại không?
Một câu thông báo lỗi sai nội dung vẫn là lỗi. Một thông báo hiện ở đầu trang trong khi ô lỗi ở cuối form là lỗi trải nghiệm thật. Test case viết "hệ thống báo lỗi" cho cả hai đi qua.
4. Không ghi điều kiện trước.
Đây là lỗi tốn thời gian nhất, vì nó không lộ ra ngay.
Test case chạy được hôm nay vì tài khoản đang tình cờ ở đúng trạng thái. Tuần sau chạy lại, trạng thái đã khác, ca thất bại. Lúc đó không ai biết là do dữ liệu hay do lỗi thật, và phải điều tra từ đầu.
Phép thử: đọc test case và tự hỏi "cần gì tồn tại sẵn để bước 1 chạy được?" Câu trả lời chính là điều kiện trước.
Viết bao nhiêu ca là đủ
Không có con số. Nhưng có một cách nghĩ thay cho việc đếm.
Đừng hỏi "đủ chưa". Hỏi: có tình huống nào người dùng làm được mà mình chưa nghĩ tới không?
Ba hướng thường bị bỏ:
- Đường đi sai: Người dùng nhập thiếu rồi bấm gửi. Bấm nút hai lần vì lần đầu tưởng chưa ăn. Bấm Back giữa luồng rồi quay lại. Mở hai tab cùng làm một việc.
- Giá trị ở biên: Số 0, chuỗi rỗng, chuỗi chỉ có dấu cách, ký tự đặc biệt, chữ có dấu, ngày 29 tháng 2, độ dài đúng bằng giới hạn và thừa một ký tự.
- Trạng thái không mong đợi: Mất mạng giữa lúc gửi. Phiên đăng nhập hết hạn rồi mới bấm lưu. Dữ liệu bị người khác sửa trong lúc mình đang xem.
Ba hướng này áp dụng được cho gần như mọi chức năng, và chúng là chỗ lỗi tụ nhiều nhất — vì lập trình viên khi viết mã thường nghĩ về đường đi đúng trước.
Nói lại một câu
Test case không phải bản ghi những gì bạn đã bấm. Nó là bản chỉ dẫn để người khác kiểm lại được kết luận của bạn.
Viết xong, đọc lại và tự hỏi: người chưa biết chức năng này có chạy được không? Không chắc thì chưa xong.
