Satisfying Customer Test Documentation Requirements

Chapters 16 and 17 showed some ways to document acceptance tests for an XP project. A spreadsheet can work well for test cases, but for larger projects, the customer may feel more comfortable with a formal test plan. If you're a consulting company working for an external client, your client may require this. You have to meet your customer's needs, even if they don't seem to fit well with XP. Flexibility is required on both sides to introduce XP into an organization.

If you have to write a test plan, use it as a place to define processes to be used for the project:

• Definition of the scope of the testing

• Procedures for reporting, tracking, fixing, and retesting defects

• Definitions of severity levels for defect reports

• Procedures for doing builds

• Definition of roles and responsibilities of programmers, testers, customers, support staff

• Definition of schedules and milestones

• Definitions of all the test phases included before release

• Communication process

• Plan for deployment

You can find a sample test plan at www.xptester.org. If you're working with large projects, take a look at this sample. It will give you ideas on coordinating work of multiple teams and handling multiple post-development test phases.

If you're a consultant or contractor developing software for an external customer who has their own testing organization, you need someone to work with that organization to agree on test procedures and coordinate the release all the way to launch. The XP team's tester may not have enough bandwidth for these activities, so consider having another tester or a project manager perform this role. For more ideas, read the discussion in Chapter 31 of alternative approaches to a shortage of testers.