As another year begins and we look forward, many teams use this time to reflect on all that they’ve accomplished—reviewing things that are working well and things they’d like to improve.
A key challenge continues to be automating our testing. Most of us are running to catch up in the test automation space and aggressively striving to secure skill sets and tooling, define automation approaches, implement automation frameworks, and increase our automation coverage. A critical foundational element in achieving our goals is our test automation architecture.
Unfortunately, with all the pressure to “just automate,” we may not invest enough in planning and architecting our automation. Most of us would not build a house, add on a room, or remodel without first doing some planning and design. Our test automation journey should be treated no differently.
The first step is to define our test automation platform requirements; identify key stakeholders; understand what projects, products, and types of technology need to be supported with our automation; and determine the breadth and depth of the types of testing to be automated. Two other requirement areas that are often overlooked are the test environments and the test data.
As we are defining the requirements, we can begin to iterate on the test automation architecture. In my experience, there are at least four layers we must consider when designing and implementing our test automation platform: the test generation layer, test definition layer, test execution layer, and test adaptation layer. Surrounding these are likely integrations to other workflow systems that we need to consider.
Here’s a summary of each layer:
- Test generation: This layer and associated tooling and methodology helps us design effective tests; this is one of the most important areas of the architecture, as it’s where we increase the probability of identifying defects and increase test coverage
- Test definition: This layer supports test case or test suite implementation and is where we specify test conditions and test cases at various levels of detail, along with the associated test data and procedures
- Test execution: This layer houses our test execution capabilities, allows for selection of test cases and test suites, and provides logging and reporting functionality
- Test adaptation: This is essentially the interface layer (API, GUI, services, etc.) to our component, application or system under test; it houses the functionality required to interface with the various technology implementations that we need to test
- Surrounding integrations: Leveraging the test adaptation layer, we must also consider how our test automation platform interfaces with other workflow systems, such as configuration management, continuous integration or delivery, and test and project management systems
The overarching objective in thinking about these architectural layers as separate yet integrated is to design maintainability, flexibility, and scalability into our test automation platform.
Often we are faced with the challenge of adapting an existing, usually disparate set of tools, or we are adding new tools or retiring others. A comprehensive plan for our test automation architecture is critical to our success in aggressively increasing our test automation coverage.
Originally published on TechWell Insights.
