How to test a webform

This guide covers what to look for when testing a new webform. It includes specific instructions for Drupal CMS webforms, but can also be used as general advice for webforms built on other platforms.

On this page

Tips for webform testing

  • Embed the webform on a CMS page and test the form there, rather than using the Test tab in the CMS back-end.

    • This is because there can be discrepancies between the back-end and front-end display and functionality of webform elements, so testing using a webpage preview link will ensure you’re experiencing the same form as website visitors.

  • If the form has conditional logic, test the form a few times selecting different options to see what displays and whether any incorrect fields appear or disappear.

  • Attempt to submit the form with incorrect data, such as not using a valid email address in an email field or not filling in a field marked as required, to check for error messages and confirm that the form won’t allow you to submit.

  • Use your VPS email address for a submission so that you can receive any auto-generated customer emails and check they make sense.

  • There are some known issues or limitations with Drupal forms. Check our advanced guides to confirm any webform elements/fields or settings that aren’t configured:

Checklist for testing

This is a general checklist of what to check for new webforms. Not all items will be relevant to every form. For example, some forms are created as decision tools only and don’t collect any submissions.

Filling in the form

  • When looking at the form on a webpage, all fields display correctly/as expected and in the right order.

  • There are no spelling, formatting or style guide errors.

  • All text is written in plain language.

  • Hyperlinks work and open in a new tab, not the same tab.

  • There is a minimum of 1 required field in the form, to prevent empty submissions.

  • The grouping and order of the fields is logical

    • For example: contact information (name, email, phone number) is grouped together.

  • Correct field types are used for the questions

    • For example: radio buttons are used for single responses only, like Yes or No; checkboxes are used when multiple answers are allowed.

  • Multi-line text fields allow you to scroll in the field.

  • An email field (not a text field) is used for collecting email addresses, and applies validation.

  • There is a visible "Submit" button.

  • A personalised collection notice is included at the end of the form.

  • Error messages show if you leave required fields blank and try to submit the form.

After submitting the form

  • The form disappears from the page to prevent duplicate submissions.

  • An appropriate on-screen confirmation message displays indicating the form submission was successful.

  • Your test submission appears in the Results section of the webform in the CMS.

  • A customer receipt email is sent to the email address used in the webform (if this has been set up).

  • An internal notification email about the submission is sent (if this has been set up).

Drupal CMS specific requirements

In the Settings section of the webform in the CMS, check the following:

  • Under the Confirmation tab, the Confirmation type should be set to Inline.

    • This means that after submitting the webform, the webpage will reload and replace the form with a confirmation message.

  • Under the Emails / Handlers tab, any emails have [site:mail] as the Send from option.

    • This is required in order for any emails to properly send, and not get stuck behind a firewall.

    • The Reply-to email can be changed to the Custom email address option in order to provide a specific email address.

If the form has passed testing

  • In the CMS, go the Results tab and then the Clear tab, and then delete all the test submissions.

  • In the Settings section, go to the Submissions tab and reset the Next submission number back to 1.

Related articles