It’s tough to sprint over long distances. So, when an agile-focused project manager asks a tester to run a marathon of functional, non-functional, and regression tests in the time frame of a ‘sprint’, they shouldn’t be surprised when they start to struggle.
Imagine the scene – A project has rolled into the later stages and there are a host of new components that need to be completed to finalise the current ‘sprint’.
You would think that getting all of these components signed off is easy, especially as the volume of work has been pre-planned, and the time required has been allocated. In some cases, this will be true– especially under the watchful eye of a detailed project coordinator – there are however some considerations that you need to be able to make – what about regressions?
Testing is a vital part of the sprint phase and as one of Mando Group’s Test Analysts, Simon Royall suggests, “It’s key to maintaining continuous, productive development.
“Thinking about functionality and the direct impact it has on what the user/client needs to see at every stage of the project is vital. If we work in a truly agile way, however, we have scope to produce the kinds of incremental gains that formulate a full project and deliver against KPIs.”
What is regression testing?
Regression testing is a type of testing in the software development cycle that runs after every change to ensure that the change introduces no unintended breaks. If there is a fault after the test, then this is referenced as a regression.
Common changes that may require regression testing include bug fixes, software enhancements and configuration changes.
The importance of testing?
Simon discussed the importance of testing recently. He said: “Imagine it’s one of the later sprints in a digital project, there are a host of new components to push through the development phase and implement on the live site – but what about the test environment and the checks that need to be made in terms of regression?
“On top of testing all of the new code – both in terms of functionally and non-functionally, we must ensure nothing has gone wrong with legacy code – and that bugs aren’t occurring or reoccurring.
“It is easy to become weighed down with the ever-increasing burden of back-checks, you can even start to feel overwhelmed, or at worse - stuck on an M.C.Escher-style staircase of your own test steps.
“Regression is a significant part of the testing burden. By regression, we mean checking that new features haven’t broken any existing features and that we are re-running some or all the test cases from previous sprints to confirm that they still pass.
“Not adding enough gravitas to this, and you may miss the degradation of an existing feature; take too much time on it, and you may turn your sprint into a marathon of going over old ground. Balance is key.
“Some in the industry would argue that it is part of development where you can throw extra testers at the task. But that negates the fact that ‘Agile teams’ are supposed to be small – and test resources are finite.”
How, then, do we make the ‘Agile’ model work for testers, so that a sprint is genuinely a sprint and that they are not asked to complete difficult code changes in an unrealistically short space of time?
What about automation?
At first, this might seem like an unlikely remedy: writing automated tests involves writing code, which takes a long time to do – something that your team might not have.
The trick is being smart with the available time. Writing automated tests up front is an investment that will ultimately pay for itself: with each new sprint, and with each release during the sprint, instead of spending hours wading through an ever-growing list of regression tests, the tester can press a button, sit back, and within a few minutes have a complete report of whether any existing functionality has failed.
And for repeat deployments, the job becomes nothing more irksome than pressing the button again.
There is a limit to what automation can do, however, but this is precisely why we want to do it in the first place.
With an automated regression script running, the human tester can focus on what they do best and make manual checks. Where the discerning human eye is needed, it can now fall without distraction. It can pick up on subtle visual errors, or those that only reveal themselves when there is the time to pursue a particular scenario. It can devise and execute more involved exploratory tests.
Getting this right requires the tester to be given access to the front-end code before it reaches the ‘Test’ environment. This might seem like a paradox – and like letting the food critic into the kitchen – but it’s perfectly feasible if you have a pattern library available.
With a pattern library, the tester can write and debug the code for automated tests against what should be a good copy of what will appear in their test version of the site. This is generally considered good testing practice and is known as “early testing” or “shifting left.” It makes use of the considerably reduced cost of fixing something earlier on in the delivery process: a mistake in the pattern library can be corrected far more quickly and cheaply than the same issue identified at the User Acceptance Testing (UAT) stage.
Key takeaways – the benefits of test automation
Here are Mando Group’s top 5 benefits of automation your test processes:
1) It saves time! By automating your testing procedure, your team has to spend less time validating newly developed features.
2) Greater insight - Automated testing provides better insights than manual testing when some tests fail, helping developers to understand what went wrong and why.
3) Test automation helps you reduce the feedback cycle and bring faster validation for phases in the development of your product.
4) By implementing an automated testing strategy, you allow your QA team to build new tools, further optimise the current testing suite and extend it with additional functionality.
5) Multiple projects can use the same tests. One advantage is that you can easily link another project to your automated test suite.
Final thoughts
Ultimately, automated testing is a crucial component of any Agile project.
By allowing for rapid and frequent testing, automated testing helps teams deliver high-quality software quickly and efficiently.
It also enables teams to catch and fix errors early in the development process, which can save time, money, and effort in the long run.
Additionally, automated testing can be integrated into the continuous integration and deployment process, further improving the overall speed and agility of the project.
By implementing automated testing, teams can increase their responsiveness to changing requirements and maintain a high level of quality in their software, ultimately leading to better results and a more successful project – and the end of sprints morphing into marathons.
For more information about testing, development and digital transformation, why not get in touch?
Interested in talking to one of our consultants?
