How to Test Forms in Mobile and Web Apps (Complete Guide)

Forms are where users enter data and where input validation either saves them or blocks them. Good forms are fast, forgiving, and accessible. Bad forms leak data, misvalidate, and drive abandonment. T

Forms are where users enter data and where input validation either saves them or blocks them. Good forms are fast, forgiving, and accessible. Bad forms leak data, misvalidate, and drive abandonment. This guide covers the test matrix for any form, from 1-field sign-up to 30-field onboarding.

Why forms fail

• Validation happens server-side only (slow, bad UX)
• Errors shown after submission, user must hunt for the bad field
• Required fields not labeled as required
• Phone / postcode / SSN format not locale-aware
• Keyboard does not match field type
• No resumable state (force-close → start over)
• Copy-paste does not work (password managers break)
• Submit button spammable (duplicate submissions)

What to test — baseline

1. All fields render and accept input
2. Labels associate with inputs (accessibility)
3. Required fields marked visibly and programmatically (required attribute, accessibilityLabel includes "required")
4. Keyboard matches field (numeric for phone, email for email, password for secrets)
5. Auto-fill works (autocomplete attributes, iOS key chain, Android auto-fill)
6. Placeholder is not used as label (disappears on focus)

Validation

1. Inline validation on blur or after short delay
2. Error message specific to the failure ("Email must contain @", not "Invalid")
3. Error linked to the field programmatically (aria-describedby)
4. Errors announced by screen reader on submit
5. Server-side validation backs up client-side (never trust client)
6. Field format validation per locale (US vs UK postcode, phone prefix, etc.)

Submission

1. Submit button disabled until form is valid (optional but user-friendly)
2. Submit button disables after first tap (no duplicate submission)
3. Loading state visible during submit
4. Success state clear — navigation, confirmation, or inline success message
5. Failure state preserves field values (user does not retype email)

Specific field types

Email

1. Accepts name+tag@example.com, unicode@domain.com, all RFC-5321 valid formats
2. Rejects no-at.com, empty string, whitespace
3. Case-insensitive on the domain part

Phone

1. Accepts international format (+country code)
2. Strips non-digits on validate
3. Locale-aware default country
4. Rejects obviously invalid (too short, all zeros)

Password

1. Minimum length enforced (12+ in 2026)
2. Complexity requirements clear up-front, not surprise-on-submit
3. Show/hide password toggle present
4. Paste enabled (disabled paste breaks password managers)
5. Password strength indicator present for signup
6. No max-length trimming (truncated passwords = broken accounts)

Date

1. Date picker for date fields, not free text
2. Date format matches locale
3. Min/max range enforced (no future birth dates)

Address

1. Auto-fill from saved addresses (platform-level)
2. ZIP/postcode validation against country
3. State/province populated based on country

File upload

1. Type restrictions enforced (only accept what you accept)
2. Size limit enforced client + server
3. Upload progress visible
4. Cancel works mid-upload

Accessibility

1. Tab order logical (top-to-bottom, left-to-right)
2. Focus visible throughout
3. Error summary at top for long forms (screen reader reaches it first)
4. Form labels at 200% zoom not truncated
5. Touch targets ≥ 48dp on mobile
6. Dynamic type respected

Edge cases

1. Force-close mid-form — state preserved (draft autosave)
2. Device rotation — state preserved
3. Network drop on submit — queued or retry with clear messaging
4. Very long text (10k chars) in text fields — either accepted or limit clearly stated
5. Special characters (emoji, unicode) preserved through to server
6. Simultaneous edits from two devices — last-write-wins or conflict UI

How SUSA tests forms

SUSA's flow detector auto-identifies forms (≥2 input fields with submit) and drives them with persona-appropriate data:

• adversarial: invalid input, injection attempts, boundary values
• elderly: careful, checks touch target sizes and readability
• accessibility_user: TalkBack / VoiceOver narration, keyboard nav
• impatient: rapid input, missing-field tolerance

Flow verdicts (PASS / FAIL) capture whether the form submission succeeded and led to expected state change.

susatest-agent test myapp.apk --persona adversarial --steps 100

Common production bugs

1. Email validation rejects valid emails (rejects + sign in local part)
2. Password truncated silently at 50 chars, login fails later
3. Phone format breaks for international numbers (US-only validator)
4. Submit double-fires on slow network, duplicate records
5. Required fields not announced to screen readers

Forms are the highest-interaction surface in most apps. Test them per persona, automate the boundary cases, manual-check the accessibility.