The Layers in the Test Automation Journey
Test automation isn’t anything new. Like any other engineering process, test automation has had its own evolution cycle, starting with the days of record-and-play solutions. Today, test automation embraces the latest in technologies, including AI and machine learning, and enables a shift left in the quality engineering cycle, bridging the gap between developers and testers.
Test automation is also able to help engineers balance their functional knowledge and test in an automated manner. Engineering efforts are moving closer to business efforts, helping showcase the true value of quality from the early stages of product development.
However, the key to remember is that automation is not just a bunch of automated scripts that can be written and handed off. The scripting process, though important, is just an inner layer embedded deep within the journey. There are several more outer layers that are supportive and important in showcasing the true value of the automated scripts.
Here are some of the other layers of test automation to keep in mind.
The core framework
This is the critical layer. It’s the base for tying the automated scripts to the reusable functions and bringing together all the independent pieces, including the test runner and reporting utilities. The core framework layer also encompasses the layers below.
One of the benefits from automation arises from being able to use it in a continuous delivery mode, where the automation is automatically invoked by defined test suites and run at varied frequencies.
Test case management tool
In most cases, automated tests are scripted and executed independently by the engineer. The true value, however, is seen only when all the automated tests are linked to the test case management solution so they can be run in multiple different ways, depending on the need—regression tests, sanity tests, something else, or a full pass. This link is important to understand the overall health of the application determined in an automated manner.
Different stakeholders have different needs when it comes to viewing the outcomes of the automated tests. Some need tests to be very granular to be able to debug failures and understand results. Some need just a view into the overall execution status. Some need data over time to understand patterns and trends to make educated calls on quality to determine release readiness and several other decisions.
This layer is important to ensure ongoing value from the automated effort, especially in a product still under development.
The right environment setup is critical, especially for dependent areas such as mobile, to ensure realistic outcomes.
A lot of engineers may get tempted to dive straight in and start scripting their tests. But test automation is a concerted effort involving several people, and embracing the layers above and around scripting makes it valuable, sustainable, and scalable. Scripting is just one layer out of the whole.