Tóm tắt nhanh:
- Mỗi lượt test phải có mã test, thiết bị, thời điểm, cấu hình và kết quả kỳ vọng rõ ràng.
- Bằng chứng cần nối được product page, cart, checkout, cổng thanh toán, đơn hàng và email xác nhận.
- Luồng thành công chưa đủ; phải thử lỗi thanh toán, địa chỉ không hợp lệ và tình huống hủy hoặc hoàn tiền.
- Không chụp hoặc chia sẻ số thẻ, mã bảo mật, token, secret key và dữ liệu cá nhân không cần thiết.
- Một lỗi chỉ nên đóng khi đã tái hiện, sửa, retest và lưu bằng chứng sau sửa.
kiểm tra checkout trong trial không nên kết thúc bằng ghi chú “đã đặt thử một đơn”. Khi lỗi xuất hiện sau đó, đội kỹ thuật cần biết người test dùng thiết bị nào, đã chọn biến thể gì, tổng tiền thay đổi ở đâu và cổng thanh toán trả về trạng thái nào. Một bộ bằng chứng tốt phải tái dựng được toàn bộ hành trình nhưng vẫn bảo vệ dữ liệu thanh toán và thông tin cá nhân.
Kiểm tra checkout trong trial cần chứng minh điều gì?
Checkout đạt yêu cầu khi khách đúng khu vực có thể đi từ sản phẩm tới xác nhận đơn, nhìn thấy tổng tiền đúng, dùng phương thức thanh toán được hỗ trợ và nhận thông báo phù hợp. Đồng thời, seller phải nhìn thấy đơn cùng trạng thái nhất quán trong admin, cổng thanh toán và hệ thống fulfillment. Chỉ thấy trang “Thank you” chưa chứng minh tiền đã được ghi nhận hoặc đơn đã sẵn sàng xử lý.
BurgerShop hiện hỗ trợ nhiều payment provider mà seller có thể bật cho store. Tài liệu Overview Payment cập nhật ngày 29/5/2026 nhấn mạnh khách sẽ chọn trong những provider đã được kích hoạt. Do đó, phạm vi test phải dựa trên cấu hình thực tế của store, thị trường bán và thiết bị khách dùng, không dựa trên một kịch bản chung cho mọi cổng.
Trước khi bắt đầu, xác nhận rõ đang dùng môi trường test, sandbox hay live. Nếu payment provider có test mode, dùng thông tin test do chính provider cung cấp. Không tự giả định một mã thẻ bất kỳ sẽ không tạo giao dịch thật. Nếu buộc phải chạy giao dịch live giá trị nhỏ, người có thẩm quyền cần duyệt trước chi phí, phương án hủy hoặc hoàn tiền và cách đánh dấu đơn nội bộ.
1. Chuẩn bị hồ sơ test trước khi bấm mua
Mỗi ca test cần một mã riêng, chẳng hạn CHK-MOB-STRIPE-01. Hồ sơ ban đầu nên ghi URL store, phiên bản theme, thời điểm, múi giờ, thiết bị, hệ điều hành, trình duyệt, phương thức thanh toán, quốc gia giao hàng, sản phẩm, biến thể, coupon và kết quả kỳ vọng. Những thông tin này giúp phân biệt lỗi cấu hình với lỗi chỉ xảy ra trên một tổ hợp cụ thể.
Chụp trạng thái cấu hình có liên quan nhưng che mọi bí mật. Có thể lưu tên provider đang bật, currency, shipping zone, tax rule, yêu cầu số điện thoại và coupon áp dụng. Không lưu secret key, API token, mật khẩu, toàn bộ số thẻ hoặc mã CVC trong ảnh, video, ticket hay bảng chia sẻ. Dữ liệu test cũng nên dùng tên, email và địa chỉ được kiểm soát, không mượn thông tin thật của khách.
Trang checkout có thể thay đổi theo cài đặt theme. Theo hướng dẫn BurgerShop ngày 11/6/2026 về trường số điện thoại, seller có thể đặt Phone là bắt buộc hoặc không bắt buộc trong Checkout page của Theme Editor; thay đổi này không tự điều chỉnh shipping, payment provider hay order notification. Vì vậy, ảnh cấu hình và kết quả trên storefront đều cần được lưu, sau đó test lại trên desktop lẫn mobile.
2. Bằng chứng cho product page và cart
Với kiểm tra checkout trong trial, bằng chứng bắt đầu trước checkout. Ở product page, lưu ảnh sản phẩm, tiêu đề, giá, biến thể đã chọn, tình trạng còn hàng, ưu đãi và thông tin giao hàng đang hiển thị. Nếu giá hoặc ảnh đổi theo biến thể, quay một đoạn ngắn hoặc chụp trước và sau thao tác để chứng minh trạng thái.
Ở cart, cần thấy đúng SKU hoặc biến thể, số lượng, giá từng dòng, discount, subtotal và currency. Thử tăng giảm số lượng, xóa sản phẩm, áp dụng coupon hợp lệ và coupon không hợp lệ. Bằng chứng tốt bao gồm cả phản hồi của giao diện, không chỉ con số cuối cùng. Nếu cart lưu trạng thái sau khi tải lại hoặc chuyển thiết bị, ghi rõ điều kiện vì cookie và phiên đăng nhập có thể ảnh hưởng.
Mỗi ảnh nên kèm mã test và thời điểm trong tên file hoặc bảng log. Không dựa vào chuỗi ảnh rời không biết thứ tự. Một dòng log ngắn như “10:21 thêm Size M, giá 29 USD; 10:22 áp mã X, giảm 10%; 10:24 sang checkout” giúp người khác nối hành động với event và log hệ thống.
3. Bằng chứng tại checkout và payment provider
Tại checkout, chụp hoặc ghi lại các trường bắt buộc, địa chỉ giao hàng, phương thức ship, thuế, discount, phí, tổng thanh toán và provider được chọn. Thử một địa chỉ hợp lệ trong vùng bán, một địa chỉ ngoài vùng hoặc thiếu thông tin, và quan sát thông báo lỗi. Lỗi tốt phải nói khách cần sửa gì; lỗi mơ hồ chỉ “Something went wrong” cần được ghi nhận cùng request ID nếu hệ thống cung cấp.
Khi chuyển sang provider, lưu thời điểm, số tiền, currency và trạng thái hiển thị. Sau thanh toán, đối chiếu ba nơi: trang xác nhận của khách, order trong BurgerShop admin và transaction trong dashboard provider. Dùng order ID, provider transaction ID hoặc mã tham chiếu đã che bớt để nối chúng. Không dùng ảnh số tiền đơn độc làm bằng chứng vì nó không xác định được giao dịch.
Nếu provider trả trạng thái bất đồng bộ, chẳng hạn pending trước khi success, ghi cả chuỗi trạng thái và thời gian chuyển đổi. Kiểm tra hành vi khi khách tải lại trang, bấm Back hoặc đóng tab sau khi thanh toán. Mục tiêu là phát hiện nguy cơ tạo đơn trùng, charge trùng hoặc thanh toán thành công nhưng store không nhận trạng thái.
Luồng thất bại cũng phải được kiểm soát
Đừng chỉ test happy path. Dùng kịch bản thất bại chính thức của provider nếu có để kiểm tra thẻ bị từ chối, xác thực không hoàn tất hoặc timeout. Store không được tạo cảm giác đơn đã thành công khi provider từ chối. Thông báo cho khách cần rõ nhưng không tiết lộ chi tiết nhạy cảm; admin phải lưu đủ trạng thái để đội hỗ trợ phân biệt trường hợp có thể thử lại với trường hợp cần chuyển cấp xử lý.
4. Xác nhận đơn, email và hậu kiểm
Sau khi đặt đơn, lưu ảnh order detail với mã đơn, items, shipping, tax, discount, tổng tiền, payment status và fulfillment status. Đối chiếu số tiền với provider, không chỉ với màn hình khách. Nếu store tích hợp fulfillment, kiểm tra đơn đã được chuyển đúng sản phẩm, biến thể, số lượng và địa chỉ hay chưa; chưa cần sản xuất thật nếu mục tiêu chỉ là kiểm luồng.
BurgerShop cho biết email mặc định của store nhận thông báo khi buyer mua hàng. Vì vậy, kiểm tra checkout trong trial nên lưu bằng chứng thông báo tới seller và email xác nhận dành cho địa chỉ test, gồm thời điểm nhận, subject, mã đơn, nội dung chính và các link quan trọng. Kiểm tra cả spam, định dạng mobile và địa chỉ reply-to; che dữ liệu cá nhân trước khi đưa vào ticket.
Với luồng hủy hoặc hoàn tiền, xác định rõ thao tác được thực hiện ở BurgerShop hay provider, trạng thái có đồng bộ không, khách nhận thông báo nào và số tiền thực tế thay đổi ra sao. Tài liệu BurgerShop về migration cũng khuyến nghị test successful payment, failed payment, order confirmation, refund hoặc cancellation, fulfillment và notification email trước khi launch.
5. Hoàn tất kiểm tra checkout trong trial bằng retest
Một ticket checkout nên có tiêu đề mô tả triệu chứng, mã test, mức ảnh hưởng, điều kiện ban đầu, từng bước tái hiện, kết quả kỳ vọng, kết quả thực tế và link bằng chứng. Thêm timestamp cùng order ID hoặc transaction ID đã che phù hợp để kỹ thuật tìm log. Tránh đính kèm toàn bộ video dài nếu chỉ 15 giây cuối cho thấy lỗi; cắt đúng đoạn nhưng giữ bản gốc trong kho có kiểm soát nếu cần.
Sau khi sửa, không chỉ mở lại trang lỗi. Chạy lại toàn bộ ca test trong cùng điều kiện, rồi kiểm một ca gần kề để phát hiện regression. Bằng chứng sau sửa phải thể hiện phiên bản hoặc thời điểm mới. Ticket chỉ được đóng khi kết quả thực tế khớp kỳ vọng và các hệ thống liên quan cùng thống nhất trạng thái.
Khi kiểm tra checkout trong trial hoàn tất, lập bảng bao phủ theo provider, thiết bị, thị trường và loại kết quả. Không cần thử mọi tổ hợp có thể xảy ra; ưu tiên tổ hợp đem lại doanh thu chính và các điểm có rủi ro cao. Những tổ hợp chưa test phải được ghi rõ, không chuyển thành khẳng định “checkout hoạt động trên mọi thiết bị”.
FAQ về lưu bằng chứng checkout
Có cần quay video toàn bộ hành trình không?
Không bắt buộc cho mọi ca. Ảnh theo mốc cùng log thường đủ với luồng chuẩn; video hữu ích khi lỗi liên quan chuyển trang, trạng thái chớp tắt hoặc thao tác khó mô tả. Luôn che dữ liệu nhạy cảm.
Có nên dùng thẻ thật để test?
Ưu tiên test mode và dữ liệu test chính thức của provider. Chỉ dùng giao dịch live khi có lý do, người duyệt, giới hạn số tiền và kế hoạch hoàn tiền. Không ghi lại số thẻ hoặc CVC.
Bằng chứng tối thiểu của một giao dịch thành công là gì?
Ít nhất cần mã test, ảnh tổng tiền trước thanh toán, order ID trong BurgerShop, trạng thái transaction ở provider và thông báo xác nhận. Các phần phải nối được bằng mã tham chiếu và thời gian.
Nếu checkout chỉ lỗi trên một thiết bị thì có cần chặn launch?
Phụ thuộc mức ảnh hưởng và tỷ trọng khách dùng thiết bị đó. Nếu lỗi ngăn thanh toán trên nhóm thiết bị quan trọng, nên chặn. Nếu là lỗi hiển thị nhỏ có workaround, có thể ghi nhận rủi ro và lên lịch sửa.
Nên giữ bằng chứng trong bao lâu?
Giữ theo chính sách nội bộ, yêu cầu bảo mật và thời gian cần đối soát. Chỉ lưu dữ liệu tối thiểu, giới hạn quyền truy cập và xóa hoặc ẩn danh khi hết mục đích.
Kết luận
kiểm tra checkout trong trial có giá trị khi mỗi kết quả đều truy nguyên được từ cấu hình, thao tác, giao dịch đến trạng thái đơn và email. Hãy ưu tiên test mode, bảo vệ bí mật thanh toán, thử cả luồng thành công lẫn thất bại và retest sau sửa. Bộ bằng chứng như vậy không chỉ chứng minh checkout đã chạy, mà còn giúp đội ngũ tìm đúng nguyên nhân khi store gặp lỗi với khách thật.
