A checkout address test matrix for real form behavior
Build a small matrix for field requirements, localization, and recoverable validation errors.
Start with field behavior, not country count
Choose cases that exercise required versus optional values, a long street, a unit, a missing postal code where allowed, and non-Latin characters. One country with meaningful boundary cases can reveal more than many duplicate happy paths.
Keep a compact scenario matrix
Example: valid baseline; missing required locality; optional unit omitted; postal code with a leading zero; accented or local-script name; invalid separator; server rejection with values retained.
Case Input Expected Baseline Boston / MA / 02108 Accepted Leading zero ZIP 02108 Value remains 02108 Optional unit Unit omitted No unit error Required locality City empty Inline city error; other values remain Unicode Québec Characters preserved
Check interaction and accessibility
Verify persistent labels, keyboard order, inline error association, focus after failure, and that translated field names do not overflow a narrow viewport. Avoid clearing the user’s values when a correction is needed.
Separate checkout from fulfillment
A successful checkout form test proves that the application accepted its inputs. Use the carrier sandbox for shipping rules and synthetic fixtures only for application behavior.