Test scenario thực tế: luồng apply voucher
Đối với voucher có luồng đầu vào khá đa dạng, được chia cơ bản theo các loại như sau:
Voucher giảm trực tiếp giá tiền
- Giảm giá tiền theo loại mặt hàng cụ thể
- Giảm giá tiền tổng đơn hàng
- Giảm giá tiền theo số tiền tối thiểu
- Giảm giá tiền khi sử dụng phương thức thanh toán cụ thể (thẻ ngân hàng, ví điện tử)
- Giảm giá tiền có mức tối đa (đơn hàng từ 200k mới được giảm 50k)
Voucher giảm % giá tiền (10%)
- Giảm giá % loại mặt hàng cụ thể
- Giảm giá % tổng đơn hàng
- Giảm giá % theo số tiền tối thiểu
- Giảm giá % khi sử dụng phương thức thanh toán cụ thể (thẻ ngân hàng, ví điện tử)
- Giảm giá % có mức tối đa (đơn hàng từ 200k mới được giảm 20% tối đa 50k)
Voucher là loại mã dùng riêng hay mã dùng chung
- Mã dùng riêng: 100 mã khác nhau, không mã nào giống mã nào
- Mã dùng chung: 01 mã được dùng với số lượng cụ thể
Voucher có thời hạn sử dụng
- Thời hạn sử dụng từ ngày … đến ngày …
- Trong giai đoạn campaign, game hay event nào đó
Ngoài các case happy case theo yêu cầu, ở đây mình chỉ note thêm một số điểm cần lưu ý, phân tích thêm các unhappy case như sau:
Verify mã voucher và cách thức apply voucher
- Nhập mã voucher sai: sai định dạng, verify chữ hoa, chữ thường, ký tự đặc biệt. Ví dụ: mã voucher có chữ long123, nhập các loại ký tự khác nhau như Long123, L0ng123, LONG123, LoNG123,…. để check xem loại ký tự mã voucher nào được apply.
- Thêm, xóa, sửa nhiều loại voucher khác nhau: đối với trường hợp apply voucher qua cách nhập ký tự khi check thông tin voucher, kiểm tra thêm case xóa voucher nhập lại, nhập voucher, hủy voucher để check lại số tiền cần thanh toán.
- Kiểm tra giới hạn số lần nhập sai voucher, không cho phép nhập sai và thử quá nhiều lần vì có thể dẫn đến các lỗi về bảo mật như đoán mã voucher.
Verify loại voucher được áp dụng theo từng phương thức cụ thể (mặt hàng điện tử, gia dụng, nội thất; phí vận chuyển bình thường, phí vận chuyển dùng phương thức thanh toán khác,…)
- Khi chọn các loại khác nhau mix-match xem có được dùng các voucher của những mặt hàng khác hay phương thức thanh toán khác hay không. Ví dụ: mua hàng điện tử apply voucher hàng nội thất; apply voucher giảm giá qua phương thức thanh toán ví cho đơn hàng thanh toán trực tiếp khi mua hàng.
Verify lại cách tính của giảm giá tiền hoặc giảm % giá tiền
- Đa phần sai sót sẽ rơi vào việc khi nào apply giảm giá, trên tổng đơn tạm tính hoặc là giảm theo từng món hàng cụ thể trên tổng đơn hàng cần thanh toán. Ví dụ: đơn hàng có nhiều loại mặt hàng, chỉ 1 số mặt hàng cụ thể được giảm giá khi apply voucher còn lại là không.
Verify việc count voucher theo logic của luồng business
- Count voucher sẽ được tính khi nhấn áp dụng hay khi gọi phương thức thanh toán, điều này quan trọng vì nó sẽ ảnh hưởng đến số lượng voucher được sử dụng, một số trường hợp gọi phương thức thanh toán nhưng thanh toán thất bại vẫn được tính là đã sử dụng 01 mã voucher.
Verify apply voucher với các loại giảm giá về 0đ hoặc có thể bị âm tiền
- Check các loại voucher khi apply, giá thanh toán về 0đ thì sẽ thể hiện như thế nào, nếu đó là bao gồm cả phí vận chuyển. Một số trường hợp có tích hợp phương thức thanh toán sẽ có mức tối thiểu cần thanh toán, như VNPay là cần tối thiểu 10.000đ, NAPAS cần tối thiểu 1.000đ,…
- Ngoài ra với một số voucher được apply, số tiền cần thanh toán bị âm thì về mặt UX/UI vẫn phải thể hiện nó là giá 0đ, không được show giá âm trên đơn hàng cần thanh toán.
Verify tổng tiền cần thanh toán khi gọi phương thức thanh toán (không tính trường hợp thanh toán khi nhận hàng)
- Một số rủi ro vẫn có thể xảy ra đối với trường hợp khi gọi phương thức thanh toán, số tiền cần thanh toán vẫn chưa giảm khi apply voucher.
Trên đây là một số ý tưởng kiểm thử, các bạn có đóng góp thêm thì bình luận vào bên dưới nhé, cảm ơn các bạn!
Leave a Comment