Multi-Layer Frameworks for Test Automation
Legacy test automation systems, whether developed as record-and-playback scripts or coded software, have been designed without reuse in mind. The automation script is created as a one-time solution for regression, data validation, or functional integration testing on a specific application. The next application typically gets a new automation platform, designed from the ground up. This philosophy runs counter to the modern software architecture principles of code reuse and refactoring.
A multi-layered framework maximizes reuse between automation projects for a given combination of automation tools (Microsoft CodedUI, Selenium, rSpec) and programming languages (C#, Java, Ruby).
The Abstract Framework Layer contains the Rules and Extension Methods to minimize scripting errors and maximize value from reuse. The objects and methods in the Abstract Framework support functions common to all automation projects. This layer is the most complex to code, but contains the smallest number of lines in the solution.
The Application Framework Layer contains page objects, step methods and helper classes associated with the application under test (AUT). Also included in the Application Framework layer are Exception Handling and Assertions but the key component in this layer is the logging and screen capturing functionalities. The logging feature is used to effectively capture and report results as the test scripts are started and completed. The screen capture piece captures screenshots for any failed steps. The volume of code in this layer is larger than in the Abstract, but its complexity is less.
The Application Test Layer holds the test tool and test data used to develop fixtures and scripts which drive the AUT. The test fixture is a code base that executes the step methods, which in turn manipulate the page objects. The results are reported (based on test results data provided by the Application Framework), to help determine whether the application has passed the defined test suite. Most of the code in the multi-layer framework exists in the Application Test, but if the coding rules are followed at all three layers, the end result is an architecture which requires very little technical experience for a test analyst to write automation scripts.
Depending on the automation platform selected, a Test Console Layer may be built to organize, schedule and execute large groups of automated test scripts, which can be grouped to test specific functional areas of an application. Many automation platforms are packaged with a Console, along with other pre-defined aspects of an automation framework. An established and open-source platform like Selenium has a wide variety of contributed and independently tested libraries of objects and methods to select browser configuration, file input types, language extensions, etc. The SPR architecture blends with these libraries, creating a solution with the minimum necessary amount of new code, and with an end result which should be very familiar to anyone with experience in creating or executing automated test suites.
It is beneficial for the software development team to understand automation architecture and needs of the automation test solution. The object naming convention and identifiers for each page class can be standardized and controlled, making it easier for the software automation engineer to understand the implementation of the UAT. It is critical for the application development team to be aware of how their own code changes and refactoring affects the automation; an innocuous change which barely affects the AUT may have drastic consequences to the automation attempting to test it.
Test automation is often times viewed as a ‘silver bullet’ to increase test coverage and reduce testing cycle time. Selecting an automation tool and programming language can incorrectly become the primary focus of the path to successful automation. Without a multi-layered test automation in place, the risk is high that the ROI of test automation will not be realized due to a poorly constructed and fragile automation test suite.