Kiểm thử thủ công: tìm câu hỏi trước khi viết test case

“Khách có mã giảm giá được giảm tiền ở bước thanh toán.” Yêu cầu nghe đơn giản, nhưng chưa trả lời mã hết hạn được tính theo giờ nào, giảm trên tiền hàng hay cả phí vận chuyển, và chuyện gì xảy ra khi khách sửa giỏ sau khi nhập mã. Viết ngay một danh sách thao tác có thể làm phần chưa rõ ấy biến mất dưới nhiều dòng tài liệu.

Giá trị của kiểm thử thủ công bắt đầu ở chỗ nhận ra những quyết định sản phẩm chưa được nói thành lời. Test case là nơi giữ lại quyết định đã hiểu, để một người khác có thể kiểm tra cùng điều kiện và nhận xét cùng một kết quả.

Khoanh điều có thể mất trước khi khoanh màn hình

Với ví dụ giảm giá, rủi ro không chỉ là nhãn trên giao diện sai. Khách có thể thấy một tổng tiền nhưng đơn hàng lưu tổng khác; mã có thể được dùng lại ngoài điều kiện đã thống nhất. Hãy ghi mục tiêu kiểm tra theo hậu quả: số tiền được giải thích nhất quán, đơn đã tạo giữ đúng giá trị, trường hợp bị từ chối có lý do dễ hiểu.

Từ đó chọn phạm vi cho lần thử đầu. Có thể ưu tiên giỏ một sản phẩm, mã hợp lệ và một đơn thành công, rồi thêm thay đổi số lượng. Chưa kiểm tra mọi tổ hợp không có nghĩa đã quên chúng: danh sách ngoài phạm vi cần hiện rõ, cùng lý do và người tiếp tục xử lý.

Dùng ví dụ để bóc chỗ mơ hồ

Giả sử nhóm đã thống nhất mã chỉ dùng khi tiền hàng từ 500.000 đồng. Ba giỏ 499.999, 500.000 và 500.001 đồng giúp làm rõ ranh giới. Đây là dữ liệu giả định cho bài viết, không phải chính sách của một cửa hàng có thật.

Tiếp theo, thử thêm mã vào giỏ đủ điều kiện rồi xóa một món. Kết quả mong đợi phải nói rõ giảm giá bị gỡ, được giữ hay cần xác nhận lại. Nếu chưa ai quyết định, hãy đặt câu hỏi thay vì tự chọn một đáp án rồi ghi lỗi khi sản phẩm làm khác.

Một bảng nhỏ nối yêu cầu với ví dụ cụ thể thường dễ thảo luận hơn nhiều test case chỉ khác tên dữ liệu. Nó cũng cho thấy những câu hỏi chưa có chủ sở hữu.

Viết để người khác không phải đoán

Test case cần trạng thái ban đầu, dữ liệu, hành động và dấu hiệu kết thúc có thể quan sát. “Kiểm tra mã hoạt động đúng” chưa đủ. “Áp mã vào giỏ đạt ngưỡng; tổng tiền cập nhật theo quy tắc đã duyệt; giá trị ấy được giữ trong đơn sau khi xác nhận” cho người chạy biết phải nhìn ở đâu.

Đừng gộp đăng nhập, đổi địa chỉ, dùng mã và hủy đơn vào một ca nếu chúng kiểm tra những mục tiêu độc lập. Khi một bước sớm thất bại, bạn sẽ không biết phần nào phía sau thực sự chưa được chạy. Những đoạn dùng chung có thể tham chiếu, nhưng điều kiện riêng vẫn phải nhìn thấy.

Chừa một khoảng cho việc không nằm trên giấy

Sau những đường chính, dành một phiên khám phá có câu hỏi rõ: điều gì xảy ra với mã khi khách quay lại, tải lại trang hoặc đổi giỏ ở tab khác? Ghi các nhánh đã đi, dữ liệu và câu hỏi mới ngay trong lúc thử.

Phiên khám phá có thể đổi hướng khi gặp điều bất thường. Nhưng đến cuối cần kể lại được mình đã quan sát gì, thay vì chỉ báo “đã test khoảng một giờ”. Số phút không cho biết những rủi ro nào đã được xem xét.

Báo lỗi bằng khoảng cách giữa hai kết quả

Một báo cáo tốt đặt điều mong đợi và điều thực tế cạnh nhau, kèm bản ứng dụng, trạng thái tài khoản và chuỗi tái hiện ngắn nhất. Ảnh chụp tổng tiền hữu ích; mã đơn thử giúp đối chiếu phần lưu trữ. Dữ liệu nhận diện cần được che trước khi chia sẻ.

Mức ảnh hưởng và thứ tự sửa là hai cuộc thảo luận liên quan nhưng khác nhau. Một nhãn sai có thể làm nhiều khách hiểu nhầm; một lỗi hiếm ở tổng tiền vẫn có hậu quả lớn. Hãy mô tả tác động và điều kiện xuất hiện, để người quyết định có căn cứ.

Kết thúc một lượt kiểm thử bằng ba điều: đã xác nhận gì, còn nghi ngờ gì và chưa kiểm tra gì. Tài liệu do AI gợi ý chỉ là đầu vào để đọc lại; nó chưa trở thành bằng chứng cho tới khi người kiểm thử thực sự quan sát sản phẩm.

Về nguồn tham khảo

Chủ đề tham khảo từ bộ AI Tester Skills. Bài viết và tình huống minh họa được biên soạn lại cho người đọc.