Test Design Strategies for End-to-End Testing

Design is Key

Test design is the most critical element to implementing a successful test automation project. This process is often overlooked as teams focus on reviewing tools rather than first looking at the overall requirement for test automation success. Test teams tend to have in-depth conversations about the tool features, while forgetting about the design considerations and other data prerequisites.

A Long Journey

Imagine planning a road trip with your family including a toddler, and only choosing the car while not deciding on the route, breaks, food, etc. While you might choose the best car, without the necessary planning there is every possibility that the trip could be a disaster. Even if you end up reaching your destination, it might be a painful experience, leaving you unwilling to plan another trip for 10 years. That’s exactly why teams end up not automating their applications, even though there are good automation solutions available. While tooling obviously is an important factor, it’s the overall strategy that makes test automation successful and maintainable.

Test Automation is a journey

What Does Test Design Mean

Test automation design strategy helps you define a structure that makes the underlying test scripts maintainable. Even before writing a line of test code, there are many requirements or preconditions that need to be addressed. For example, you need to identify the areas of your application that need automation and decide on the timeframe.
Breaking down application features in terms of priorities helps you focus on the most important things first. Once these areas are identified the next step will involve identifying the data required for testing. Data requirements can sometimes be tricky as you need the latest dataset that is as close to production as possible. This may involve multiple teams, which basically puts you at the mercy of other groups such as infrastructure, database administrators, etc. to create a clone that’s close enough to production data.

Once a dataset has been identified, the next process is to separate out tests that are purely UI based, such as checking the position of a button, ensuring the button has the right color, verifying whether the text is displayed in the right font, from tests that validate business logic. Examples of tests that involve business logic include checking if the correct price is displayed, validating whether the grid has the correct set of data, verifying the user is successfully registered, and checking search capabilities.

This separation of concerns helps with identifying failures of critical features rather than focusing on cosmetic UI bugs. That’s not to say UI bugs are not important, but a clear demarcation helps you to present a crisp bug to the developer, which speeds up the whole defect lifecycle.

Component Locator Strategy

A good component locator strategy completes the test design strategy. This should begin as a conversation with the developers because they can provide key information that test automation engineers need in most situations. Developers can provide important automation hooks, where possible, that can be leveraged by test automation engineers for effective test creation.

Tests should interact with the Ext JS Component layer wherever possible, rather than referencing DOM elements directly. DOM elements and their attributes (like id) are dynamically generated by the framework and regularly change based on the order that components are rendered. By referencing the Component using a Component Query type locator, like an xtype, or a combination of xtype and itemId, makes referencing the Component’s underlying elements more robust.

Ext JS has various unique ways of defining classes by specifying unique xtypes and itemIds that will stand out from the most commonly used XPaths and DOM IDs. By providing meaningful names for xtypes and itemIds, developers can make test automation seamless and improve the overall quality of the application.

Single Page vs Multi Page

The next important aspect of test design is to organize the tests into meaningful suites. A suite should consist of tests that address a common feature. In a single page application architecture, this is rather convenient as tests can be organized based on the page under test. In the example below, tests were written for the different pages in an asset registry application. The sample application consists of 4 different views:

• Login
• Dashboard
• Assets
• User

In a single page application, there is no concept of page navigation, so the suites can be a collection of tests for a single page. For example, the Dashboard View in the case of our sample application. The structure below shows how you can group the tests into Jasmine suites for each page and thereby effectively contain the flow of test execution.

Dashboard View for our sample application

In the case of a multi-page application, this may not be as straightforward. Pages in a multi-page application may not be self-sufficient, and every event such as click or tap can render a new page.

Have you ever used a banking application? In heavy data-intensive applications, there could be multiple trips made to the server every time a new screen has to be rendered. In order to effectively segregate tests for multi-page applications, make sure you are able to identify common tests for a feature. For example, in a banking application, savings accounts can be a broader level scenario. Within that scenario, there could be many different Jasmine suites testing the different aspects of savings accounts. Similarly, there could be different scenarios for checking accounts, credit cards, and so on. You can then break them down into multiple Jasmine Suites based on UI tests and business logic tests.

Creating organized tests simplifies maintenance

Sample End-to-End Tests

Sencha Test simplifies the process of writing tests for Ext JS applications. The sample test suites in this GitHub repository will help you to learn how to use Sencha Test APIs to effectively write tests targeting specific Ext JS components, without having to rely on information at the DOM level. Read the instructions on how to use the tests. These tests demonstrate effective test design using a page object design pattern as well as a clean mechanism to separate tests that don’t belong in the same scenario.

Conclusion

Test Design has nothing to do with selecting test automation software. It’s a requirement to effectively build your strategy for automation projects. Teams that spend as much time upfront in test design will end up spending much less time maintaining tests.