How to test a form before people fill it in

The first failure often happens before the form shows. An embed from another company loads late or gets blocked, and the box stays empty. Next, a required field rejects real input, such as O'Brien or a phone number with spaces, and says only 'Invalid'. Then submit hangs or fails without a message. Last, the page shows a thank you while the confirmation email never arrives. The owner rarely sees this, because they type their own details on a desktop with autofill on.

• Does the form show on a phone, with no console errors and no blocked embed?
• Does each error sit beside the field it is about, and name what to change?
• Do O'Brien, a phone number with spaces and an email with a plus sign get through?
• After submit, is there a clear success message, or a redirect to a page that loads?
• Does the confirmation email arrive, and does its link open a page that exists?

Start with an empty submit. Every required field should say it is required, beside the field, before anything is sent. Then send the entries real people type: a name with an apostrophe or a hyphen, a phone number with spaces, an email with a plus sign. Finish with one normal entry on a phone. Repeat the run in a private window, so saved details do not fill the form for you. Keep the browser's developer tools open: the Console lists script errors, and the Network tab lists each request the form sends, with its status code.

A problem that shows at the end often started two fields earlier, with a value that passed the first check and failed on the server. Write down the field and the step where each problem first appears, not only the message at the end. Then run the same entries again after the fix, so you can see the field pass and the next one stop.

Test the signup flow

Each cause leaves a different trace. If no request is sent when you press submit, the browser stopped the form, so the fault is a field rule or the button handler. If a request returns 400 or 422 and names a field, the server rejected a value, and that message is the one to fix. A 500 status, or a request that never returns, is a server fault. A 200 response with no success message on the page is a front end problem. An empty embed box with a failed script in the Console is a blocked embed, and the person to call is whoever installed it.

A run sends visitors through the form on phones and laptops, with a task such as sending a question and finding the confirmation email. Each visitor has an email address with a working inbox, so the confirmation reaches it. The run reports where each visitor stopped, with the field, the console errors and a screenshot. It does not read your CRM, email tool or analytics, so check where leads land yourself. It does not predict how many real people would submit. A CAPTCHA marks the visitor as blocked by the site. A checkout form stops at the payment step, and no real payment is made.

Test a site before launch

Forms change when someone adds a required question, edits a field or swaps the embed. The same visitors can run again after each change, to show whether the fix worked. Behind a login, or on every preview deploy, the same run catches a broken form before it goes live.