Create testing framework with minimum test artifacts to allow full test coverage for your AUT
Read this short article to learn how to most efficiently develop test automation framework and reduce time for test script development and maintenance.
The quality of software applications is an inevitable characteristic of any successful business today. For the past few decades, testing has become a part of any organizations’ SDLC, and test automation has also become a part of many organizations’ test processes. One of the main objectives of test automation is the optimization of testing ROI by expediting test execution.
Many organizations, (even with test automation at place,) struggle with time to test execution due to the fact that their testing frameworks require high time investment into development and maintenance of their test artifacts. One of the main aspects of these delays is the way test automation teams create their frameworks.
In order to optimize test framework, you need to reduce the number of test artifacts, yet still perform maximum test coverage of your application under test (AUT). This can be achieved by designing test architecture with a ratio of one (1) test artifact per one (1) test case (test script). These types of test architecture and test artifacts have to be designed based on four main fundamentals; i.e:
- Rich Logic
Modularity allows your architecture to divide functional areas of your AUT to reusable blocks that will be later on used for constructing your test procedures. When designing test architecture, you might use two classes of test artifacts: the module (reusable script) and test procedure (procedural script). For example, if you need to test a travel application’s itinerary procedure using this approach, you would first create 5 reusable scripts: Login, Book Flight, Book Hotel, Book Rent-a-Car, and Logout. When creating procedural script, Book Itinerary, you will call these 5 reusable scripts. This approach allows test framework to be flexible and also allows testers to create any test procedure addressing their testing goals. Also, using modules allows test automation specialists to update test scripts once (in case AUT requirements change) and these changes will be automatically applied across all procedural scripts.
As a best practice, any test case should have at least one validation (a checkpoint) to report pass or fail conditions during execution. An Event-Driven way to design test cases means that every test step should end up by triggering events in the AUT, and therefore, presetting a test for validation. For example, if we are designing a Login test case, we would create 2 test steps: Invoke AUT (to preset validation of Login page appearance, i.e.: click AUT URL,) and the actual step to login into AUT (type a user name and password, and of course, click the Login button).
Speaking of testing ROI and the need to minimize the number of test artifacts in our framework, we need to create test scripts that are Data-Driven (similar to data sponge that will accept and return any variable of input and output data.) Therefore, we need to substitute any static values that can be dynamic in our AUT with dynamic values (the parameters). For example, in Login test case, we would parameterize username and password fields. These values, later on, also can be used for validation as well as anywhere else in the test architecture.
And as best for last, you will maximize your testing ROI by creating your test cases in Rich Logic. Here, you will need to use conditional approach when designing your test steps and most importantly, your expected results. For example, if you are creating a Login test case, and if your AUT has few user groups, in order to incorporate the approach of 1 test artifact per 1 functional area, you would use IF statements to validate what user group member is logged in. Using Rich Logic in your test cases will take a slightly longer time to design and develop, but will eliminate the need to multiply test cases per functional area of AUT, and therefore, will save significant time in maintenance.
Your main goal as a test leader is to maximize testing ROI. One of the main ways to do so is to create a testing framework with minimum test artifacts that allow full test coverage for your AUT. Your test framework should be flexible enough to construct any test procedure that addresses your AUT requirements, uses default application data for input and output, validates your test execution, and addresses the logic of your application business requirements.
I want to thank you very much for taking your time to read this blog! I’d like to ask you to provide your feedback in case you agree or disagree with this blog. Your opinion will help everyone in the industry to make the right decision when designing test framework.