Planning E2E

While end-to-end testing (E2E) can help create a more robust product and save time by performing common UX tasks, it does take some time investment to set up. In this chapter, we cover some of the steps to consider when first setting up your E2E environment.

What testing framework?

The Jasmine Framework (Angular default) is more free-form. The business analyst simply provides a test description (it command) and the QA resource or developer provides the code to perform the test. This allows a free-form test description, which provides flexibility and power to the business analyst, but possibly increases the workload of the developer since there might be descriptions that are the same, but still require code to implement the definition.

The Cucumber approach requires that the business analyst be more structured when writing the test definitions, since they need to provide the prerequisite setup (Given), actions (When), and expected results (Then). By providing structure at the step level, the QA resource or developer can likely develop common code to handle the steps, particularly since many steps are common (such as navigate to a webpage, enter text, or select a value from a drop-down).

Base functionality

Whichever approach you use, be sure to create a code base of the common operations. A person writing the code to perform the test should not need to write code for the following:

• Navigate to a page.
• Clear a text box and enter text.
• Click a button.
• Click a link.
• Select a value from a drop-down.
• Select a radio button or check box.

The focus of the code should be calling methods with different parameters, so the developer is coding the test, not figuring out how to make the browser commands work. Many times, a developer gets involved to come up with a solution to a recurring test step. When this happens, the step should be reviewed for inclusion in a base class.

For example, we had a recent example where the value of a previous drop-down determined what the next drop-down should contain:

Type   | Expected

States  | List of states and provinces

Rates   | List of shipping rates

The solution to resolve “List of...” was to match the expected code to a value that would be found in the list, such as “Pennsylvania” being found in the states list. The code was added to check that a value exists in the list. This is the type of item that should be added to the base class, so future coders facing the “List of…” don’t need to determine the code to confirm an entry exists in a list, but rather can simply call a method like ListContainsValue().

Templates

Computers love consistent data, while humans understand variations that mean the same thing. To a computer, the following commands are two distinct requests:

• Navigate to home page.
• Jump to the home page.

However, to people writing a test spec, the two commands are performing the same action.

One approach is to use regex patterns to provide flexibility in how the business analyst writes the test step. While it takes a bit more work to use a regex pattern as opposed to text, it makes it easier for the business analyst to write the specifications and test plans.

Another approach is the provide templates or snippets with the commonly used test commands. Many editors allow you to define your own code snippets, so creating some for the business analyst’s editor can make it easier for the analyst to write the correct syntax, rather than relying on their memory as to what the actual wording should be.

If you have very common test patterns (such as requiring a “navigate to…”, making sure fields exists, or making sure save and cancel buttons are clicked), then create a template with the proper expected syntax so the spec/test writers use the expected syntax to ensure the test will run.

Summary

E2E testing is a very comforting tool for knowing that the UX is being tested. If manual testing detects an error, you can add the condition to your E2E test plan. In time, you’ll have a comfortable regression test for your UX. However, take the time to decide the testing approach and invest some time up front in developing common code and templates. Allow the person coding the test steps to focus on the test, not the idiosyncrasies of getting the browser to perform its tasks.