A WBS (Work Breakdown Structure) is a valuable planning tool which is often overlooked in the rush to create a project schedule. A WBS is a tool defined in the PMBOK. It is a structured decomposition of the entire scope of the project. PRINCE2 also defines a similar planning mechanism…
Oops is it broken? The ins and outs of Agile and Automated Testing
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.