Planning and Defining Tests

Toss out those tree-killing test plans. By test plans, we mean the formal documents that describe the scope of the testing, what functionality will and won't be tested, and a list of the tests to be performed for each bit of functionality: positive, negative, boundary, error, and so on. They're usually in some kind of text format that's impossible to maintain.

Be honest: does anyone but you ever actually read these? Why spend a lot of time writing about what you are and aren't going to test? Why spend days producing a document that will be out of date soon and be a nightmare to maintain? The only reason would be that your project management office or other authority forces you to deliver one. If so, keep it as lightweight and useful as possible.

Focus your energy instead on the test cases themselves. Go ahead and use the same techniques we recommend in Chapters 16 and 17: start writing the automated test scripts themselves. If the business experts are more comfortable, use a lightweight spreadsheet format to document them. Get as much input from the customers as you can. Have the business experts and a programmer and/or architect review your test cases and suggest additions, modifications and deletions. Ask the business experts to identify test cases critical to acceptance.

As for test automation, the principles in Chapters 16 25 apply even to traditional waterfall development. Use XP practices such as pair testing and refactoring to improve your productivity and quality. Turn your testing effort into a sort of self-contained XP project. Impress everyone with how quickly and effectively you and your team can automate tests. They may start wondering how you're getting that done and may be willing to try agile practices for software development.