Khi một đơn hàng đi qua biên giới, số lượng nơi xuất hiện trong cùng một bản ghi tăng lên nhanh chóng. Đây là lý do nhóm kịch bản xuyên biên giới thường phát hiện những lỗi mà biểu mẫu nội địa không bao giờ chạm tới. Vấn đề không nằm ở việc thu thập thêm dữ liệu, mà ở việc chốt xem dữ liệu nào là chuẩn khi các nguồn không khớp nhau.
Một đơn hàng xuyên biên giới có bao nhiêu quốc gia?
Câu trả lời phụ thuộc vào việc bạn đang xét lớp thông tin nào, và đó chính là chỗ dễ nhầm. Trong một đơn hàng điển hình, có thể có nơi đặt hàng, nơi thanh toán, nơi nhận hàng, và nơi xuất phát của hàng hoá. Bốn lớp này có thể trỏ tới bốn nơi khác nhau, và không lớp nào tự động quyết định ba lớp còn lại.
Thêm vào đó còn có các lớp phụ. Đơn vị vận chuyển có thể có quốc gia đăng ký riêng. Nhà cung cấp dịch vụ thanh toán có thể xử lý giao dịch ở một nơi khác với nơi in trên hoá đơn. Thiết bị mà người dùng đang dùng cũng có thể đang ở một nơi khác hoàn toàn, và đôi khi hệ thống ghi nhận cả thông tin đó.
Vì vậy mô hình dữ liệu cần nhiều hơn một trường quốc gia. Nếu bạn dùng một trường duy nhất và ghi đè lên nó mỗi khi có lớp mới, thông tin cũ sẽ mất, và rất khó để tái hiện lại một đơn hàng đã xử lý.
Điều cần chốt là mỗi lớp thông tin phải có trường riêng và nhãn rõ ràng. Nhãn này không chỉ để hiển thị mà còn để phân xử khi có tranh chấp về sau.
Khi nơi thanh toán khác nơi nhận hàng thì lấy bên nào làm chuẩn
Đây là câu hỏi gây ra nhiều lỗi nhất, và câu trả lời đúng không nằm trong dữ liệu mà nằm ở mục đích của từng phép kiểm tra. Hệ thống của bạn cần trả lời ít nhất ba câu hỏi khác nhau, và mỗi câu hỏi có một bên chuẩn khác nhau.
| Câu hỏi cần trả lời | Bên thường là chuẩn | Lý do |
|---|---|---|
| Địa chỉ này phải được viết theo quy ước nào | Nơi nhận hàng | Đây là nơi bưu phẩm thật sự phải tới |
| Loại giấy tờ nào được chấp nhận | Nơi thanh toán | Giấy tờ gắn với bên chịu trách nhiệm thanh toán |
| Đơn vị tiền tệ của đơn là gì | Nơi giao dịch | Giá trị được chốt tại nơi giao dịch được thực hiện |
Bảng này chỉ là cách tổ chức phổ biến, không phải quy tắc bắt buộc cho mọi hệ thống. Điều bắt buộc là bạn chọn một cách và ghi nó thành một quy tắc đọc được, thay vì để mỗi phần trong hệ thống tự quyết.
Sai lầm phổ biến là dùng nơi nhận hàng làm chuẩn cho mọi thứ. Cách này hoạt động trong phần lớn trường hợp, nhưng khi nơi thanh toán nằm ở một nơi có quy định khác, hệ thống sẽ kiểm tra giấy tờ theo quy ước của một nơi không liên quan.
Ngược lại, dùng nơi thanh toán làm chuẩn cho địa chỉ giao hàng sẽ tạo ra rất nhiều bưu phẩm bị trả lại. Địa chỉ được viết theo quy ước của một nơi, còn nơi giao hàng lại đọc nó theo quy ước khác.
Vì sao điện thoại, tiền tệ và múi giờ phải xét riêng
Ba trường này thường bị gộp vào cùng một cục với quốc gia, và mỗi lần gộp như vậy là một lần sinh lỗi. Chúng khác nhau ở chỗ chúng có thể được xác định bởi những nơi khác nhau trong cùng một đơn hàng.
Số điện thoại trong đơn xuyên biên giới thường thuộc về người đặt hàng, không phải người nhận. Vì vậy nó phải đi theo nơi đặt hàng hoặc nơi liên hệ, chứ không phải nơi giao hàng. Nếu bạn suy nó từ nơi giao hàng, bạn sẽ gửi thông báo tới một nơi không liên quan.
Tiền tệ thì gắn với giao dịch, và một đơn hoàn toàn có thể được báo giá bằng một loại tiền nhưng thanh toán bằng loại khác. Đây là chuyện bình thường trong thương mại xuyên biên giới, và hệ thống phải lưu cả hai giá trị nếu cả hai đều quan trọng với nghiệp vụ.
Múi giờ là trường dễ bị bỏ sót nhất. Nó không phải là quốc gia, và một số nơi có nhiều múi giờ bên trong cùng một lãnh thổ. Việc lưu múi giờ theo quốc gia sẽ sai ngay khi có đơn hàng ở những nơi như vậy.
Cách xử lý chung là để từng trường có nguồn gốc riêng, và ghi rõ nguồn gốc đó trong mô hình dữ liệu. Khi ba trường này tách nhau, việc kiểm thử cũng trở nên rõ ràng hơn nhiều.
Một số nơi còn có quy định riêng cho mã bưu chính và số giấy tờ; phần đó được nói kỹ hơn trong các bài thuộc chuyên mục địa chỉ và danh tính, nên ở đây chỉ cần nhớ rằng chúng không dùng chung một quy tắc.
Tên quốc gia dài và địa chỉ dài làm hỏng những chỗ nào
Đây là nhóm lỗi giao diện, và chúng xuất hiện nhiều hơn khi có yếu tố xuyên biên giới. Tên của một số nơi dài hơn nhiều so với những tên quen thuộc, và địa chỉ ở một số nơi có nhiều dòng hơn mức mà giao diện đang chừa chỗ.
Vài chỗ thường vỡ:
- Bảng danh sách có cột tên quốc gia bị cắt cụt, khiến hai dòng khác nhau trông giống nhau.
- Hoá đơn in ra bị tràn lề, và phần bị mất đúng là phần phân biệt nơi này với nơi khác.
- Nhãn trong biểu mẫu bị xuống dòng, làm lệch toàn bộ bố cục của các ô phía dưới.
- Thông báo qua thư điện tử bị đứt dòng ở giữa tên, khiến người nhận đọc sai.
- Địa chỉ được ghép thành một dòng bị dài quá giới hạn cho phép, và bị cắt ở nơi quan trọng.
Cách kiểm thử là dùng một tập tên dài và một tập địa chỉ nhiều dòng, rồi xem chúng ở mọi chỗ hiển thị. Nên kiểm tra cả chế độ xem trên màn hình nhỏ, vì đây là nơi việc tràn dòng xảy ra sớm nhất.
Một điểm nữa là đừng cắt chuỗi bằng cách đếm ký tự. Cùng một số ký tự có thể chứa lượng thông tin rất khác nhau, và cách cắt như vậy sẽ phá vỡ những tên mà người dùng cần đọc đầy đủ.
Vì sao không hỗ trợ giao hàng và sai định dạng phải được nói khác nhau?
Hai tình huống này trông giống nhau ở chỗ biểu mẫu đều không cho đi tiếp, nhưng nguyên nhân và cách xử lý khác hẳn. Trộn chúng vào một thông báo sẽ khiến người dùng không biết phải làm gì.
Không hỗ trợ giao hàng là một giới hạn của nghiệp vụ. Người dùng không thể sửa bằng cách nhập lại, và điều họ cần biết là hệ thống không phục vụ nơi đó. Sai định dạng là một vấn đề của dữ liệu nhập, và người dùng có thể sửa nếu được nói rõ chỗ cần sửa.
Ngoài ra còn một tình huống thứ ba thường bị gộp vào: dữ liệu của nơi đó chưa được hệ thống xử lý đầy đủ. Đây không phải lỗi của người dùng, cũng không phải giới hạn nghiệp vụ, mà là một khoảng trống cần được ghi nhận và theo dõi riêng.
Trong kiểm thử, hãy tạo ca cho cả ba tình huống và kiểm tra thông báo hiển thị. Ba thông báo phải khác nhau, và mỗi thông báo phải gợi ý được bước tiếp theo. Một thông báo chung chung sẽ khiến người dùng thử lại vô ích.
Cũng nên kiểm tra xem thông báo nào được ưu tiên khi nhiều điều kiện cùng đúng. Một đơn vừa không được hỗ trợ giao hàng vừa có dữ liệu chưa đúng định dạng sẽ nhận thông báo nào, và thứ tự đó cần được quyết định có chủ ý.
Phần dành cho nhà phát triển: viết rõ bên nào là chuẩn
Nếu chỉ giữ được một việc từ bài này, hãy giữ việc ghi rõ bên nào là chuẩn cho từng phép kiểm tra. Đây là thứ khiến các lỗi xuyên biên giới trở nên dễ sửa hơn rất nhiều.
Vài điểm nên chốt:
- Cho mỗi lớp thông tin một trường riêng, kèm nhãn nói rõ nó là nơi nào.
- Ghi thành tài liệu bên nào là chuẩn cho địa chỉ, giấy tờ và tiền tệ.
- Không suy số điện thoại, tiền tệ hay múi giờ từ trường quốc gia giao hàng.
- Tách ba loại thông báo: không hỗ trợ, sai định dạng, và chưa xử lý được.
- Kiểm tra giao diện bằng một tập tên dài và địa chỉ nhiều dòng ngay từ đầu.
Để thử tay, bạn có thể mở danh mục quốc gia và vùng lãnh thổ và xem cách từng nơi được trình bày, ví dụ Hoa Kỳ. Các đơn hàng, địa chỉ và trường thông tin nêu trong bài đều là ví dụ hư cấu do bài tự dựng để minh hoạ luồng xử lý; chúng không mô tả bất kỳ giao dịch thật nào và không được dùng làm căn cứ cho quyết định nghiệp vụ.
Bước tiếp theo
Hãy lấy một đơn hàng đã xử lý và liệt kê tất cả các nơi xuất hiện trong đó. Bạn sẽ thường tìm ra ít nhất một trường đang bị ghi đè. Sau đó, bài quốc gia và ngôn ngữ khác nhau giải thích vì sao định dạng dữ liệu phải đi theo vùng chứ không theo ngôn ngữ, còn bài vùng nhỏ và mã đặc biệt nói về những nơi mà dữ liệu địa chỉ thường được xử lý sai.