Kiểm thử trước khi PR - Phần 2 - Tư duy tạo test case và checklist khía cạnh kiểm thử

Ở Phần 1, mình đã nói về sự khác nhau giữa Unit Test và Integration Test. Bài này đi vào phần "tay chân" hơn một chút: làm sao để viết test case mà không bị sót ý.

Tư duy tạo test case

Muốn test case toàn diện, cứ bắt đầu từ việc phân tích Đầu vào – Xử lý – Đầu ra, theo 4 bước sau:

1. Xác nhận đặc tả: yêu cầu, thiết kế, API, DB, Figma, ticket
2. Làm rõ đầu vào/đầu ra: cái gì được đưa vào, xử lý ra sao, cho ra kết quả gì
3. Liệt kê các khía cạnh: case thông thường, case lỗi, giá trị biên, phân quyền
4. Xác định phạm vi ảnh hưởng: màn hình liên quan, CSV, email, liên kết bên ngoài

Viết test case theo Given – When – Then

Cấu trúc này giúp ai đọc cũng hiểu giống nhau, ai chạy test cũng ra kết quả đánh giá giống nhau — khỏi tranh luận "test vậy có tính là pass không":

• Given (điều kiện tiên quyết): trạng thái sẵn có trong hệ thống trước khi test. Ví dụ: trường hợp đăng ký bằng email đã tồn tại.
• When (thao tác/đầu vào): thao tác của người dùng hoặc hành động kích hoạt. Ví dụ: khi thực hiện thao tác đăng ký thành viên.
• Then (kết quả mong đợi): phản hồi hoặc thay đổi trạng thái mong đợi. Ví dụ: không lưu vào DB & hiển thị lỗi trùng lặp.

Thử áp dụng vào ví dụ: tính năng đăng ký thành viên

Unit Test:

1. Kiểm tra định dạng email — đầu vào testexample.com → kết quả mong đợi: lỗi định dạng email
2. Giới hạn số ký tự mật khẩu — đầu vào mật khẩu 7 ký tự → kết quả mong đợi: lỗi độ dài ký tự
3. Xác định tài khoản trùng lặp — kiểm tra email đã tồn tại → kết quả mong đợi: lỗi trùng lặp tài khoản

Integration Test:

1. Luồng đăng ký thành viên — nhập dữ liệu tại màn hình và đăng ký → kết quả mong đợi: lưu DB + chuyển hướng đến màn hình thành công
2. Liên kết thông báo email — gửi email đăng ký thành công → kết quả mong đợi: email được gửi đến địa chỉ đã đăng ký
3. Phân quyền & bảo mật — truy cập trang quản trị khi chưa đăng nhập → kết quả mong đợi: chuyển đến màn hình đăng nhập hoặc báo lỗi phân quyền

Checklist nhanh trước khi viết test case

Đọc xong đặc tả, cứ rà qua mấy khía cạnh này một lượt cho chắc:

• Giá trị đầu vào: bắt buộc/tùy chọn, kiểu dữ liệu, độ dài, loại ký tự, định dạng
• Quy tắc nghiệp vụ: trùng lặp, trạng thái, thời hạn, giới hạn số lần
• Phân quyền: trạng thái đăng nhập, vai trò (role), dữ liệu cá nhân/người khác
• Cơ sở dữ liệu: thêm, sửa, xóa, giá trị NULL, transaction
• Màn hình giao diện: nội dung hiển thị, thông báo lỗi, chuyển hướng, thao tác quay lại
• Liên kết bên ngoài: thành công, thất bại, timeout, gửi lại, trùng lặp

Đừng chỉ nhìn xem hệ thống "chạy bình thường" có ổn không — quan trọng là cả lúc nó thất bại, phân quyền khác nhau có đúng không, dữ liệu có nhất quán không.

Lỗi này hợp với Unit Test hay Integration Test?

Nhìn lỗi thực tế để đoán xem nên bồi thêm Unit Test hay Integration Test ở đâu: Lỗi phù hợp với Unit Test:

• Công thức tính số tiền bao gồm thuế bị sai
• Regex kiểm tra định dạng email bị sai

Lỗi phù hợp với Integration Test:

• Tên tham số gửi từ Frontend khác với tên nhận ở phía API
• API thành công nhưng không chuyển hướng đến màn hình hoàn tất
• Không gửi được email hoàn tất đăng ký
• Người dùng không có quyền vẫn truy cập được vào màn hình quản trị

Viết được test case rồi, câu hỏi cuối cùng là: làm sao để reviewer nhìn vào PR là biết ngay mình đã test cái gì? Phần 3 (phần cuối) sẽ nói về chuyện đó — cùng với quy trình kiểm thử khi sửa lỗi để tránh lỗi cũ quay lại.