Browse the Knowledge Hub32 resources
Test cases
Form validation test cases, applied to any form
Twenty seven cases written as rules rather than one product flow: required and whitespace handling, length and numeric boundaries, paste behaviour, client and server parity, disabled and hidden field tampering, cross field and conditional rules, error announcement and mobile keyboards.
All 27 test cases, ready to copy
Free to use and adapt, no sign-up. Download as CSV or Markdown, or copy it straight into your own tooling.
Last updated
27 worked examples
Submit a valid form
TypeFunctionalPriorityHigh- Test data
- Every field completed within its rules
- Expected result
- Accepted, stored exactly as entered after documented trimming, and a clear success state shown.
Submit with every required field empty
TypeNegativePriorityHigh- Test data
- All fields blank
- Expected result
- Blocked, an error against each required field, focus moved to the first one, and an error summary where the form is long.
Submit a required field containing only whitespace
TypeBoundaryPriorityHigh- Test data
- Three spaces, then a tab, then a non breaking space
- Expected result
- Treated as empty and refused. A non breaking space pasted from a document is a real and confusing case.
Verify when validation fires
TypeFunctionalPriorityMedium- Test data
- Type a partial email, then leave the field, then correct it
- Expected result
- Errors appear on blur or on submit rather than on every keystroke, and clear as soon as the value becomes valid. Validating mid typing tells users they are wrong before they have finished.
Verify values are preserved after a failed submission
TypeStatePriorityHigh- Test data
- A long form with one invalid field
- Expected result
- Every other value is retained, including selections and uploads. Clearing a form on failure is the fastest way to lose a completed submission.
Check minimum and maximum length boundaries
TypeBoundaryPriorityHigh- Test data
- Minimum minus one, minimum, maximum, maximum plus one
- Expected result
- Inside the range accepted, outside refused with the limit stated. Maximum length is enforced on paste as well as on typing.
Paste a value longer than the field allows
TypeBoundaryPriorityHigh- Test data
- Paste 5000 characters into a 255 character field
- Expected result
- Refused or truncated with a visible message, never silently cut so the user submits something different from what they pasted.
Enter invalid characters in a numeric field
TypeNegativePriorityHigh- Test data
- Letters, spaces, 1e5, --5, 1,000, 1.2.3, and a leading plus
- Expected result
- Refused with a clear message, or normalised by a documented rule. Exponent notation reaching a currency field is a genuine defect.
Check numeric boundaries and signs
TypeBoundaryPriorityHigh- Test data
- Zero, negative, the maximum allowed, one above it, and a value beyond the integer limit
- Expected result
- Enforced server side. Quantity and amount fields must refuse negatives explicitly rather than relying on the input control.
Check decimal precision on money fields
TypeBoundaryPriorityHigh- Test data
- 10.005, 10.999, a value with four decimal places, and a locale using a comma separator
- Expected result
- Rounded or refused by a documented rule, and the stored value matches what is displayed to the currency minor unit.
Validate email formats
TypeBoundaryPriorityHigh- Test data
- [email protected], an address at the length limit, user@, user@domain, and two at signs
- Expected result
- Valid unusual formats accepted, malformed refused. Over strict patterns that reject plus addressing are a defect, not a safeguard.
Validate phone and postcode by country
TypeBoundaryPriorityMedium- Test data
- International prefix, spaces and brackets, a country with no postcode system
- Expected result
- Normalised consistently, and a country without postcodes is not blocked by a required field.
Enter names with punctuation and non Latin characters
TypeBoundaryPriorityHigh- Test data
- O'Brien, Anne-Marie, a single character name, non Latin scripts, and an emoji
- Expected result
- Accepted and stored without corruption. Rejecting apostrophes or non Latin characters excludes real people and is a real defect.
Attempt script and SQL payloads in text fields
TypeSecurityPriorityHigh- Test data
- <script>alert(1)</script>, ' OR 1=1 --, template expressions, and an HTML entity
- Expected result
- Stored safely and rendered as visible text everywhere it later appears, including admin views, exports and emails.
Bypass the browser and post invalid values directly
TypeSecurityPriorityHigh- Test data
- A request violating every client rule at once
- Expected result
- The server refuses with the same rules and returns errors mapped to the correct fields. Client validation is convenience only.
Submit values for disabled and read only fields
TypeSecurityPriorityHigh- Test data
- A request including a field that the interface disables, and one that is display only
- Expected result
- Ignored or rejected. Disabled in the markup is not a permission, and this is the classic mass assignment route.
Tamper with hidden fields
TypeSecurityPriorityHigh- Test data
- Modify a hidden identifier, price, role or step token
- Expected result
- Validated against the session and the server record rather than trusted because it was on the page.
Verify cross field rules
TypeFunctionalPriorityHigh- Test data
- End date before start date, confirm value not matching, total not equal to the sum of parts
- Expected result
- Refused with the error against the field the user can fix, and enforced on the server as well as in the browser.
Verify conditionally required fields
TypeFunctionalPriorityHigh- Test data
- Toggle the condition on, fill the dependent field, toggle it off, then submit
- Expected result
- The dependent field is required only while the condition holds, and a value entered then hidden is either cleared or deliberately retained rather than being submitted invisibly.
Verify server errors map to fields
TypeFunctionalPriorityHigh- Test data
- A rule only the server knows, for example an address that fails verification
- Expected result
- The message appears against the relevant field, not only as a banner, and the form remains completed and editable.
Submit the form twice quickly
TypeStatePriorityHigh- Test data
- Double click submit, then resend the request
- Expected result
- One record created. The control disables while in flight and the endpoint is idempotent.
Navigate away from a partly completed form
TypeStatePriorityMedium- Test data
- Change fields, then close the tab, press back, and follow an internal link
- Expected result
- An unsaved changes warning where the design promises one, and consistent behaviour across all three routes.
Verify autofill and password manager behaviour
TypeCompatibilityPriorityMedium- Test data
- Browser autofill on address and card fields, plus a generated password
- Expected result
- Autofilled values pass validation, autocomplete attributes are correct, and paste is not blocked.
Verify the character counter and trimming rules
TypeFunctionalPriorityMedium- Test data
- A field at its limit including trailing spaces and an emoji
- Expected result
- The counter matches what the server counts, including multi byte characters, and trimming happens consistently in both places.
Verify errors are announced to assistive technology
TypeAccessibilityPriorityHigh- Test data
- NVDA or VoiceOver with a deliberately invalid submission
- Expected result
- Errors are programmatically associated with their fields, announced on submission, and the error summary is focusable and links to each field.
Verify errors do not rely on colour alone
TypeAccessibilityPriorityHigh- Test data
- View the invalid state in greyscale and at 200 per cent zoom
- Expected result
- Text and an icon accompany the colour, contrast meets the standard, and the message stays visible when the layout reflows.
Verify the form on a mobile keyboard
TypeCompatibilityPriorityMedium- Test data
- Numeric, email and phone fields on iOS and Android
- Expected result
- The correct keyboard type appears, the focused field is not hidden behind the keyboard, and the next control is reachable from it.
What goes in each field
ID
RequiredStable identifier, prefixed by module.
Test case
RequiredWhat is being verified, in one line.
Type
Functional, negative, boundary, security, state, performance, accessibility or compatibility. Use it to check coverage is spread rather than clustered on the happy path.
Priority
Risk based. Any rule enforced only in the browser is High, because the endpoint behind it is the real interface. Message wording and timing are Medium unless the field is legally or financially significant.
Test data
The specific values, including the invalid and boundary ones.
Expected result
RequiredThe precise observable outcome, including message text where the wording itself is the requirement.
Send the request without the form
Everything the browser prevents, the endpoint usually allows. That is the whole test in one sentence.
Post every rule violation at once
One request breaking all client rules. The server should refuse with errors mapped to fields, not accept and store it.
Include the disabled fields
Disabled and read only in markup is presentation. Sending those keys is the classic mass assignment route.
Paste, do not type
Length limits enforced on keystrokes are routinely bypassed by paste, and silent truncation submits something the user never saw.
Fail one field on a long form
If the other twenty values are lost, users abandon. This is the highest impact validation defect there is.
The validation gaps worth writing down
Parity between the browser and the server is the whole game. Client validation exists to help a person; server validation exists to protect the data. When a rule lives only in the browser, the endpoint accepts anything, and every downstream consumer inherits the mess. Post one request that violates every rule at once and assert both the refusal and that each error is attached to the field it belongs to.
Disabled and hidden fields are where authorisation quietly leaks into validation. A price, a role, an identifier or a workflow step token that the interface disables is still just a key in a request body. Send it modified and confirm the server recomputes or refuses rather than trusting it because it was rendered on the page.
Over strict rules are a real defect class rather than a safe default. Rejecting apostrophes and hyphens in names excludes people, rejecting plus addressing in email breaks a legitimate and widely used pattern, and blocking paste in password fields actively discourages strong credentials. Each of those is a bug worth raising.
The most expensive defect on any long form is losing what somebody typed. Fail one field and check that every other value, including selections and uploaded files, survives. Users who lose fifteen minutes of input do not report it, they leave.
Suggest an improvementForms carrying revenue or compliance?
QAble tests validation at both layers, in the interface and against the endpoint, including the tampering cases that never appear in a browser.
Functional testing servicesMore test case sets
View allTest cases for a login page
Test cases25 cases across functional, negative, boundary, security, session and accessibility paths, including account enumeration and lockout.Test cases for a registration form
Test cases28 cases covering validation, duplicate accounts, email verification, password rules and the enumeration leak most signup forms ship with.Test cases for search functionality
Test cases28 cases across relevance, partial and fuzzy matching, filters, pagination, empty states, injection attempts and performance under load.Test cases for a shopping cart
Test cases27 cases on quantity limits, price recalculation, stock changes, coupon stacking, guest to account merge and cart persistence.Test cases for checkout and payment
Test cases30 cases including 3D Secure, declines, timeouts, duplicate charges, idempotency, refunds and partial captures.Test cases for file upload
Test cases28 cases on size and type limits, spoofed content types, malicious filenames, progress, resume, virus scanning and storage limits.Test cases for forgot password
Test cases26 cases on reset token expiry, single use enforcement, session invalidation and the enumeration and rate limit gaps that are routine here.Test cases for OTP verification
Test cases26 cases on expiry, resend throttling, attempt limits, code reuse, delivery failure and the brute force window teams forget to close.Test cases for user roles and permissions
Test cases26 cases on horizontal and vertical privilege checks, direct object access, role changes mid-session and permission inheritance.Test cases for a date picker
Test cases26 cases on timezone shifts, ambiguous day and month order, impossible dates, min and max limits, leap years and keyboard operation.Test cases for pagination
Test cases24 cases on ordering stability, records changing mid-session, page size caps, deep offset cost, permission-filtered totals and state restore.Test cases for push notifications
Test cases26 cases on app states, deep link routing, token release on sign out, lock screen privacy, preferences, provider failures and platform differences.Test cases for reports and data export
Test cases25 cases on permission filtering in the file, spreadsheet formula injection, encoding, typed numbers and dates, row limits and audit logging.Test cases for a chatbot
Test cases28 cases on paraphrased intents, context, fallback loops, human handoff, policy grounding, prompt injection and data scoping.Sources
- OWASP ASVS verification requirements for authentication, session and access control.
- WCAG 2.2 the success criteria behind the accessibility cases.
- WAI-ARIA Authoring Practices expected keyboard and screen reader behaviour for widgets.
Want validation tested where it actually matters?
QAble covers functional, security and accessibility paths together with ISTQB-certified engineers. Start with a free QA audit.