Form Validation Testing — Learn How to Test (Junior)

1 The Hook — Why This Matters

A user registers for a NZ government service. They enter their phone number as 021 555 0123 with spaces. The form rejects it because the pattern only accepts digits. They try again without spaces. It works.

But the error message said "Invalid phone number" — not "Remove spaces." The user gives up. The form was "correct" (it rejected invalid input), but the experience was broken.

Form validation testing isn't just about pass/fail. It's about helping users succeed.

2 The Rule — The One-Sentence Version

Test every field systematically: required, format, length, type, boundary. Then test the form as a whole.

Individual field testing finds local bugs. Form-level testing finds integration bugs — like a date range where the "to" date is before the "from" date, or a password confirmation that doesn't match.

3 The Analogy — Think Of It Like...

Analogy

A bouncer at a club.

They check ID (required), photo match (format), expiry date (validity), and age (boundary). But they also need to be polite — a rude bouncer loses customers. In form testing, the error message is the bouncer's tone. A field can be "correctly" rejected while the user experience is ruined.

4 Watch Me Do It — Field-by-Field

Here's how I test each common field type. Use this as a checklist.

Text field
- Empty
- Spaces only
- Special characters (!@#$%)
- Very long (1000+ characters)
- Unicode (Māori macrons: āēīōū)
- Pasted from Word (hidden formatting characters)
Email
- Missing @
- Missing domain (user@)
- Invalid TLD (user@site.c)
- Valid format but fake domain (user@fakeexample12345.co.nz)
- Uppercase (USER@EXAMPLE.COM)
- Plus addressing (user+test@gmail.com)
Phone (NZ)
- Mobile prefixes: 021, 022, 027
- Landline: 03, 04, 06, 07, 09
- Toll-free: 0800
- International: +64
- With and without spaces
- With and without country code
- Invalid prefix (025 — no longer allocated)
Date
- NZ format DD/MM/YYYY
- Leap year (29/02/2024)
- Invalid dates (31/02/2024)
- Past / future boundaries
- Two-digit year (24 vs 2024)
Number
- Negative
- Zero
- Decimal (if integer expected)
- Very large
- Letters mixed in
- Empty
Dropdown
- Empty / default selection
- Invalid value via DevTools
- Multi-select behaviour (if applicable)
Checkbox / Radio
- None selected
- All selected
- Rapid toggle
File upload
- Wrong type (.exe instead of .pdf)
- Too large
- Zero bytes
- Double extension (file.pdf.exe)
- Path traversal filename (../../../etc/passwd)
Password
- Length boundaries (min-1, min, max, max+1)
- Complexity rules (upper, lower, number, symbol)
- Common passwords (Password123!)
- Paste behaviour
- Show / hide toggle

HTML5 Attributes Reference Table:

Attribute	What it does	Input types	QA test
`required`	Field must have value	All	Submit empty
`type="email"`	Enforces email format	Email	Test `notanemail`
`pattern`	Regex validation	Text, tel, etc.	Test pattern mismatch
`min` / `max`	Numeric range	Number, date	Test BVA
`minlength` / `maxlength`	String length	Text, password	Test BVA

🛡 Frontend vs Backend Validation

This is defence in depth. Frontend validation is for user experience — fast feedback, no round-trip. Backend validation is for security — the server must never trust the client. Test BOTH by disabling JavaScript or using direct API calls. If the backend accepts what the frontend rejects, you have a security gap.

5 When to Use It — Decision Tool

✅ Use form validation testing when...

Any form exists (which is always)
A new field is added to an existing form
Validation rules change
You're localising for a new region (e.g., NZ phone formats)
You're doing accessibility testing (error message screen-reader behaviour)

❌ Don't skip it when...

Never — form validation is universal
"It's just a simple form" — simple forms break too
"The framework handles it" — frameworks are configured by humans
"We have client-side validation" — that's only half the story

6 Common Mistakes — Don't Do This

🚫 Testing only valid inputs

I used to think: If the happy path works, the field is fine.
Actually: Most bugs live at the edges. Empty, too long, wrong type, and boundary values are where systems break.

🚫 Trusting client-side validation only

I used to think: The browser stops bad input, so the server is safe.
Actually: Anyone can disable JavaScript or send raw HTTP requests. Backend validation is non-negotiable.

🚫 Ignoring error message quality

I used to think: If the field rejects bad input, the test passes.
Actually: "Invalid phone number" without explaining why causes user abandonment. Error messages are part of the feature.

🚫 Not testing tab order and keyboard navigation

I used to think: Tab order is a "nice to have."
Actually: For keyboard users and screen-reader users, broken tab order makes the form unusable. It's an accessibility bug, not a polish issue.

🚫 Forgetting mobile-specific issues

I used to think: Mobile is the same as desktop, just smaller.
Actually: Numeric keypad vs alphabetic keyboard, autocomplete behaviour, paste suggestions, and zoom-on-focus all behave differently on mobile. Test on real devices.

🚫 Not testing copy-paste behaviour

I used to think: Typing and pasting are the same.
Actually: Pasting from Word, PDFs, or websites can introduce hidden characters, smart quotes, or formatting that breaks validation. Users paste constantly.

🚫 Missing cross-field validation

I used to think: Each field is tested independently.
Actually: Password / confirm-password mismatch, date ranges where "to" < "from", and dependent dropdowns (region → city) are all form-level bugs that field-by-field testing misses.

🚫 Not testing with real screen readers

I used to think: Automated accessibility tools are enough.
Actually: Tools catch markup errors, but only a real screen reader (NVDA, JAWS, VoiceOver) reveals whether error announcements are understandable and timely.

🚫 Assuming empty = invalid

I used to think: Empty fields are always errors.
Actually: Some fields are genuinely optional. An empty middle name is valid. Test the spec, not your assumptions.

🚫 Not testing concurrent submissions

I used to think: One submission at a time is the only real use case.
Actually: Double-clicking a submit button, refreshing on success, or submitting from two tabs can create duplicate records, race conditions, or confusing error states.

7 Now You Try — Registration Form

🎯 Interactive Exercise

Spec: A registration form with fields: Name, Email, Phone (NZ), Date of Birth, Password, Confirm Password.

Your task: List 3 test cases for the Phone field and 3 for the Password field.

Field	Test case	Input	Why it matters
Phone	Valid NZ mobile with spaces	`021 555 0123`	Users naturally type spaces. The system should accept or gracefully guide.
Phone	Invalid prefix	`025 123 4567`	025 is no longer allocated in NZ. Should be rejected with a clear message.
Phone	International format	`+64 21 555 0123`	NZ receives international users. +64 format must work if the spec allows it.
Password	Minimum length boundary	`Ab1!` (if min is 5)	Tests the exact boundary. Should be rejected if min is 5.
Password	Missing complexity	`password`	No numbers or symbols. Tests whether complexity rules are enforced.
Password	Confirm mismatch	Password: `Hello1!` Confirm: `Hello1@`	Cross-field validation. A classic bug that field-level testing misses.

Did you think about error messages? For each rejected input, the message should tell the user what is wrong and how to fix it. "Invalid" is not enough.

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. What's the difference between frontend and backend validation?

Frontend validation runs in the browser and is for user experience — fast feedback, reduced server load. Backend validation runs on the server and is for security and data integrity. The server must never trust the client. Test both by disabling JavaScript or sending direct API requests.

Q2. Why isn't the HTML5 pattern attribute enough for security?

Because pattern is frontend-only. A user can disable JavaScript, modify the DOM, or send raw HTTP requests that bypass the browser entirely. Pattern attributes improve UX but do nothing to protect the server. Backend validation is mandatory.

Q3. What should you test for NZ phone numbers specifically?

Test mobile prefixes (021, 022, 027), landline prefixes (03, 04, 06, 07, 09), toll-free (0800), international format (+64), with and without spaces, and invalid prefixes like 025. NZ numbers have structure — test that the validation respects it without being overly restrictive.