Agile Testing: A Practical Guide for Testers and Agile Teams

Ultimately, I think I ended up thinking slightly more like a developer, being less concerned about some of the small bugs. My better understanding of the application’s workings made me understand that the risk and cost of fixing it was potentially much more risky than the benefit. I believe that thinking like this isn’t a bad thing as long as we are always mindful of the end customer impact, not just the internal cost.

The corollary to my thinking more like a developer is that the developers began thinking more like testers. I’m actually a fan of the adversarial role of the tester, but in a relaxed way. I actually give the developers gold stars (the little sticker kind you used to get on your spelling test in second grade) when they implement an area of code that is especially solid and user friendly, and I give out pink stars when they “implement” a bug that is especially heinous. They groan when I come over, wondering what I’ve found now, and take great joy in “making my job boring” by testing their code themselves and giving me nothing to find. Needless to say, you need the right group to be able to work with this kind of faux-hostile attitude. I’ve never been in another company where this would have worked, but I’ve never worked in another company where spontaneous nerf gunfights broke out either.

Mark’s experience matches our own and that of many other testers we’ve met who’ve moved from traditional to agile development. If you’re a tester who just joined an agile team, keep an open mind and consider how your teammates might have different viewpoints.

Management Expectations

When we think of challenges involved with adopting agile, we generally think of the actual team and the issues it encounters. However, for successful agile adoption, management buy-in is critical. In a phased project, management gets regular updates and sign-off documents indicating the end of each phase. Upper-level managers might not understand how they’ll be able to gauge agile project progress. They might fear a loss of control or lack of “process.”

Cultural Changes for Managers

In an agile project, expectations change. In her previous life in waterfall projects, Janet remembers hearing comments like “this feature is 90% done” for weeks. Those types of metrics are meaningless in agile projects. There are no sign-offs to mark the end of a phase, and the “doneness” of a project isn’t measured by gates.

Meaningful metrics are determined by each project team. In Scrum, sprint and release burndown charts track story completion and can give managers a measure of progress, but not any hard “dates” to use for billing customers. Test matrices can be used to track functionality test coverage but do not provide sign-off documentation.

The other change that is difficult for some managers to understand is letting the teams make their own technical decisions and manage their own workloads. It’s no longer the manager who decides what is good enough. It is the team (which includes the customer) that defines the level of quality necessary to deliver a successful application.

Agile teams estimate and work in smaller chunks of time than traditional teams. Rather than building in contingency, teams need to plan enough time for good design and execution in order to ensure that technical debt does not increase. Rather than managing the team’s activities at a low level, managers of agile teams focus on removing obstacles so that team members can do their best work.

Janet’s Story

I asked the vice president in charge of a large agile project what he found to be the most difficult part in the new agile environment from a management perspective. He said that in a traditional waterfall type project, the reports all showed that everything was going according to plan until the very end, and then everything was in a panic state and “nothing worked.”

In the agile project, there were problems every day that needed to be addressed. Agile projects were more work on a consistent basis, but at least he was getting realistic reports. There were no surprises at the end of the project.

—Janet

Business stakeholders don’t like surprises. If they can be convinced to give the team enough time and resources to make the transition, they’ll find that agile development lets them plan more accurately and achieve business goals in steady increments.

Sometimes it’s actually management that drives the decision to start doing agile development. The business leaders at Lisa’s company chose to try agile development in order to solve its software crisis. To be effective, they needed to have a different set of management expectations. They needed to be sensitive to the difficulty of making big changes, especially in an organization that wasn’t functioning well.