One aspect of form development that is often either overlooked or not always thoroughly done is the testing phase. While testing can consume a little time, the savings in the long term can be immense, in terms of both time and reputation. The testing phase is where we get to identify and repair any little cracks or gaps that may have crept in between the original specification and the actual implementation. But it must be done thoroughly.
If testing is not properly done before the form is live and published, then our form users become our testers, which is not fair on them. It is better by far if the problems, niggles and irritations are discovered and handled internally before we cause frustration out in the public domain.
While a certain amount of technical testing is necessary on the part of the form developer, it is best if someone other than the form developer does the usability testing. The main reason for this is that the developer is going to see what they expect to see, whereas another user who was not as intimately involved in development is more likely to accurately measure what they see against the original wish-list from the form design stage. These users will also be better placed to evaluate the form in terms of usability.
In the case of forms more complex than our current form, it is almost never good enough to have one person do one test submission and consider the job of testing to be done. As the options on the form multiply, so do the number of potential test paths, so we should ensure that the test plan covers as many of these possibilities as is practical.
Something else to consider in the set up of the testing plan is the various validations that we specified for components, for example, unique e-mail addresses.
The person or preferably persons who are going to conduct the testing should familiarize themselves with all of the form requirements as per the design discussions. From these they can draw up a checklist of specific items to be checked off as they progress through the form.
Thankfully our form is still fairly simple, so all that needs to be checked is that the mandatory fields are, in fact, enforced and that the same e-mail address cannot be submitted multiple times.
The form should be tested at least once as an anonymous user (that is, by a user not currently logged in on the site) and once as a registered user. This is to ensure that the %useremail token substitution works as expected.
We should also include in our test plan to see whether we can enter more than fifty characters in the Presentation title field, or whether we are blocked from doing so, as per the rule we set up on the component.
We should ensure that the confirmation e-mail arrives at the specified e-mail address and that it is in the layout we set in the template.
Just clicking Submit on the blank form is the easiest way to test the mandatory fields. Let's click on the View tab to load up the form and then click the Submit button. We should see all the mandatory field error messages at the top of the form display highlighted in a red box as follows:
Notice the red highlighting of input areas on the form itself which serves as an aid to identify the fields in error.
Let's now assume the role of testers and enter some test submissions, taking into account the testing actions described previously. Please enter several test submissions so that we have enough data to play with in Chapter 3, Working with Submissions where we see what Webform offers in terms of working with submitted data.