One trap to avoid is having testers write the unit tests. Because TDD is reallymore of a design activity, it’s essential that the person writing the code also write the tests, before writing the code. Programmers also need the immediate feedback that automated unit tests give. Unit tests written by someone else after the code is written might still guard against regression defects, but they won’t have the most valuable benefits of tests written by the programmer.
Lisa’s Story
Whenever I’ve wanted to effect change, I’ve turned to the patterns in
“Ask for Help” was one pattern that helped me. This pattern says, in part: “Since the task of introducing a new idea into an organization is a big job, look for people and resources to help your efforts” [Manns and Rising, 2004]. When I wanted my team to start using FitNesse, I identified the programmer who was most sympathetic to my cause and asked him to pair with me to write FitNesse tests for the story he was working on. He told the other programmers about the benefits he derived from the FitNesse tests, which encouraged them to try it too. Most people want to help, and agile is all about the team working together, so there’s no reason to go it alone.
“Brown Bag” is another change pattern that my teams have put to good use. For example, my current team held several brown bag sessions where they wrote unit tests together. “Guru on Your Side” is a productive pattern in which you enlist the help of a well-respected team member who might understand what you’re trying to achieve. A previous team I was on was not motivated to write unit tests. The most experienced programmer on the team agreed with me that test-driven development was a good idea, and he set an example for the rest of the team.
We think you’ll find that there’s always someone on an agile team who’s sympathetic to your cause. Enlist that person’s support, especially if the team perceives him or her as a senior-level guru.
—Lisa
As a tester on an agile team, there’s a lot you can do to act as a change agent, but your potential impact is limited. In some cases, strong management support is the key to driving the team to engage in Quadrant 1 activities.
What Can Managers Do?
If you’re managing a development team, you can do a lot to encourage test-driven development and unit test automation. Work with the product owner to make quality your goal, and communicate the quality criteria to the team. Encourage the programmers to take time to do their best work instead of worrying about meeting a deadline. If a delivery date is in jeopardy, push to reduce the scope, not the quality. Your job is to explain to the business managers how making quality a priority will ensure that they get optimum business value.
Give the team time to learn, and provide expert, hands-on training. Bring in an experienced agile development coach or hire someone with experience in using these practices who can transfer those skills to the rest of the team. Budget time for major refactoring, for brainstorming about the best approach to writing unit and code integration tests, and for evaluating, installing, and upgrading tools. Test managers should work with development managers to encourage practices that enhance testability and allow testers to write executable tests. Test managers can also make sure testers have time to learn how to use the automation tools and frameworks that the team decides to implement.
It’s a Team Problem
While you can find ways to be an effective change agent, the best thing to do is involve the whole team in solving the problems. If you aren’t already doing retrospectives after every iteration, propose trying this practice or some other type of process improvement. At the retrospective, raise issues that are hampering successful delivery. For example, “We aren’t finishing testing tasks before the end of the iteration” is a problem for the whole team to address. If one reason for not finishing is the high number of unit-level bugs, suggest experimenting with TDD, but allow programmers to propose their own ways to address the problem. Encourage the team to try a new approach for a few iterations and see how it works.
More about retrospectives and process improvement in Chapter 19, “Wrap Up the Iteration.”