Testing error handling on a submitted form

Test a form's errors by deliberately submitting missing, invalid and unavailable information. Check whether the message tells the respondent what to fix and preserves their work.

Submit a valid response and confirm the success state is unmistakable. A form is not ready just because its happy path works.

Make a small failure matrix

List every required field and validation rule. Try leaving each required field empty, entering the wrong format and exceeding a stated limit.

If the form includes a file upload, test a blocked file type and an oversized file. If it has conditional questions, follow each branch and check that a required field on a hidden route does not trap the respondent.

W3C's form notification guidance recommends clear feedback near the affected field and overall feedback after submission. An error such as “Invalid input” gives little help; “Enter a date in day/month/year format” points to a correction.

Colour alone is a weak signal, so the message should be readable as text.

Effective vs. Ineffective Error Messages

Inspect what happens after Submit

For each invalid case, ask four questions:

Repeat with a valid submission. Look for a clear success message and, if the process promises one, a receipt or reference.

Check whether the response actually appears in the destination system. A decorative “Thank you” screen is not proof that an integration received the data.

Google provides help on fixing common errors while responding to a Google Form. Such errors show why tests need the actual respondent context. A form owner signed in to the right account may miss a failure an external respondent sees.

Test the environment, not just the fields

Open the published form on a narrow screen and with a keyboard. Try a slow connection or interruption if the submission is important enough to justify that check.

Avoid deliberately sending sensitive information in test submissions. Record the form version, device, browser, account state, input and observed result so a failed case can be reproduced.

If a failed submission loses a long response, consider shortening the form, adding a draft-saving route if the product supports it, or giving an alternative contact method. Do not claim a feature exists until the chosen product and plan have been checked.

Re-run the failure matrix after changing validation or branching rules; those edits can create new dead ends.