Who Is Responsible for Quality?

Quality should be a collaborative effort among the entire project team, which includes everyone involved in getting the software released. The tester is responsible for helping the customer make conscious decisions about quality during the planning process. If the customer is clear about her acceptance criteria and these are reflected accurately in the acceptance tests, you're much more likely to achieve the level of quality the customer wants without giving your time away.

How do various members of the team participate in producing a high-quality deliverable? Customers need to understand their responsibilities in defining quality and writing tests that prove it. If your XP team includes testers, they can help the customer with these tasks and act as customer surrogates if the customer can't sit with the team. Testers can pair with programmers to go over stories and review the finished tasks and stories to make sure the requirements are met.

Programmers can estimate technical risks of stories and provide alternatives to help the customer achieve a balance of quality and cost. By mastering XP practices such as test-first coding and refactoring, programmers build quality into the software. They shoulder their part of the quality burden by taking on tasks related to acceptance testing, such as writing automated test scripts and coming up with ideas on how to automate tests simply and effectively.

All teams need strong leaders. If the team is failing to master a necessary practice and takes no action on it, someone in a position of authority needs to get the team together and decide how to correct the problem. It's human nature to avoid doing things that are hard. We've often found, for example, that programmers who haven't done test-first coding before won't do it unless required to do so by a leader they respect. Once they try this practice, they see the value and keep going, but someone has to push them to start.

Lots of other people are probably involved in the delivery of your software project, even if you don't always think of them as someone "on the team." It's a common misconception that XP projects "don't produce documentation." Of course they do, and if your team is fortunate, you have a good technical writer to help with this task. Someone has to write the paychecks and approve the expense reports. Have you thanked your accountant lately? Someone recruited you into the company and told you how to file a medical insurance claim. Someone buys your office supplies. Someone set up your network, someone fixes your laptop when it dies a big blue death. All these people are on your extended team, and, though their services may be peripheral, they're important in enabling your core team to do its best.