As software development is getting more and more agile, the need is to reduce the effort required in the system testing phase and start testing early in the cycle. How can we reduce test effort? By automating the tests. When can we automate tests, especially UI automation? We need a stable UI and an application ready for the test code development right? Ohhh, does that sound ridiculous?
How can we develop a UI automation suite, when the dev team is not even ready with the UI design, and we don’t have a stable UI to for developing the automation suite? Yes, we can achieve it if we follow a well-structured, layered and loosely coupled automation solution.
The idea here is to separate out the layer of specific actions on the UI from the scenarios and tests. The specific UI actions can only be identified once the UI is ready and stable which can be achieved only later in the cycle. But what about the tests and scenarios, these would be known to us earlier when the requirements are baselined. The chances of the scenarios and tests to change over the cycle is very less when compared to the UI.
Before we go into the details, let’s look at the anatomy of a typical test suite for UI automation.
How can we develop a UI automation suite, when the dev team is not even ready with the UI design, and we don’t have a stable UI to for developing the automation suite? Yes, we can achieve it if we follow a well-structured, layered and loosely coupled automation solution.
The idea here is to separate out the layer of specific actions on the UI from the scenarios and tests. The specific UI actions can only be identified once the UI is ready and stable which can be achieved only later in the cycle. But what about the tests and scenarios, these would be known to us earlier when the requirements are baselined. The chances of the scenarios and tests to change over the cycle is very less when compared to the UI.
Before we go into the details, let’s look at the anatomy of a typical test suite for UI automation.
A test automation solution will mostly consist of these components as mentioned above either well-structured or layered or mixed up in a clutter. The worst case that I have seen in my experience is that all of these layers are not well separated and there are cross references among these.
A better level of maturity that we can see is where the layers are well organized as below.
This is the most common form of test automation suites than we can see in the industry now. There will be a tests layer at the top which interacts to test data layer either by using the tool capabilities or a custom implementation. The test layer interacts with the scenarios layer which has a high level implementation of scenarios and not a set of detailed actions. The scenarios layer will use the actions layer to realize the actions needed for a scenario. This might look very familiar to all who have done a structured test automation framework. This is good, but would you be able to do the following with this approach.
- Start developing the automation suite before even the UI design is finalized
- Remove any layer without code changes spread across other layers(loosely coupled)
- Spend minimal effort in the System Testing phase for completing the automation suite and use the suite effectively to run the tests
In order the achieve this, we need to think of how we can make the solution loosely coupled, easily extendable and maintainable. We can achieve this by Making components/layers depend on contracts rather thanimplementations Following design patterns wherever appropriate Strictly adhering to design principles and coding standards Design the solution with interfaces to set the contract on which each layers will interact and use a factory pattern to provide the concrete implementation of the components.
So the tests layer only knows the signatures of methods or in fact the contracts it can use on the scenarios to run the test. The scenarios layer knows only about the contracts on action methods. It doesn’t know how the actions are going to be implemented. We can plug in any implementation of the scenarios or actions component to the tests. So the business logic tests can be same for different implementations. Even the test data, whether it be dynamic or static should be abstracted by test data adapter layer which provides the data required for the tests. Tests layer will never know how this data is created or fetched for it
