US Address Form Test Cases: A Copy-Ready QA Checklist

Good US address form test cases cover empty required fields, apartment and suite numbers in line 2, two-letter state codes, ZIP codes with leading zeros stored as text, ZIP+4 format, city-state-ZIP mismatches, PO Boxes, APO/FPO military addresses, US territories, length limits, and special characters. Use fictional addresses, never real customer data.

This post turns that list into 30 test cases with an ID, an input, and an expected result. You can paste the table into TestRail, Jira, or a spreadsheet and adapt it to your own rules.

Scope note: This checklist is for testing your own software in development or staging. The sample addresses are fictional. They can't receive mail and won't pass real address, identity, or payment verification. Don't use them to sign up for services or get around any checks.

If you need help preparing the test data itself (fixtures, why real addresses are risky, how to build a set quickly), read our companion guide: US Address Test Data for Checkout Forms. This post focuses on the test cases.

How to use this checklist

The cases assume a typical US address form with five fields:

• Address line 1 (required)
• Address line 2 (optional: apartment, suite, unit)
• City (required)
• State (required, dropdown or text)
• ZIP code (required, 5 digits or ZIP+4)

Your product may have different rules. For example, you may block PO Boxes for shipping, or you may not ship to territories. That's fine. Keep the case, and change the expected result to match your rule. A test case that says "rejected with a clear message" is just as useful as one that says "accepted".

For each case, check three things: what the user sees, what gets saved, and what gets sent to downstream systems (shipping, tax, CRM).

Required fields and empty states

Start with the simple failures. They catch more bugs than you'd expect.

• Each required field empty. Leave line 1, city, state, and ZIP empty one at a time. Each should show its own error next to the field, not one generic message at the top.
• Spaces only. Type three spaces into line 1. Many forms check "not empty" but forget to trim, so a blank address gets saved.
• Values kept after an error. Fill everything, leave ZIP empty, and submit. After the error, the other fields should still hold what the user typed.
• Line 2 empty. Line 2 is optional. Submitting without it must work and must not save the word "null" or "undefined".

Street line 1 and line 2

Street fields need to accept the messy text real people type.

• Unit formats. Test "Apt 4B", "Ste 210", "Unit 7", and "# 12" in line 2. All should be saved exactly as entered.
• Unit typed in line 1. Enter "120 Sample Ave Apt 3" in line 1. Decide whether you split it or keep it, and make sure nothing is cut off.
• Apostrophes and hyphens. "45 O'Brien St" and "12-14 Test-Hill Rd" are valid. Check that the apostrophe isn't escaped twice ("O'Brien") on the confirmation page or in emails.
• Length limit. Find your limit (often 35, 50, or 100 characters). Enter exactly the limit, then one more. The form, the database column, and the shipping label API should all agree.
• Unicode. Try "88 Peña Blvd". Accents should save and display correctly. If your carrier needs ASCII only, convert it on purpose instead of breaking it by accident.

City and state

• Two-letter code vs full name. If the state is a dropdown, the label can say "California" but the value sent to the API should usually be "CA". Check the network request, not just the screen.
• District of Columbia. "DC" is not a state, but it's a valid address. Make sure it's in the list.
• US territories. Puerto Rico (PR), Guam (GU), and the US Virgin Islands (VI) use US ZIP codes. Decide if you support them. If you don't, show a clear message instead of a broken form.
• City with spaces or punctuation. "Salt Lake City", "St. Louis", and "Winston-Salem" should all save as typed.

ZIP and ZIP+4

ZIP codes cause more data bugs than any other field.

• Leading zeros. Many Northeast ZIP codes start with 0, for example in Connecticut, Massachusetts, and New Jersey. A ZIP like "06103" must stay "06103". If it's stored as a number, it becomes "6103". See sample addresses on the Connecticut page and the Massachusetts page.
• ZIP+4. "12345-6789" is valid. Test with and without the hyphen ("123456789") and decide which you accept.
• Bad characters. Letters, spaces, and symbols ("1234A", "12 345") should be rejected with a clear message.
• Wrong length. Four digits, six digits, and "12345-67" should be rejected.
• ZIP doesn't match state. A ZIP starting with 9 (West Coast) with state "NY" is suspicious. Decide whether to warn, block, or allow, and test that behavior.

Special addresses

• PO Box. "PO Box 1234", "P.O. Box 1234", and "Post Office Box 1234". If you block PO Boxes for some carriers, test all common spellings.
• APO/FPO/DPO. Military addresses use "APO", "FPO", or "DPO" as the city and "AA", "AE", or "AP" as the state. If you sell to military families, these must work.
• Rural route. "RR 2 Box 15" is an older format that still appears. It shouldn't break your street parser.

Data round-trip

Many bugs happen after the form, not in it.

• Database to screen. Save an address with line 2 and a leading-zero ZIP. Reload the account page. Both should be unchanged.
• CSV and Excel export. Export orders to CSV and open the file in Excel. Excel often turns "06103" into "6103". Check the raw CSV too, and consider quoting ZIP values.
• Autocomplete overwrite. If you use an address autocomplete, type a line 2 value, then pick a suggestion. The suggestion should not wipe out line 2.
• Edit and resave. Change only the city on a saved address. Every other field should stay the same.

Sample test case table

All inputs below are fictional. Replace the expected results with your own rules where needed.

ID	Case	Input	Expected
ADDR-01	Line 1 empty	Line 1 = ""	Field error on line 1; form not submitted
ADDR-02	City empty	City = ""	Field error on city
ADDR-03	State empty	State not selected	Field error on state
ADDR-04	ZIP empty	ZIP = ""	Field error on ZIP
ADDR-05	Spaces only	Line 1 = " "	Treated as empty; error shown
ADDR-06	Values kept after error	All filled except ZIP	Error on ZIP; other fields keep values
ADDR-07	Line 2 optional	Line 2 = ""	Accepted; saved as empty, not "null"
ADDR-08	Apartment in line 2	Line 2 = "Apt 4B"	Saved and shown exactly
ADDR-09	Suite in line 2	Line 2 = "Ste 210"	Saved and shown exactly
ADDR-10	Hash unit	Line 2 = "# 12"	Saved; no HTML or URL encoding issues
ADDR-11	Apostrophe	Line 1 = "45 O'Brien St"	Saved and shown without extra escaping
ADDR-12	Hyphen in number	Line 1 = "12-14 Test-Hill Rd"	Accepted
ADDR-13	Max length	Line 1 at limit	Accepted; not cut in DB or label
ADDR-14	Over max length	Line 1 at limit + 1	Blocked with message, or input stops
ADDR-15	Unicode	Line 1 = "88 Peña Blvd"	Saved and shown correctly
ADDR-16	State value	State = California	API receives "CA"
ADDR-17	DC	City = Washington, State = DC	Accepted
ADDR-18	Territory	State = PR, ZIP = 00901	Accepted, or clear "not supported" message
ADDR-19	City with punctuation	City = "St. Louis"	Saved as typed
ADDR-20	Leading-zero ZIP	State = CT, ZIP = 06103	Saved as "06103"
ADDR-21	ZIP+4 with hyphen	ZIP = 12345-6789	Accepted
ADDR-22	ZIP+4 no hyphen	ZIP = 123456789	Accepted and normalized, or rejected by rule
ADDR-23	Letters in ZIP	ZIP = 1234A	Rejected with message
ADDR-24	Short ZIP	ZIP = 1234	Rejected with message
ADDR-25	ZIP/state mismatch	State = NY, ZIP = 97205	Warning or block, per rule
ADDR-26	PO Box spellings	Line 1 = "P.O. Box 1234"	Same handling as "PO Box 1234"
ADDR-27	Military address	City = APO, State = AE, ZIP = 09012	Accepted if supported
ADDR-28	Rural route	Line 1 = "RR 2 Box 15"	Accepted; parser doesn't fail
ADDR-29	CSV export	Order with ZIP 02108, Line 2 "Unit 7"	CSV keeps "02108" and line 2
ADDR-30	Autocomplete keeps line 2	Type line 2, then pick suggestion	Line 2 not erased

Generating test data

The cases above need a steady supply of realistic but fictional addresses. The USA Dizhi US address generator creates US-formatted sample records (street, city, state abbreviation, ZIP, and phone) for free. It's useful when you need many rows quickly:

• Use state pages, such as California, to get addresses for a specific state.
• Use city pages, such as New York, for city-level samples.
• If your form also accepts Canada, the Canada address generator helps you test postal codes like "K1A 0B1".

Generated records are for testing only. Please read the disclaimer before use.

FAQ

Should a ZIP code field be numeric?

No. Store ZIP codes as text. A numeric field drops leading zeros, so "02108" becomes "2108". On mobile, you can still show a number keypad with inputmode="numeric" while keeping a text field.

What is a valid ZIP+4 format?

Five digits, a hyphen, and four digits, for example "12345-6789". Many forms also accept nine digits without the hyphen and add it before saving.

Do I need to support APO/FPO addresses?

If you ship to US military members or their families, yes. These addresses use APO, FPO, or DPO as the city and AA, AE, or AP as the state.

Is Address Line 2 required?

Usually not. But when the user fills it in, it must be saved and passed to shipping. A lost line 2 often means a lost package.

Can I use real addresses for testing?

It's best not to. Real addresses in test systems, screenshots, and bug tickets are personal data and create privacy risk. Fictional data is safer and easier to share.

Will generated addresses pass address verification?

No, and they shouldn't be used that way. Generated addresses are for testing your own forms. Don't use them for address verification, identity checks, sign-ups, or payments.