Debunking the Most Commonly Cited Barriers to Effective Agile Testing
With approaches such as Test-Driven Development and Acceptance Test-Driven Development, organizations are now accepting that testing should be in the driver’s seat rather than just the back seat.
In spite of the increasing prominence of agile development, running an effective agile development process remains very rare. A major culprit for this shortcoming has been ineffective testing.
For a variety of reasons, testing has struggled to keep up with the rapid and iterative pace that development sets. It can seem like the nature of agile forces testing to take a back seat in the process. However, when you look at some of the biggest barriers that are cited, you will find that this simply isn’t the case.
“There’s not enough time.”
46% of developers claim they don’t have enough time to test as much as they should. However, developers also have cited that their last major software defect required an average of 20 developer hours to fix.
It can seem like the demands of testing during agile are too frequent to keep up with, but failing to keep up will end up costing you even more in the end. A proactive automated regression and exploratory test following each sprint will end up preemptively uncovering and fixing issues that would each require 20 hours of reactive and frantic repairing.
It may seem like you don’t have the time to test. However, it is more true that you don’t have the time not to.
“It costs too much money.”
The belief that testing less frequently will incur less overhead and end up saving money in the long run is actually unfounded.
Automated regressions and exploratory tests can be executed while incurring minimal overhead. Meanwhile, the cost of hotfixes is estimated by developers to be an average amount of $250,000 per issue.
Consistently testing throughout the SDLC and taking on the small amount of overhead each sprint actually saves you from becoming penny wise and pound foolish at the time of launch.
“There are too many unexpected changes.”
If it’s not time and money that have been keeping you from effective agile testing, then it must be unplanned and unexpected issues that have been preventing you from testing as often as you would like to.
It is human nature to view your own future with unwarranted optimism, but don’t let this tendency tank your whole QA effort.
The agile methodology was inspired by the principal of adapting to unexpected changes, so make sure that this flexibility carries over into your agile testing plans. Timetables shift, technology changes, and customer expectations are a constantly moving target. Plan for unexpected changes. They have happened, and they will continue to happen.
Developers who felt their companies allotted sufficient time to pre-release testing indicated spending less than half as much time resolving bugs later in the development cycle.
