Focusing on a new project is all well and good, but you also must ensure it won’t harm business operations. It happens so easily. Come across any of these? A sponsor executive who doesn’t understand the impact of the project on business processes. A leadership team with a poor grasp…
Author: Craig Barnard
With a growing number of companies moving towards Agile methodologies, automated testing is now an integral part of the delivery process rather than a nice addition.
Part of this essential process is regression testing, which sees software development progress regardless of the delivery methodology. It is near impossible for agile teams to deliver value to end users, if substantial regression cycles are required to be executed on a sprint by sprint basis.
With this in mind, the time it takes to execute full regression cycles will have to develop further to become a linear approach. Delivering more and more features will eventually reach a tipping point.
Once the tipping point is reached we have two options:
1. Test less and potentially deliver features that are incomplete or do not meet our quality standards
2. Invest more effort into regression testing rather than delivering tangible real world value to our end users via new features.
If neither option is palatable, the only effective way to answer the question “Have we broken it?” is to automate the testing of features as the project is delivered.
Be prepared to unshackle your team, the more we automate in testing, deployment or build, the more we can focus on solving real problems.
Test automation unleashes the imagination of those whose responsibility it is to deliver a quality, working product, allowing them the creativity to thrive.
With more time to spend on adding real value rather than cranking out the same tests over and over, the test team will have the opportunity to increase the quality of the product via additional test coverage or new innovations in the test space.
I’ll take working software over comprehensive documentation any day, the better the quality of a product the more people will use it!
Documenting manual test cases in excel or quality centre quickly becomes an exercise in comprehensive documentation that gets filled away never to be seen again or, in best-case scenario wheeled out every time a change is made to the product.
In order to respond to change and be truly agile we need to automate all aspects of what we do. Unfortunately, too often testing is treated as a second class citizen in this regard. It’s common that when time is tight testing gets squeezed and it’s easy to veer away from automated to manual testing.
However, it’s imperative that automated testing goes hand in hand with development from day one. The successfulness of any product requires that automated testing be delivered wherever practical if we truly want the ability to be “Agile” and respond to change effectively.