Test Maestro Forms

   MaestroThe UI design product.  |  All versions This feature is related to all versions.

As Maestro allows you to build onboarding user journey forms that incorporate both complex logic and visual representation, form testing is becoming an essential part of the development process. It's paramount that before a form is deployed to a production environment, it must be thoroughly tested. A failure to do so will lead to poor user experience that immediately provides an adverse impact on your organization resulting in revenue-reducing customer experience.

To test forms, we encourage you to create a testing specification, which defines how the forms should look and behave. For example, some fields must be mandatory, certain information must be available, and back-end integrations should operate in a particular way.

There is no universal method for creating specifications, but an intuitive approach is to format each specification as a user story, as shown below:

As a < type of user >, I want < some goal > so that < some reason >.

For example:

As a customer, I want my data to be prefilled, so that I don't have to enter data manually.

You can then keep track of these stories as tickets in an issue-tracking system, such as Jira.

Note

User stories don't always need to be from the perspective of the customer. You might, for instance, write user stories for the people who will be analyzing the data that's produced by the form submissions.

Principles of Effective Testing

There are many ways of addressing form testing, which is available on the Internet, so we are not going into details. However, it's important to mention a few principles you should consider while designing your form testing specifications. Here they are:

Budget enough time and money
Ensure enough resources are allocated to form testing.
Don't leave testing until the end
During the development process, it can often feel like testing is less of a priority than implementing new features. As a result, testing can become an afterthought that is squeezed into the final stages of development.
The problem with this mindset is that it can compound issues that might have been avoided had testing been properly valued earlier in the process. There may be fundamental issues with how something is designed, for instance, and it may require that numerous elements of the form are ripped out and replaced before going into production. Soon, the time saved earlier in development pale in comparison to the time lost later in the process.
Run tests on various browsers, devices, and resolutions
These days, it's impossible to predict how your form will look to every customer. The amount of browsers, devices, and display resolutions on the market is so diverse that the only solution is to be mindful of the possibilities.
To make informed decisions, refer to your organization's analytics software and identify the primary browsers and devices that customers use to navigate your websites. This will provide a starting point what to test first.
To run tests on a wider range of device configurations, use a tool such as BrowserStack or SmartBear.
Use a blend of manual and automated testing
In a perfect world, all testing could be automated. Unfortunately, creating automated tests at a certain level of granularity can become more time-consuming than simply performing the tests manually.
To strike the right balance, identify:
  • What can be automated with third-party testing tools
  • What can be automated with custom-built tests
  • What doesn't fall into the above categories
Continue testing throughout development

As you can see, there are no universal tests that can be applied to every form. However, we've identified the following set of tests that can be applied to most forms so you can safely use them as a starting point for form testing:

Functional Tests

  • When supplying valid data, you can complete the form from start to finish. If you can't complete this test, the rest of the tests is too granular to be useful. Ensure this test passes before continuing.
  • There are no errors or warnings in the JavaScript Console.
  • Fields marked as mandatory are actually mandatory.
  • Fields reject invalid data.
  • The Add and Remove buttons for repeating block components work as expected.
  • You can enter data in an unusual order, for example, from bottom to top, randomly, and so on.
  • After submitting a form, the submission XML contains the data entered in the form.

Visual Tests

  • Fields are aligned correctly as per a wireframe of the form design.
  • Fields are arranged in a logical order, for example, from left to right, and top to bottom.
  • Long labels or text don't cause wrapping or alignment issues.
  • Dropdown lists are wide enough to fit the content they contain.
  • Different types of fields align correctly when placed in the same row.
  • Mandatory fields are identified as mandatory, for example, with .
  • Optional fields are identified as optional.
  • Fields look consistent between pages and across the whole application.
  • Spelling, punctuation, and grammar are correct.
  • Error messages are relevant and easily understood.

Receipt Tests

  • Fields are shown or hidden as per a wireframe of the form design.
  • Receipt is flat and uneditable. Here, flat refers to all the content being displayed together, from top to bottom - unlike in an interactive form, where content gets shown and hidden as a user navigates through it .

Accessibility Tests

  • You can navigate through a form using only the keyboard.
  • Using the keyboard navigates the fields in a logical order.
  • Images have alt attributes.

For more information, see Accessibility for Journey Maestro Form Developers.

Dynamic Data Tests

  • Dynamic data look-ups retrieve requested data.
  • Third-party integrations, such as identity verification, operate as expected.
  • When 3rd party integrations don't work, manual alternatives are available.
  • Data is prefilled.
  • Attachments can be uploaded.
  • Attachments must be scanned for viruses.
  • Forms can be signed digitally.

Devices and Browsers Tests

  • Layout responds to different view-port sizes.
  • Fields are touch-friendly.
  • All tests pass on primary browsers and devices.

Next, learn how to debug Maestro forms.