Các tiêu chí đánh giá website thương mại điện tử nên được kiểm tra bằng những tình huống mua hàng cụ thể. Trước nghiệm thu, hãy đi hết hành trình từ tìm sản phẩm, chọn phiên bản, thanh toán đến xử lý đơn trong trang quản trị. Bài viết tập trung vào nghiệm thu chức năng và vận hành; rà soát pháp lý hoặc chứng nhận cần có phạm vi chuyên môn riêng.
1. Xác định phạm vi và dữ liệu dùng để nghiệm thu
Bắt đầu từ chức năng đã thống nhất trong dự án website thương mại điện tử: phương thức thanh toán, vùng giao hàng, biến thể sản phẩm, mã ưu đãi và kết nối kho. Chức năng chưa được đặt hàng cần được ghi riêng để tránh đánh giá sai phạm vi.
Chuẩn bị dữ liệu DEMO: sản phẩm có nhiều phiên bản, sản phẩm hết hàng và giỏ hàng có nhiều mặt hàng. Dùng thông tin giả lập, không lấy dữ liệu cá nhân của khách thật để minh họa. Mỗi tình huống nên ghi điều kiện ban đầu, thao tác, kết quả mong đợi và bằng chứng thực tế.
Các quy định về phí giao hàng, đổi trả hoặc ưu đãi phải dùng nội dung đã được doanh nghiệp duyệt. Nhóm kiểm thử xác minh hệ thống thực hiện đúng quy định đó.
2. Khách có tìm được đúng sản phẩm không?
Đi từ menu đến danh mục, thử bộ lọc rồi mở trang sản phẩm. Kiểm tra tên, ảnh, phiên bản, tình trạng hàng và thông tin giá có nhất quán hay không. Khi chọn phiên bản khác, giao diện cần thể hiện rõ khách đang mua lựa chọn nào.
Thử tìm kiếm với tên đầy đủ, tên ngắn và từ không có kết quả. Ghi nhận cách website hướng dẫn khách tiếp tục. Khi quay về danh mục, kiểm tra hành vi giữ bộ lọc theo thiết kế đã thống nhất.
Google hướng dẫn cấu trúc website thương mại điện tử nên có liên kết từ danh mục đến sản phẩm cần được tìm thấy; Googlebot thường không nhập truy vấn vào ô tìm kiếm. Vì vậy, hãy kiểm tra cả đường đi qua danh mục, thay vì chỉ tìm được sản phẩm bằng ô tìm kiếm.
3. Giỏ hàng có tính đúng khi khách thay đổi lựa chọn?
Thử thêm sản phẩm, tăng giảm số lượng, xóa một mặt hàng và quay lại mua tiếp. Sau mỗi thao tác, đối chiếu phiên bản, số lượng, giá và tổng tiền. Nếu có ưu đãi, kiểm tra điều kiện áp dụng theo cấu hình đã được duyệt.
Mã hợp lệ, mã hết hạn và mã không đáp ứng điều kiện cho kết quả gì?
Khi đổi địa chỉ hoặc phương thức giao hàng, phí và tổng tiền có cập nhật?
Khi hàng không còn đủ, khách có biết cần thay đổi lựa chọn nào?
Thông tin giỏ hàng có còn đúng sau khi tải lại trang?
Ghi rõ thời điểm giá được xác nhận. Nếu giá hoặc tồn kho thay đổi trong lúc khách mua, hành vi mong đợi cần được thống nhất trước khi kết luận đạt hay chưa đạt.
4. Thanh toán có xử lý cả thành công và thất bại?
Kiểm tra biểu mẫu với dữ liệu đầy đủ, thiếu trường bắt buộc và sai định dạng. W3C khuyến nghị hướng dẫn biểu mẫu làm rõ trường bắt buộc, trường tùy chọn và định dạng dữ liệu. Khách cần hiểu phải nhập gì trước khi gửi.
Với thanh toán trực tuyến, chuẩn bị các tình huống thành công, bị từ chối, khách hủy và kết quả chưa được xác nhận. Khi quay về website hoặc tải lại trang, kiểm tra có tạo đơn trùng hoặc hiển thị sai trạng thái thanh toán không.
Hướng dẫn đơn hàng thử của Shopify minh họa việc dùng chế độ thử để kiểm tra quy trình đặt hàng. Cách thực hiện phụ thuộc nền tảng và nhà cung cấp thanh toán. Shopify cũng lưu ý khách không thể đặt đơn thật khi nhà cung cấp thanh toán đang ở chế độ thử; cần kiểm soát môi trường và khôi phục cấu hình phù hợp trước vận hành.
Minh họa DEMO do AI tạo; giao diện và dữ liệu giả định, không phải kết quả đo hay hệ thống của khách hàng.
5. Đơn hàng có đi đúng tới bộ phận xử lý?
Sau mỗi đơn thử, mở trang quản trị để đối chiếu mặt hàng, số lượng, phí, địa chỉ giả lập và trạng thái thanh toán. Kiểm tra thông báo theo đúng kênh nằm trong phạm vi, đồng thời xác nhận người vận hành biết tìm đơn cần xử lý.
Nếu có kết nối kho hoặc tự động hóa nghiệp vụ, theo dõi cùng một đơn qua từng hệ thống. Khi kết nối lỗi, ai thấy cảnh báo và thao tác nào được phép thử lại? Đơn hàng cần có dấu vết để đối chiếu, tránh xử lý lặp.
Trong tình huống DEMO, một đơn đã ghi nhận trên website nhưng chưa đồng bộ sang kho. Tiêu chí cần kiểm tra là người vận hành nhận biết được trạng thái, có hướng xử lý và xác minh đồng bộ lại không tạo bản ghi trùng. Đây là ví dụ giả lập để xây dựng bài thử.
6. Kiểm tra di động, quyền truy cập và thông tin tìm kiếm
Trên điện thoại, thử chọn phiên bản, mở giỏ hàng, nhập địa chỉ và sửa lỗi biểu mẫu. Kiểm tra bằng bàn phím để xem người dùng có tới được các trường và nút quan trọng. Ghi thiết bị, trình duyệt và bước xảy ra lỗi.
Dùng tài khoản thử thuộc từng vai trò để kiểm tra quyền xem, sửa và xuất dữ liệu theo thiết kế đã duyệt. Nhân viên xử lý đơn cần thao tác đúng phần được giao. Đây là một nhóm kiểm tra chức năng; phạm vi đánh giá an toàn hệ thống cần được xác định riêng.
Nếu triển khai dữ liệu có cấu trúc Product, đối chiếu với thông tin sản phẩm hiển thị. Tài liệu Product của Google giải thích dữ liệu này có thể giúp thể hiện thông tin như giá và tình trạng hàng trên tìm kiếm. Cần kiểm tra dữ liệu thực tế, không đưa đánh giá hoặc chính sách chưa có cơ sở vào phần đánh dấu.
7. Chốt nghiệm thu bằng bằng chứng và người chịu trách nhiệm
Mỗi lỗi nên có bước tái hiện, kết quả mong đợi, kết quả thực tế và ảnh hoặc video đã loại bỏ thông tin riêng tư. Những vấn đề làm sai tiền, mất đơn hoặc lộ dữ liệu cần được ưu tiên xử lý. Hai bên phải thống nhất điều kiện phát hành phù hợp với rủi ro còn lại.
Hồ sơ cuối gồm danh sách tình huống đã chạy, kết quả kiểm tra lại, cấu hình bàn giao, hướng dẫn vận hành và đầu mối xử lý sự cố. Đối chiếu với quy trình triển khai website để xác định phần việc hoàn tất và phần còn chờ.
Nếu đang chuẩn bị dự án, bạn có thể trao đổi với CuongDesign về luồng mua hàng cần kiểm tra. Danh sách nghiệm thu nên được xây dựng từ cách doanh nghiệp bán và xử lý đơn, rồi cập nhật khi phạm vi thay đổi.