Are you transitioning to agile? Then test automation is key in getting you there fast and efficiently. Here's why.
In a world where new business models are disrupting established revenue streams and expectations to the customer experience are constantly increasing, businesses everywhere are struggling to stay relevant.
To stay competitive requires efficiency: Fast market adaptation, well-organized change management, and the ability to secure emerging opportunities. One of the ways to get there is through agile transformation.
In short, the aim of agile transformation is for businesses to reach a state of change readiness that lets them embrace the unknown.
Internally, this means establishing a smooth and predictive path for converting ideas into practice.
The actual implementation of agile principles is usually done by introducing new ways of managing projects and development processes in a company, i.e. Scrum and/or SAFe (Scaled Agile Framework).
Although agile transformation is relevant for every business, companies whose value chain is largely based on IT processes tend to be the first to embrace the concept of agility.
Not surprisingly, Scrum, SAFe, etc. are first and foremost applied to the IT processes in enterprises, especially in software development.
Before the introduction of agile development, projects were often managed using the “waterfall model”. With this approach, each discipline had a dedicated focus and place in the project timeline.
A project would begin with an outlining of all requirements for the software to be developed. Then developers would begin building the software – this could take months or even years – and then testers would take over the final product and begin testing it.
Not surprisingly, the waterfall model has proven to be too rigid an approach for modern software development.
In an agile project model, there is no dedicated, focused time for each discipline. Instead, the project timeline is broken into iterations, called sprints, that involve all disciplines: scoping, development, testing, and more.
Typically, the duration of a sprint is two to four weeks depending on the number of people involved, the maturity of the department, etc.
Working in short, focused iterations combined with the lack of a dedicated testing phase presents a challenge to testers; how and when to verify the quality of the software in its entirety?
As shown in the figure below, the number of features in a software will accumulate as sprints are completed.
Assuming that the project is not supplied with additional test resources along the way, the accumulation of features means that during each sprint, testers will only have time to test the recently developed features and will not be able to do regression testing, i.e. testing how the new features affect existing features.
FIGURE 1: The regression issue.
As features to be tested accumulate, and with a fixed amount of testing resources available,
testers are forced make to compromises.
The regression testing issue is a well-known problem in software development. Agile development has just accentuated the problem; with iterative sprints it has become increasingly difficult to answer questions such as “How is the quality?” and “When can we do a release?”.
Of course, one way to solve the regression testing problem would be to hire more testers. However, this would increase project costs significantly and is not a scalable solution.
Another approach could be to go back to doing end-to-end testing from time to time, but this would defeat the purpose of agility. This leaves us with just one option: Automation.
With test automation – in this case automated functional UI testing – robots are instructed to execute the repetitive, predictable test scripts allowing testers to focus on testing the new features of the latest sprint.
The figure below illustrates how test automation supplements the testing efforts during sprints.
FIGURE 2: Automated regression testing. Robots take care of regression testing,
while testers continue to focus on testing new features.
With test automation implemented, it would still be the testers themselves designing test cases and monitoring the results, but the main regression efforts are carried out by robots.
To sum up, automation reduces risk by ensuring that any uncertainties are limited to the recently developed features.
When transitioning to agile, you need the right approach that will make the transition as fast and easy as possible. You also need the right test automation tool.
A good test automation tool is one that allows all testers on the team to have ownership of the automation effort; each tester should be enabled to build automated test cases and to monitor and analyze the results.
If an entire team can take part in utilizing automation, then each team member will also reap the benefits, and have time freed up for testing new features.
In other words, for test automation to truly support the objective of being agile, the underlying automation strategy should not be dependent on only a few technical specialists.
Instead, the strategy should be based on making automation a natural part of each tester’s profession. This will make test automation much more efficient and scalable.
Learn more about test automation strategy in our podcast on the requirements for successful automation.
So where do you go from here? First, a quick overview of what we've discussed in this blog post. Download our whitepaper on Agile Testing to continue learning about this topic and to achieve a smoother and more efficient transition to agile development.
If you want to learn more about agile testing, download the whitepaper here: