Crispin, Lisa - Agile Testing - A Practical Guide for Testers and Agile Teams

Celebrate Success

Implementing change takes time and can be frustrating, so be sure to celebrate all successes your team achieves. Pat yourselves on the back when you meet your goal to write high-level test cases for all stories by the fourth day of the iteration. Get the team together for a trivia game or lunch when you’ve just delivered an iteration’s worth of work. Acknowledgment is important if you want a change to stick.

Chapter 18, “Coding and Testing,” covers how testers and programmers work together throughout the development process.

Integrating testers into development teams while letting them continue to report to a supportive QA manager is one way to ease the transition to agile development. Testers can find ways to move from an adversarial relationship with programmers to a collaborative one. They can show how they can help the team understand the customers’ needs and deliver appropriate business value. They can host enjoyable activities to build good team interactions. Having cookies or chocolate available for teammates is a good way to get them to walk over to your desk! Patience and a sense of fun are big advantages.

Overcoming Resistance to Agile

Mark Benander, a Quality Assurance Team Lead with Quickoffice, was on his fourth project on an agile team. The first was a major rewrite of their entire application, with a team of eight developers, one tester, and no test automation tool. He told us about his experiences in overcoming his concerns about agile development, especially about reporting to a development manager.

We were in a matrix management type of system, where a tester reports to a development manager, but the test manager is still officially the supervisor. This comforted me somewhat, but the majority of the issues I expected to occur, such as being overruled whenever I found an issue, never did. My concern wasn’t that I’d really end up thinking like a developer and just releasing anything, but that my manager, who was not a tester, wouldn’t care as much, and might not back up my concerns with the application.

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.

In all cases, managers need lots of patience during what might be a long transition to a high-functioning agile team. It’s their job to make sure they provide the necessary resources and that they enable every individual to learn how to do high-quality work.

A Testing Manager’s Transition Tale

Tae Chang manages a team at DoubleClick that conducts end-to-end testing to ensure that all integration points, both up and downstream from the target of change, are covered. When they implemented Scrum, the development teams were reorganized into numerous application teams. Communication problems resulted in missed dependencies, so Tae’s team stepped up to help make sure problems were detected early.

Tae told us, “I believe agile development effectively magnified the importance of cross-team communication and a coordinated end-to-end testing effort. It was not easy to work out a noninvasive (in terms of fitting into current sprint structure) integration testing process; in fact, we are still tweaking it, but the overall benefit of such a testing effort is apparent.” Their teams began to slide into the “mini-waterfall” trap. “In retrospect,” explains Tae, “one of the reasons for this is because we started with the agile process before internalizing agile practices.”