Читаем Agile Testing: A Practical Guide for Testers and Agile Teams полностью

Responding to change is a key value for agile practitioners, but we’ve found that it’s one of the most difficult concepts for testers. Stability is what testers crave so that they can say, “I’ve tested that; it’s done.” Continuously changing requirements are a tester’s nightmare. However, as agile testers, we have to welcome change. On Wednesday, we might expect to start stories A and B and then C the next Friday. By Friday, the customer could have re-prioritized and now wants stories A, X, and Y. As long as we keep talking to the customer, we can handle changes like that because we are working at the same pace with the rest of team.

Some agile teams try to prepare in advance of the next iteration, perhaps by writing high-level test cases, capturing business satisfaction conditions, or documenting examples. It’s a tricky business that might result in wasted time if stories are re-prioritized or greatly changed. However, distributed teams in particular need extra feedback cycles to get ready for the iteration.

Lisa’s Story

Our remote team member used to be our on-site manager. He’s a key player in helping the business write and prioritize stories. He has in-depth knowledge of both the code and the business, which helps him come up with creative solutions to business needs. When he moved to India, we looked for ways to retain the benefit of his expertise. Meetings are scheduled at times when he can participate, and he has regular conference calls with the product owner to talk about upcoming stories. We’ve had to switch from low-tech tools such as index cards to online tools that we can all use.

Because the team was willing to make changes in the way we worked, and looked for tools that helped keep him in the loop with ongoing changes, we were able to retain the benefit of his expertise.

—Lisa

Some teams have analysts who can spend more time with the business experts to do some advance planning. Each team has to strike a balance between brainstorming solutions ahead of time and starting from scratch on the first day of each iteration. Agile testers go with the flow and work with the team to accommodate changes.

Automated testing is one key to the solution. One thing we know for sure: No agile team will succeed doing only manual testing. We need robust automation in order to deliver business value in a time frame that makes it valuable.

Self-Organize

The agile tester is part of a self-organizing agile team. The team culture imbues the agile testing philosophy. When programmers, system administrators, analysts, database experts, and the customer team think continually about testing and test automation, testers enjoy a whole new perspective. Automating tests is hard, but it is much easier when you have the whole team working together. Any testing issue is easier to address when you have people with multiple skill sets and multiple perspectives attacking it.

Lisa’s Story

My team is a good example of a self-organizing team. When we implemented Scrum, we had a buggy legacy system and no automated tests. Making any changes to the code was risky at best. Our manager probably had some excellent solutions to the problem, but he didn’t suggest them. Instead, we explored the issues and came up with a plan.

The programmers would start implementing new stories in a new, testable architecture, using test-driven development. The testers would write manual regression test scripts, and the entire team—programmers, testers, the system administrator, and the DBA—would execute them on the last two days of every iteration. The testers (at the time, this meant me) would work on an automated regression smoke test suite through the user interface. Eventually, the architecture of the new code would let us automate functional tests with a tool such as FitNesse.

We implemented this plan in baby steps, refining our approach in each iteration. Using the skills of every member of the team was a much better approach than my going off and deciding the automation strategy on my own.

—Lisa

When an agile team faces a big problem, perhaps a production showstopper or a broken build, it’s everyone’s problem. The highest-priority issues are problems for the whole team to solve. Team members discuss the issue right away and decide how to and who will fix it.

There’s no doubt that Lisa’s manager could have mandated that the team take this approach to solving its automation problems, but the team itself can come up with the most workable plan. When the team creates its own approach and commits to it, its members adopt a new attitude toward testing.

Focus on People