Form validation testing

Forms are where users give you their data, and where broken validation quietly loses leads, orders and signups. This page lists the edge cases worth trying on every form and a ready test task for your AI beta tester.

Who it’s for

  • Teams with signup, contact, lead or checkout forms
  • Developers who changed validation rules or form libraries
  • Marketers whose lead forms feed a CRM
  • Anyone whose forms have never been tested on mobile

Updated 2026-10-19.

A form can look perfect and still reject valid input (a name with an apostrophe, an international phone number), accept garbage, or lose everything the user typed after one error. Form validation testing tries the inputs real people actually type, not just the ones the developer had in mind, and checks that errors help people fix the problem. It is one of the most useful things a beta tester can do, because forms sit in front of signups, checkouts, contact requests and every setting in your product.

How to run a form validation beta test

  1. List the forms: signup, login, checkout, contact, profile, settings, search, and any multi-step wizard.
  2. Decide what may be submitted for real. Contact and lead forms send emails or create CRM records; agree on a test marker or stop before the final submit.
  3. Fill the happy path first to confirm the form works at all.
  4. Try the edge-case inputs below, one field at a time, then several at once.
  5. Check every error message: where it appears, what it says, when it disappears.
  6. Test submit behavior: data kept after errors, double submit, loading state, success message.
  7. Repeat on a phone to check keyboards, autofill and layout.
  8. File bugs with the exact input used, and retest after fixes.

Inputs worth trying in every field

Text and names

  • Empty: submit with nothing filled in, then with only one field filled.
  • Whitespace: a single space, leading and trailing spaces.
  • Names: apostrophes (O'Brien), hyphens, accents (José), non-Latin scripts, a single letter.
  • Long text: a very long value in short fields and in text areas. Is there a character counter? What happens at the limit?
  • Special characters and emoji in free text fields.

Contact details

  • Email: missing @, two @, missing domain, plus addressing ([email protected]), uppercase, a long but valid address.
  • Phone: with and without a country code, spaces, dashes, brackets.
  • Addresses and postcodes: international formats, apartment numbers, postcodes with letters.

Numbers and dates

  • Numbers: zero, negative, decimals with a comma and a dot, very large values, letters in a number field.
  • Dates: past and future dates, 29 February, different formats, a start date after the end date.

Other inputs

  • Paste: pasting into fields that block paste, or pasting text with line breaks.
  • Password fields: rules shown before typing, show-password toggle, password manager autofill.
  • File uploads: too large, wrong type, several files, and the error shown when a file is rejected.
  • Dropdowns, checkboxes and radio buttons: required ones are enforced, defaults make sense.

Error messages

  1. Shown next to the field they belong to, not only at the top of the page.
  2. Say what to do, not just what went wrong ("Enter an email like [email protected]").
  3. Appear at the right time: not while the user is still typing the first character.
  4. Disappear when the field is fixed.
  5. Are announced to screen readers and not shown by color alone.
  6. Match server-side errors: client and server should agree on what is valid.

Behavior around submit

  • Keep the data: after a failed submit, everything the user typed is still there (except passwords, by design).
  • Double submit: clicking twice should not create duplicates.
  • Loading state: the button shows progress and is disabled while sending.
  • Success: a clear confirmation, and the user knows what happens next.
  • Required markers: required fields are marked before the user submits.
  • Multi-step forms: going back keeps earlier answers, and a refresh does not wipe everything.

Mobile specifics

Check that email, phone and number fields open the right keyboard, that the keyboard does not cover the submit button or the error messages, that the page scrolls to the first error, and that autofill works.

Example bug report

Title: Signup rejects valid names with an apostrophe ("O'Brien")

Environment: Production signup page, Safari on iPhone-size viewport (390px), logged out
Severity: High (some real users cannot create an account)

Steps to reproduce:
1. Open /signup
2. First name: Sean, Last name: O'Brien
3. Email: [email protected], valid password
4. Tap "Create account"

Expected: Account is created
Actual: Error under Last name "Please enter a valid name"; the email field is
also cleared, so the user must retype it

Notes: Same error for "Ana-María" and "Zoë". Server returns 422 with
"invalid_characters", so the rule exists both client and server side
Evidence: Annotated screenshot of the error, screen recording of the attempt

How to prioritize form findings

  1. Valid input rejected on signup, login or checkout: real users are blocked.
  2. Data loss: forms that clear after an error or on back navigation.
  3. Duplicates and silent failures: double submits, or submits that fail with no message.
  4. Invalid input accepted that breaks something later (bad emails, impossible dates).
  5. Unhelpful or badly timed errors, missing required markers.
  6. Layout and polish.

Common mistakes

  • Testing only with the developer's own name, email and a domestic phone number.
  • Relying on browser validation alone, which differs between browsers and is often unclear.
  • Checking that an error appears, but not whether the user can understand and fix it.
  • Forgetting server-side errors, which often show up as a generic message at the top of the page.
  • Letting test submissions flood a real inbox or CRM.

Manual testing vs an AI beta tester

Real users bring inputs you would never think of, and they tell you when a form asks for too much or feels intrusive. Accessibility needs its own work too: an automated check of labels and error announcements is no substitute for a certified accessibility audit or testing with people who use assistive technology.

An AI beta tester like betatest.ing is well suited to the methodical part. It fills every form it can reach in a real browser and on phone-sized screens, tries the edge-case inputs above, checks error placement, wording and timing, and files each bug with the exact input, steps to reproduce, severity, annotated screenshots and a screen recording. It can repeat the same run on a schedule after every release, so a broken validation rule is caught before users hit it. It submits only what you allow and does not craft requests that bypass the interface or run security attacks.

Forms that send something real

Contact and lead forms send emails, create CRM records or notify a team. Tell your tester whether it may submit them for real, use a test marker in the message, or stop before the final submit.

The test task

What you send your AI beta tester. It works out the steps and tests like a real user.

Find every form on [SITE URL] (signup, login, contact, newsletter, search, settings, checkout fields) and test validation on each. Try: submitting empty; spaces only; invalid emails (no @, two @, no domain) and valid unusual ones ([email protected], uppercase); phone numbers with country codes, spaces and dashes; names with apostrophes, hyphens, accents and non-Latin letters; very long text; special characters and emoji; numbers that are zero, negative or huge. For each, check the error message (placement, wording, timing, whether it clears), whether typed data survives a failed submit, double-clicking submit, and the loading and success states. Repeat the main form at mobile width and check the keyboard type. Submitting rule: [SUBMIT RULE]. Log each bug with the exact input, steps to reproduce and an annotated screenshot, and end with a table of forms and their pass/fail status.

Fill in your details

Here, or later in the chat with your tester.

  • [SITE URL] The site or app to test, e.g. https://example.com
  • [SUBMIT RULE] e.g. "you may submit forms with TEST in the message" or "stop before the final submit"

What the AI beta tester checks

  • Empty and whitespace-only submissions
  • Email, phone, name, number and date edge cases
  • Very long text, special characters and emoji
  • Error message placement, wording, timing and clearing
  • Data kept after a failed submit
  • Double submit, loading and success states
  • Required field markers
  • Mobile keyboards and layout with the keyboard open

What you get

  • Bugs with the exact input that triggered them and steps to reproduce
  • Annotated screenshots of broken or unclear messages
  • A table of every form with pass/fail per check
  • A recording for any bug that is hard to describe

How to run it with betatest.ing

  1. Add your site as a project
  2. Paste the task, fill in the URL and whether forms may be submitted
  3. Send it; the tester tries each edge case in a real browser
  4. Fix the bugs, then ask it to re-test the open ones

Tips

  • Say which forms send real emails or create records, so the tester marks or skips them
  • Test client and server validation separately when you can
  • Keep a list of inputs that broke a form once and re-test them on every release
  • Check international formats if you have users outside your country

Form validation testing: FAQ

Will the tester spam my inbox or CRM?

Only if you allow it. You choose whether it submits for real, marks submissions as tests, or stops before the final submit.

Does it test server-side validation?

It tests what a user can do in the browser, which reaches your server through normal submits. It does not craft requests that bypass the interface or run security attacks.

Which forms does it find?

Every form it can reach from the pages you point it to, including forms behind login when you save a test login in the project.

What makes a good validation error message?

It sits next to the field, says what to do in plain words, appears after the user has had a chance to finish typing, and does not rely on color alone.

Can it test file upload fields?

It can check upload fields for clear limits, accepted types and error messages when a file is rejected. Tell it which test files it may use.

What is the difference between client-side and server-side validation?

Client-side validation runs in the browser and gives instant feedback, while server-side validation checks the data again when it arrives. Both are needed, and they should agree on what is valid, or users see confusing errors after a form seemed fine.

Does form validation testing cover accessibility?

Partly. It checks that errors are next to their fields, not shown by color alone and announced to screen readers. It is no substitute for a certified accessibility audit or testing with people who use assistive technology.

Which forms should I test first?

Start with the forms that block access or revenue: signup, login and checkout. Then test contact and lead forms, then profile and settings forms.

Related beta testing guides

  • Signup flow testing — Signup and onboarding are where most new users decide whether to stay. This page covers what to test in a signup flow, the edge cases teams usually miss, and a test task your AI beta tester can run on your app today.
  • Payment flow testing — A broken payment flow costs revenue every hour it stays broken. This page explains how to test checkout, upgrades and subscriptions safely in test mode, which cases to cover, and a ready task for your AI beta tester.
  • Accessibility testing — Accessibility problems lock real people out of your product, and many of them are easy to find and fix. This page covers the WCAG checks a careful browser pass can do, what it cannot replace, and a ready task for your AI beta tester.
  • Bug report template — A good bug report lets a developer reproduce the problem on the first try. This template has every field that matters and nothing extra. Give it to your beta testers, or ask your AI beta tester to file every bug in exactly this format.
  • Free tool: Test case generator — A table of test cases with steps, data and expected results, edge cases included. CSV and Markdown export.

More in by test type