Debunking the Most Commonly Cited Barriers to Effective Agile Testing

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.

KPMG

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.

Want to see more like this?
Scott Siegler
Scott Siegler
Former Blogger

How to Create a Usability Test Plan

Follow this usability testing checklist to gain valuable user insights

How a Canary Release Strategy Improves Quality

Software deployment strategies like standard, canary, A/B and blue-green releases explained

5 Best Practices for Testing AI Applications

Testing AI applications in the era of AI regulations

Creating a Store of the Future: 7 Lessons from the Real World

A store of the future doesn’t have to be futuristic

Applause Wins 4 International Awards for Business and Product Excellence

The company was a winner at both the International Business Awards and Best in Biz Awards

Do You Have the Skills to Thrive as a DevOps Engineer?

The best DevOps engineers have a unique and varied skill set