Early Automation
This is the third post in our series on test automation
With the software industry going Agile in a big way and the emergence of digital technology, testing is no longer a “later stage” activity. Rather, testing has to remain hand in hand with development, ensuring “done-ness” at all times. Agile requires that tests for new and existing features be executed as soon as development completes on various desktops/ device/ browser combinations. This translates to a “safety net” in the form of a Regression Test Suite that gets built side-by-side with the features in the software.If development and testing are to march together in-tune in this way, iteration after iteration, tests not only have to be ready in time, but they also have to be fully automated. Else the testing activity will inevitably fall behind. Why? Because the manual effort of an increasing array of regression tests will eventually cause testing to lag behind development.
However, the creation of automated testing frameworks has been regarded as a downstream activity in the software industry till recently. This is due to the traditional “waterfall” thinking on one hand, and the technical difficulty of automating testing of software that is not yet developed, on the other.
So how do we move from the traditional “delayed automation” model of testing to the modern “aligned automation” needs? How do we build the “safety net” as we build the software?
Below is the solution to this problem, and explains an actual implementation of this concept. The aim is to introduce the possibility of automation early in the development cycle to software testing professionals, and to help them make the required paradigm shift in their thought processes.
The Test Automation “Phase Lag”
Test Automation is often thought of as an activity to be done once testable code is delivered. This creates a “phase lag” – the automated tests cannot be used during the same iteration or sprint. They are used in successive iterations or sprints. Usually the automation activity is so late that these tests cannot be used even in successive sprints, but are only ready for subsequent releases.
Below figure represents a typical scenario of Test Automation “Phase Lag”
The above scenario for a single user story is multiplied manifold as multiple user stories are developed in each iteration/sprint. This generates a huge backlog of automation. This backlog often continues beyond the release boundary and starts affecting future releases as well.
So what do we need to get rid of this lag? We need the ability for the test automation engineer to be able to start writing the automation scripts based on the user story description, just as the manual testing engineer can write the test cases based on the same description.
The Solution – The Automation Template
What is required to be able to begin automation? Primarily two critical things – requirements (in the form of either business requirements or test cases) and object identification (the UI objects in the screens that are going to be automated).
Let us consider a simple example.
A Login page of a web based application is a simple-enough place to start with. Let us assume that the test engineer has the requirements, and understands how the UI will look like. He or she understands from the requirement that there would be two input fields for entering the username and password and there would be two buttons for submitting or cancelling the request. Using these as a basis, it should be possible for the automation engineer to write the base code for the following steps, with the caveat that he or she does not have the object properties of the UI objects yet:
- Opening the application (this will require just the URL as the parameter)
- Entering the username (this will require the object property of the username input field)
- Entering the password (this will require the object property of the password input field)
- Clicking on the Submit or Cancel button (this will require the object properties of the Submit and Cancel buttons)
So the code is ready with the only exception of the object property. This means that the automation engineer is ready with at least 70-80% of the code before the developer has finished developing the actual screen. Once the code for the screen is ready, the only aspect left is to put the object property and start running the automation scripts! This essentially creates an “Automation Template”. All that is needed to convert the template to working scripts is to plug-in the object properties.
This can be further improved by putting coding standards in place so that object properties follow well known conventions and patterns, enabling the automation to define the object properties without seeing the UI code. This would push automation completion to the 90% region even before the UI code is ready, and adding the finishing touch would be much quicker.
With the above methodology, we can get to automated tests almost immediately after development completes, allowing each use case to be tested and certified using automated tests rather than manual tests. This creates the safety net along with the code, and eliminates the automation “Phase Lag”.
Figure 2 below shows how the results from the new approach would look. Automation testing would be “in-step” with development, and a solid base of automated regression tests would be built up for use in subsequent iterations/sprints.
Conclusion
To stay abreast with the current trends of agile methodology & digital transformation, extensive testing efforts are required to test on all possible OS/browser/device combinations. For this, automation needs to happen within the sprint or what we call as “In-Sprint”. All this is possible only when the testing fraternity makes a paradigm shift in their approach to Automation. Value proposition out of this will be:
- High percentage of test automation
- Increased Testing Efficiency
- Accelerate Real Continuous Integration
- Faster Time to Market
In the next and last post, we’ll explain more about ATDD or Acceptance Test Driven Development and how to tame specifications while preserving efficient turnaround of tests as presented in this post.
