Form Validation Testing
Every field is a contract between the user and the system. Learn the 10-point universal pattern to test any form field systematically — with real NZ data.
1 The Hook — Why This Matters
In 2021, a major NZ retailer launched a new online checkout. The "Phone Number" field had client-side validation: it showed a green tick for anything with 10 digits. But the backend expected the number in a specific format with no spaces. When a customer typed 021 555 0123 — perfectly valid in New Zealand — the frontend smiled and said "Looks good!" while the backend crashed with a database constraint error.
The result? Orders were lost. Payments were taken but fulfilment systems had no contact number. The customer service team spent three weeks manually reconciling orders. The fix was one line of code: .replace(/\s/g, ''). The cost of finding it late? Estimates started at $200,000 in staff time and lost revenue.
A junior tester who knew the 10-point universal test pattern would have caught this in the first hour. That is what this page teaches.
2 The Rule — The One-Sentence Version
Never trust the frontend alone. Test every field against all ten dimensions, then bypass the frontend and test the backend directly.
Frontend validation is for user experience, not security. It can be bypassed in under 30 seconds: open DevTools, disable JavaScript, or send a raw POST request. Every validation rule must exist on the backend. Your job is to verify that it does.
3 The Analogy — Think Of It Like...
A nightclub with two bouncers.
The door bouncer checks your ID, dress code, and whether you're on the list. The bar bouncer inside checks you're not already drunk and that your ID is real, not a photo on a phone. Form validation testing is like testing both bouncers independently. If you only test the door bouncer, sneaky guests will hop the fence (disable JavaScript), use fake IDs (malformed API requests), or slip in through the staff entrance (direct POST calls). The bar bouncer — your backend — is the last line of defence.
4 Watch Me Do It — Step by Step
Here is a systematic walkthrough of the Universal 10-Point Test Pattern applied to a single field: Email on an NZ registration form. The spec says: "Required. Must be a valid email format."
- Required Submit the form with the email field left empty. The system must reject it with a clear message.
-
Format
Test valid format (
user@example.com) and invalid formats:notanemail,user@,@domain.com, double @, and spaces. - Length Test minimum (1 character) and maximum (254 characters per RFC 5321). Most systems cap at 100–255.
-
Type
The HTML5
type="email"attribute helps, but does not replace testing. Browsers vary in what they accept. - Boundary If the spec says "maximum 50 characters," test exactly 50 and exactly 51. Use BVA at the character limit.
-
Special characters
Test dots, plus signs, underscores, and hyphens:
user.name+tag@example.co.nz. These are all valid. -
Empty / null
Submit
null,undefined, or an empty string directly to the API. The backend must reject it. -
Whitespace
Test leading and trailing spaces:
user@example.com. The system should trim or reject, never crash. -
Copy-paste
Paste from Microsoft Word with smart quotes:
“user@example.com”. Smart quotes break many parsers. - Backend bypass Disable JavaScript, edit the DOM in DevTools, or send a direct API call with curl. If the backend accepts invalid data, you have found a security bug.
| # | Dimension | Test input | Expected result |
|---|---|---|---|
| 1 | Required | (leave empty) | Rejected: "Email is required" |
| 2 | Format valid | user@example.co.nz | Accepted |
| 3 | Format invalid | notanemail | Rejected |
| 4 | Format invalid | user@ | Rejected |
| 5 | Format invalid | @domain.com | Rejected |
| 6 | Format invalid | user@@domain.com | Rejected |
| 7 | Type / length | 251-character string | Rejected: too long |
| 8 | Special chars | user.name+tag@example.co.nz | Accepted |
| 9 | Whitespace | user@example.com | Accepted (trimmed) |
| 10 | Copy-paste | "user@example.com" (smart quotes) | Rejected or cleaned |
| 11 | Backend bypass | POST {"email": null} | Rejected: 400 Bad Request |
if (email.valid) on the frontend but forgetting NOT NULL on the database column creates a silent data loss bug that only appears when JavaScript is disabled.
| Field type | Valid NZ test data | Invalid / boundary test data |
|---|---|---|
| Phone (mobile) | 021 555 0123, 022 123 4567, 027 000 1111 | 021, 021555012399999, CALL-MEBRO |
| Phone (landline) | 04 555 0123, 09 555 0123 | 04, 0455501239999 |
| Phone (toll-free) | 0800 123 456, 0508 123 456 | 0800, 08001234569999 |
| Phone (intl) | +64 21 555 0123 | +64, +6421555012399999 |
| IRD Number | 10-000-000, 123-456-789 | 1234567, 1234567890, abcdefghi |
| Postcode | 0110, 6011, 8011 | 01, 60111, abcde |
| Address (macrons) | Te Whanganui-a-Tara, Tūranganui-a-Kiwa | Test Unicode handling |
5 The Decision Tool — When to Use It
✅ Use form validation testing when...
- You are testing any form with user input
- A new form field is added or changed
- Backend validation rules were modified
- You are doing a security review
- The form handles money, identity, or legal data
- You suspect client-side and server-side rules are out of sync
❌ Don't use it when...
- The form is read-only display with no input fields
- Only CSS styling changed (no logic impact)
- The change is purely front-end label text
- You are doing purely visual regression testing
- The form is generated by a framework with built-in validation you cannot influence
Before you test form validation, ask:
- Does your form have complex validation logic with multiple fields?
- Are there client-side and server-side rules that might be out of sync?
- Do you understand all the validation interactions (blur, submit, async)?
6 Common Mistakes — Don't Do This
🚫 Only testing the happy path
I used to think: If the form accepts one valid email, the field works.
Actually: The happy path tells you the feature exists. It does not tell you the feature is robust. Professional testers spend 80% of their time on edge cases. One valid phone number proves the field works once. It does not prove it rejects invalid input, handles spaces, survives copy-paste from Word, or blocks SQL injection.
🚫 Trusting client-side validation
I used to think: The green tick from the frontend means the data is safe.
Actually: Frontend validation is for user experience, not security. It can be bypassed in under 30 seconds: open DevTools, disable JavaScript, or send a raw POST request with curl. Every validation rule must exist on the backend. Your job is to verify that it does.
🚫 Forgetting to test bypass methods
I used to think: Testing each field in isolation is enough.
Actually: Individual field validation is necessary but not sufficient. A form with five valid fields might still fail when they interact: submitting with all fields empty at once, fixing one field and resubmitting, or using the browser Back button after a successful submit. Test the form, not just the fields. And always test the backend bypass.
When form validation testing fails
Missing validation interactions (email after blur, async server-side validation) that run at unexpected times. Also, forms with client-side validation but no server-side protection are vulnerable to bypass attacks. Backend validation must mirror frontend rules.
7 Now You Try — NZ Event Registration
Scenario: You are testing an NZ event registration form. The "Attendee Name" field has this spec: "Required. 2–50 characters. Letters, spaces, and hyphens only."
Your task: Using the 10-point pattern, list at least four test cases for this field. Include one required test, one length boundary, one special character test, and one backend bypass.
Suggested test cases for "Attendee Name":
| Dimension | Test input | Expected result |
|---|---|---|
| Required | (empty) | Rejected: "Name is required" |
| Length (min) | A | Rejected: "Name must be at least 2 characters" |
| Length (max boundary) | 51-character string | Rejected: "Name must be 50 characters or fewer" |
| Special characters | John@Doe | Rejected: "Only letters, spaces, and hyphens allowed" |
| Valid with hyphen | Anne-Marie | Accepted |
| Unicode / macron | Kahurangi | Accepted (if Unicode supported) |
| Backend bypass | POST {"name": null} | Rejected: 400 Bad Request |
Tip: The macron test is critical for NZ forms. If the backend database uses Latin-1 instead of UTF-8, a name like Kahurangi will be corrupted or rejected. Always test Unicode on localised systems.
8 Self-Check — Can You Actually Do This?
Click each question to reveal the answer. If you got all three, you're ready to practice.
Q1. Why must you test backend validation even if the frontend has a green tick?
Frontend validation can be bypassed by disabling JavaScript, using browser DevTools to edit the DOM, or sending direct API requests with tools like curl or Postman. The backend is the only layer that cannot be circumvented by the user, making it the true security and data-integrity gatekeeper.
Q2. Name three NZ-specific test data values you should have in your toolkit.
Any three of: 021/022/027 mobile prefix, 04/09 landline prefix, 0800/0508 toll-free, +64 international format, IRD number format (8–9 digits), NZ bank account (BB-BBBB-AAAAAAA-SSS), 3–4 digit postcode, or Maori macrons (Te Whanganui-a-Tara) for Unicode testing.
Q3. A form has a "Quantity" field with spec: "1 to 99, whole numbers only." What is the minimum set of test values?
EP gives three partitions: below valid (invalid), valid range (1–99), above valid (invalid). 2-value BVA tests the boundaries: 0 (just below), 1 (minimum), 99 (maximum), 100 (just above). Combined minimum set: 0, 1, 50 (mid-range EP), 99, 100. Add type tests: negative (-1), decimal (1.5), and non-numeric ("ten") for completeness.
9 Interview Prep — Know These Cold
These are questions Kiwi employers actually ask junior testers. Have an answer ready.
Q1. Why must you test backend validation even if frontend has it?
Frontend can be bypassed. The backend is the only real defence. Users can disable JavaScript, manipulate the DOM with DevTools, or send direct API calls. If the backend does not independently validate every input, the system is vulnerable to data corruption, injection attacks, and silent failures.
Q2. What HTML5 attributes help with form validation?
required, type (email, url, number, date, tel), pattern (regex), min and max (numeric ranges), minlength and maxlength (string lengths), and step (numeric increments). These improve UX but do not replace server-side validation.
Q3. How do you bypass frontend validation during testing?
Three methods: (1) Disable JavaScript in browser settings. (2) Use DevTools to edit the DOM and remove required or pattern attributes. (3) Send a direct HTTP request to the API endpoint using curl, Postman, or browser Network tab replay. Method 3 is the most reliable because it completely skips the browser layer.
10 Link to Reference
Want the full theory, HTML5 attribute reference, and advanced bypass techniques?
→ Form Validation Testing — Full Reference
Includes the complete 10-point pattern, field-type matrix, and security bypass cheat sheet.
11 Next Step
You now know how to test any form field systematically. The next skill is making sure the error messages themselves are clear, helpful, and accessible when validation fails.