Contact form testing checklist: from mobile input to an enquiry someone can handle
A success message does not prove an enquiry reached the right person. Test the whole path: input, acceptance, storage, notification and ownership. These cases help you accept a new website or investigate missing enquiries on an existing one.
Define what successful delivery means
Name the responsible person and the system of record, such as a CRM or protected enquiry list. Decide which fields must appear there and how the owner notices a new request. Email is a notification channel; it need not be the only copy of an enquiry.
Use clearly labelled test data and a test address you control. Record a timestamp and identifier so you can find the same request in the form, storage and notification. Do not use real customer data for this test.
Run input tests on the public form
Test mobile and desktop on the deployed website. Development-environment success does not confirm production domain settings or notification delivery.
- Valid enquiry: all required details arrive intact.
- Missing required field: a clear message appears at the field.
- Invalid email: correction is possible without losing other input.
- Long text and accented characters: important details are not silently truncated.
- Slow connection: sending state is clear and accidental duplicates are avoided.
- Interrupted transmission: a useful error and safe retry path; simulate only in an agreed test environment.
- Keyboard use: inputs, error messages and submission are accessible without a mouse.
Verify storage and notification separately
After a successful submission, inspect the saved record, assigned recipient and spam folder where relevant. Compare contact details, message, selected service and source. In a test environment, simulate a downstream notification failure: does the stored enquiry survive, and can notification be retried?
Separate visitor abandonment, server rejection and a stored enquiry with a failed notification. Each calls for a different fix. If contact clicks and success events disagree, first check exactly where each event is measured.
Keep an acceptance log
Record test identifier, device, language, time, expected result, actual delivery and owner. Each failure needs a description and a retest date. Repeat affected cases after changes to the form, recipients or hosting.
A complete entry might read: EN-TEST-01 — mobile — stored — correct CRM owner — notification received — success event captured. Keep the log with the project and remove test records using the agreed cleanup procedure.
Frequently asked questions
- Is a success message sufficient evidence?
- No. Check storage, correct ownership and notification separately. The browser message does not show every downstream step.
- How often should I test the form?
- Before launch and after changes to the form, recipients, integrations or hosting. Also agree a recurring check appropriate to the importance of the channel.
Send the form address and explain where enquiries should arrive. We can discuss testing, failure handling and integration.
Discuss enquiry delivery