Forms turn user data into system actions: registration, orders, profile updates, or file uploads. Testing a form therefore involves more than entering character combinations. Follow the path from input to saved data and a clear on-screen outcome.
Good validation helps people correct errors and protects data integrity. Poor validation frustrates users while allowing invalid requests: it might reject a legitimate surname in the UI yet allow an API record without mandatory consent.
Clarify rules first
Document each field's contract: required status, allowed values, length range, format, normalization, dependencies, and validation timing. Separately identify business rules such as uniqueness, plan availability, valid dates, and role restrictions.
Normalization converts input into an agreed form, such as trimming surrounding spaces. Do not invent it in a test. Spaces can matter in names, and changing password case or Unicode characters can change the secret. Raise ambiguous rules as requirement questions rather than declaring defects based on personal preferences.
Separate client and server checks
Client validation gives rapid feedback before a request. Server validation makes the final decision on whether an operation is allowed. Browser HTML attributes and JavaScript can be bypassed, so UI rejection does not prove backend data protection.
Test the same invalid input through the form and a direct request in a test environment. Expect the agreed server rejection, no created record, and correct UI error handling. The API contract determines the exact HTTP status; there is no universal status for every form.
Select data systematically
Use equivalence classes: groups of inputs expected to behave alike. For a length range of 2–50, check empty input, 1, 2, 50, and 51 characters, plus an ordinary value within the range. This gives explainable boundary coverage.
- →Numbers: minimum, maximum, adjacent values, negative numbers, fractions, and an invalid separator.
- →Dates: nonexistent dates, leap days, period boundaries, and required locale and time-zone behavior.
- →Text: spaces, line breaks, Cyrillic text, composite Unicode characters, pasting, and long values.
- →Selections: no selection, unavailable values, and dependent-list changes after the parent field changes.
Clarify the length unit. Visible characters, code points, UTF-16 units, and bytes can have different counts, especially with emoji.
Test input as an interaction
Users type, paste, autofill, edit the middle of a string, and delete selections. A phone mask that works only with sequential typing may corrupt pasted values. A calendar may accept a date through its widget while handling manual entry differently.
Also check submission by button and Enter, Tab navigation, value preservation after errors, and appropriate mobile keyboards. Placeholders can show examples but disappear during input, so they cannot replace persistent field labels.
Errors should support recovery
Messages should explain what happened and how to correct it. Associate them with the right field, make them understandable without color, and keep them visible long enough to read. Multiple errors need a clear path to each.
Check focus order, accessible field names, and screen reader error announcements. A form-level “invalid data” message may be insufficient for a delivery address. Conversely, login messages that reveal account existence may violate security requirements. Context matters.
Asynchronous checks and races
Username availability, price calculations, and address suggestions arrive after user actions. Enter A, quickly replace it with B, and delay A's response. The old response must not overwrite the current result.
During submission, show the agreed state. Repeated clicks, Enter, and network retries must not create extra business operations. Disabling a button reduces risk, but verify definitive duplicate protection at the operation and server layers.
Practical example: registration
Suppose the contract requires email and a 12–64-character password, preserving password spaces. The account is created when server processing succeeds; losing the response does not imply that no record exists.
- 1.Enter valid data and submit. Expect one new record and a clear next step, such as email confirmation.
- 2.Test password lengths of 11, 12, 64, and 65 through UI and API. Expect consistent boundaries and no invalid records.
- 3.Use an existing email. Expect the contract-defined rejection and retention of other valid fields, except where policy requires clearing secrets.
- 4.Simulate a timeout after submission, then repeat. Expect a defined outcome without a second account or endless loading.
- 5.Complete a failed submission using a keyboard and screen reader. The error should be discoverable and correctable without a mouse.
Files and sensitive data
For file forms, check contract-defined size and type, empty files, interrupted transfers, and repeat uploads. The accept attribute guides selection, but the server must independently validate contents and limits.
Keep real passwords, tokens, and personal documents out of diagnostics. Demonstrate defects with prepared test data and sanitized requests.
Common mistakes and lessons
Common mistakes include checking only required fields, treating a mask as proof of validity, and inspecting messages without actual data state. Arbitrary restrictive email or name patterns without a product requirement are also risky.
Systematic form testing connects contracts, boundaries, input methods, server decisions, and error recovery. Evaluate the complete user journey rather than the number of strings entered.
Further reading
- →MDN: Client-side form validation
- →W3C WAI: Easy Checks, forms and errors
- →OWASP: Web Security Testing Guide
One rule, a concrete input matrix
Training rule: nickname must contain 3–12 ASCII letters. Spaces are rejected rather than silently trimmed; Unicode letters are outside this deliberately narrow exercise. The prepared HTML form is client-only and does not send a request. The API fixture validates the same name rule separately.
Input Expected
(empty) Reject
ab Reject: length 2
abc Accept: length 3
abcdefghijkl Accept: length 12
abcdefghijklm Reject: length 13
abc Reject: leading space
абв Reject: non-ASCII under this ruleFor rejected values, verify a visible error, aria-invalid=true and focus on the invalid field. The error is connected to the input through aria-describedby. For accepted values, require the success status and an empty error. Do not generalize this ASCII-only rule to real names or international products.
Client checks improve feedback but can be bypassed. Send invalid JSON directly to the local API fixture and require rejection there as well. The form and API checks are two distinct tests; this demo does not claim an end-to-end browser-to-API submission.