Skip to main content
QA Testing for No-Code & AI-Built Websites·Lesson 4 of 5

Testing Forms & Interactions

Forms are where no-code and AI sites fail most often. The form looks right, but submit it with bad data, submit it twice, or submit it from a mobile device, and it breaks. Here is how to test every interactive element systematically.

The Form Testing Checklist

For every form on the site, run through these scenarios:

Happy Path

  • Fill in all fields with valid data and submit
  • Verify the success state appears (confirmation message, redirect, or email)
  • Verify the data actually arrives at its destination (check the inbox, CRM, or database)

Validation Testing

  • Submit the form completely empty — does validation fire for all required fields?
  • Enter an invalid email format (e.g. notanemail) — does the email field reject it?
  • Enter a phone number with letters — does the phone field validate?
  • Enter a password that's too short — does the password field show an error?

Edge Case Inputs

  • Very long text: Enter 500+ characters in a text field — does the UI handle it?
  • Special characters: Enter <script>alert('test')</script> in a text field — does it display as text or cause a problem?
  • Apostrophes and quotes: Enter O'Brien or "quoted text" — do these break anything?
  • Emoji: Enter 🎉 in a name field — does it save and display correctly?

Double Submission

  • Click the submit button twice quickly — does it submit twice?
  • Does the button disable after the first click?

Network Failure

  • Submit the form with browser DevTools network throttling set to "Offline" — what does the user see? A clear error, or nothing?

Every button and link on the site needs to be clicked:

  • Does it do what it's labelled to do?
  • Does it go to the right page (check the URL)?
  • Is there a visible focus state when you Tab to it with the keyboard?
  • Does it have a hover state?
  • On mobile, is the tap target large enough?

For anchor links (#section-name): do they scroll to the correct position, or do they land at the wrong place (a common bug when sticky headers offset the scroll position)?

Testing Modals and Overlays

  • Does the modal open when triggered?
  • Can you close it by clicking the X button?
  • Can you close it by clicking outside the modal?
  • Can you close it by pressing Escape?
  • Does the background scroll lock when the modal is open?
  • Does focus trap correctly inside the modal (tabbing doesn't focus elements behind it)?

Testing Navigation

  • Does every navigation link go to the correct page?
  • Does the active state update correctly as you navigate?
  • Does the mobile hamburger menu open and close?
  • Are there any links that go nowhere (href="#" with no handler)?

Documenting Bugs

When you find a bug, document it immediately with:

  • What you did: The exact steps to reproduce
  • What happened: The actual result
  • What should have happened: The expected result
  • Screenshot or recording: Visual evidence
  • Severity: Critical (blocks a user completely), Major (significant impact), Minor (cosmetic or low impact)

A bug that's not documented doesn't get fixed.