Testing contact forms so enquiries actually arrive

A contact form fails quietly. When a page breaks, people notice. When a form stops delivering, the site looks exactly the same, and the only symptom is fewer enquiries, which can be mistaken for a quiet month. That is why form testing deserves more care than its simplicity suggests, and why it belongs on every launch and update checklist.

Delivery: the test that matters most

A form that shows "Thank you" has only proved that the page received the data. Whether anyone ever reads it depends on everything after that: the form handler, the mail settings, the sending service, spam filters, and the inbox itself.

• Send a real test from each form with realistic details and a clear label, such as "TEST, please ignore" in the message.
• Find it in the inbox that will be monitored after launch. A developer's address or a test mailbox proves nothing about the real one.
• Check the junk folder if it does not arrive. Messages sent by websites can be flagged as spam when the sending domain lacks the email authentication records mail providers look for.
• Check what arrives. All fields present, special characters intact, a sensible subject line, and a reply-to address that answers the visitor rather than the website.
• Note the time it took. A message that takes an hour to arrive can point to a queue or a mail service problem.

If the site stores submissions as well as emailing them, check the stored copy too, and check who can see it.

Validation and error messages

Validation is how the form tells a visitor what it needs. Test it from the visitor's side:

• Submit with each required field empty in turn. Does the error say which field and what to do?
• Submit an email address without an @ sign, or with a space in it. Is the message specific?
• After an error, is everything the visitor typed still there? Retyping a long message is a reason to give up.
• Are errors shown in text beside the field, not only as a red border? Colour alone is easy to miss and does not reach everyone.
• Does keyboard focus move to the error or to a summary of errors, so the problem is easy to find?

Unusual but valid input

Real names and messages are messier than test data. Each of these should go through cleanly:

• A name with an apostrophe and a fada, such as Seán O'Neill or Siobhán Ní Bhriain.
• An email address with a plus sign or a subdomain.
• An Irish mobile number written with spaces, with +353, or with a leading zero.
• An Eircode in upper or lower case, with or without the space.
• A long message of several paragraphs, including line breaks.
• Text pasted from a word processor, with curly quotes and long dashes.

If a form rejects any of these, it is turning away real people.

Hostile input

Forms attract abuse, so check that the obvious attempts fail safely. This is not a security test, just a sanity check:

• Line breaks in the name or email field should not change who the email goes to. A form that lets a visitor add recipients can be used to send spam.
• HTML or script typed into a field should appear as plain text in the email and anywhere the submission is displayed, never as working code.
• Very long input should be refused or trimmed, not crash the handler.

If any of these succeed, stop testing and report it as a blocker.

Spam protection that does not block people

Spam filtering is a balance. Too little and the inbox fills with junk; too much and real enquiries vanish. Test the protection as a visitor:

• Can you submit on a phone without solving a puzzle you cannot read?
• Does the form work with a keyboard alone, including any challenge?
• If a submission is rejected as spam, does the visitor see a message that offers another way to get in touch, such as an email address?

Quiet techniques, such as hidden honeypot fields and checks on how quickly a form was filled in, block a share of automated spam without asking anything of visitors. They are worth asking your developer about.

Confirmation pages and emails

• The thank-you page or message should say what happens next and roughly when, in words the organisation can stand behind.
• If the visitor receives a confirmation email, check the sender name, the wording, the links, and that it does not repeat sensitive details unnecessarily.
• If you track form submissions in analytics, check that the tracking fires once per real submission, not on page load.

On a phone

Test every form on a real phone. Check that the right keyboard appears for each field (numbers for phone numbers, the email layout for email), that labels stay visible while typing, that the field in use is not hidden behind the keyboard, and that the submit button is reachable without zooming.

Privacy points to check

Forms collect personal data, so a few privacy checks belong in testing:

• The form links to a privacy notice that explains what happens to the data.
• Only the fields you need are required.
• Any consent checkbox for marketing is unticked by default and separate from the act of sending the enquiry.
• The data goes only where the privacy notice says it goes.

These are checks for testers, not legal advice. Your privacy notice and its wording are a matter for whoever is responsible for data protection in your organisation.

Test again after every change

Forms break when things around them change: a CMS or plugin update, a new theme, a move to new hosting, a change of email provider, a new spam filter, or an expired password on the mail account the site sends from. Put "send a test from every form" on the checklist for every one of those events. Our guide to testing after CMS and plugin updates puts this into a short routine.

A form test log worth keeping

Because form failures are silent, a simple log of form tests is a record worth keeping. Each entry needs only a few fields:

When enquiries drop, the log answers the first question anyone asks: when did we last know the form worked? It also shows a pattern if delivery times start to grow, which can be an early sign of a mail problem.

Forms that feed other systems

Some forms do not just send an email. They create a contact in a CRM, add someone to a mailing list, open a ticket or start a booking in a separate system. Each extra destination is another place where data can go missing or arrive wrong. For each one:

• Check that the record is created, in the right place, with every field mapped correctly.
• Check what happens when the other system is unavailable. Does the visitor see an error, does the submission queue and retry, or does it vanish?
• Check that a single submission creates a single record, not two.
• Check that consent choices, such as a newsletter opt-in, are carried across accurately.

A form that shows a thank-you message while a connected system silently rejects the data is the hardest failure of all to notice, which is why integrations deserve their own test cases.

Questions about form testing