Agile techniques are becoming mainstream as companies gear up to deliver the software they need to meet rapidly shifting consumer needs and intense competition. However, it’s also clear that many companies are struggling with testing in this new, agile world.
“I’ve been observing this issue for quite some time now, and I think the root cause is that development teams are not making the mindset or paradigm shift from the old-style Waterfall method to agile. Rather, they seem to be talking the agile talk, but not walking the agile walk,” says Aldo Rall, principal consultant at IndigoCube.
“Testing is particularly vulnerable to this because its role within the agile universe is significantly different from its traditional one.”
Rall explains that whereas the Waterfall methodology sees the software passing from one role to the next, agile requires the whole team to be accountable. In particular, agile testing ceases to be a discrete phase of software development and becomes a continuous activity owned by the whole team.
He explains: “Within the agile world, the tester no longer acts as the ‘quality police’, but rather uses a broad set of cross-functional knowledge and analytical skills collaboratively with fellow team members to find ways of delivering working software successfully. Agile testers work as part of the team, not in isolation at distinct points in the process.”
Certain issues show that teams are failing to address the changeover to agile effectively. These include the failure to address quality properly, not seeing testing as a continuous process or even outsourcing it, and a lack of effort in helping testers to adopt the agile mindset.
Agile testing requires much of the basic checking of the software to be automated in order to free up the tester to take on this broader role—uncovering hidden assumptions and helping to build a common understanding of what the project is trying to achieve. In this context, one has to remember that software is really the company’s customer interface: there’s no latitude for bugs and other examples of failed development.
Research by IBM[1] shows that even though most testers use some flavour of agile, they are not experiencing the benefits. They spend their time in three broad areas: testing itself, navigating development delays and missing functionality, and dealing with unplanned activities unrelated to testing. As a result, 54% end up deferring testing and 33% de-scoping it—all of which reduces efficiency, leading to waste.
Even more telling, the research shows that almost half of the respondents (49%) spend eight of their 40 weekly work hours (20% of their working time) on non-testing work, while more than a third (36%) spend 50 to 100% of their time on non-testing activities! It seems that ad-hoc requests are the biggest culprit for this sorry state of affairs.
In summary, Rall argues, the shift to agile means moving beyond just simply adopting certain techniques or methodologies; it’s necessary to start living agile’s underlying values. The IBM research clearly shows that testers are well aware of the problem, and that they need to move beyond “agile in name” to becoming “agile through and through.”
Rall concludes: “That’s why the first item on the agenda should be to change the mindset of the testing team. If they don’t understand the rationale for the change and its underlying concepts, you will end up with a mess—and set them up for failure.”