Website form testing checklist: developer QA guide

A website form is part of the product path, not just a group of inputs. Test the complete path from the first label to the success state. A form that looks correct can still lose values, hide errors, submit twice, or send users to the wrong route.

Use this website form testing checklist before launch and after changes to validation, authentication, routing, or backend responses.

Confirm the form contract

Write down what the form should do before testing it:

1. Which fields are required?
2. What values does each field accept?
3. Where does the data go?
4. What does success look like?
5. What should happen when the server fails?

This gives every test a result to compare with. Include the normal path, invalid input, an empty submission, a slow response, and a failed request.

Check labels and input semantics

Every field needs a visible label that describes its value. Connect the label and input with matching for and id attributes. Use the correct input type and autocomplete hint so browsers and assistive technology can provide useful controls.

<label for="email">Work email</label>
<input id="email" name="email" type="email" autocomplete="email" required>
<p id="email-error">Enter a valid email address.</p>

If an error exists, connect it with aria-describedby and expose the error in a way that a keyboard and screen-reader user can find. Do not use placeholder text as the only label. The value disappears when the user types and may be too low contrast.

Run the form with the keyboard. Tab through the controls in a logical order, type a value, open any select or date control, and submit with Enter. The focus indicator should remain visible.

For more detail, use the accessibility checks before launch guide.

Test validation at both ends

Client-side validation improves feedback, but the server must validate again. Send malformed, missing, too-long, and unexpected values directly to the endpoint in a safe test environment. Never trust a browser check as a security boundary.

For each invalid value, check that the form:

• Identifies the field with the problem.
• Explains the expected format in plain developer-friendly language.
• Keeps valid values the user already entered.
• Moves focus to the first actionable error when appropriate.
• Does not expose stack traces, tokens, or internal details.
• Lets the user correct and submit again.

Avoid clearing the entire form after one validation error. Preserve work unless the product has a clear reason to discard it.

Test loading, success, and failure states

Prevent duplicate submissions while the request is in flight. The submit control needs a clear pending state and should not let a double click create two records. Restore the control when the request fails.

Test these outcomes:

• A successful response shows a confirmation or sends the user to the correct route.
• A redirect keeps the expected state and does not loop.
• A server validation response maps to the right field.
• A timeout gives the user a retry path.
• A network failure does not claim success.
• Refreshing the success route does not submit the form again.
• The browser back button does not lose an important result without warning.

Check the browser console and network panel while testing. A form can display a success message while its request returns an error or a follow-up request fails.

Test the narrow viewport

Open the form on a real phone or a narrow browser viewport. Check that labels, errors, controls, and the submit action remain visible. Long validation messages should wrap without pushing the action off screen. The virtual keyboard should not cover the active field or the error message.

Use mobile website testing before launch for the viewport routine. Test landscape when the form includes a wide table, file picker, or multi-column layout.

Check privacy and telemetry

Review the request payload and analytics events. Send only the fields the feature needs. Do not put passwords, access tokens, or sensitive form values in URLs, analytics labels, console logs, or error reports.

Confirm that the consent state, retention message, and support route match the product's actual behavior. If a form collects an email address, test the confirmation and unsubscribe path as part of the same release.

Know what a public audit can test

An automated public URL audit can check whether the form is visible, labeled, reachable, and connected to a measurable first task. It cannot safely complete every backend workflow, know whether a test account should be used, or prove that an email was delivered.

Slop Audit reports the evidence it can observe from the public page. Use its first-task result with your integration and end-to-end tests. When the report points to a missing or unclear action, use the website audit report guide to turn that finding into a release task.

Form sign-off

labels → keyboard path → valid input → invalid input
→ pending state → success → retry → mobile viewport
→ request payload → console and network → production URL

Record the tested route, browser, viewport, build, and result. A short record makes a later form regression easier to reproduce and fix.