Is Quality Negotiable?

are in a unique position to facilitate this process.

I work in the same room as the developers, pair with them when needed, participate in the standup meetings. At the same time, I try to have as much contact with the customer as possible: we discuss the tests, get together to run them, look at the results. Testers are part of the development team—much more so than in a traditional software process. But as a tester, you need a level of detachment; you have to be able to be an advocate for the customer and at the same time a guardian of the developers. This can be a lonely and difficult role at times. The beauty of XP is that you’re never really alone. With the help of your team, you can enhance the customer’s satisfaction.

Running Acceptance Tests
The fast pace of XP iterations makes it difficult for acceptance testing to keep pace with development. It’s much better to do the acceptance testing in the same iteration with the corresponding stories. If you’ve ever done “downstream” testing where you don’t get the code until development is “finished”, you know that developers are looking ahead to the next set of tasks. It’s painful to have to stop the fun new stuff you’re doing and go back to fix something you’ve already put out of your mind.

In our projects, the developers try to organize tasks so that they can give me components to test early in the iteration. This way I can find defects and they can fix them BEFORE the end of the iteration. This means that the estimates have to include time to find and fix bugs. I think it makes everyone happier. There will most likely still be some defects or issues left over that have to become stories for future iterations, but it’s possible to minimize these, and we should try.

As iterations roll along, regression testing of acceptance tests from previous iterations also have to be performed. In an email to the YahooGroup extremeprogramming, Ron Jeffries [2] says that once an acceptance test passes, it should pass forever after, so any regression defects for previously working tests must be addressed.

How do you do acceptance testing that fast? That’s another paper in itself, but here are some tips.

• Make acceptance tests granular enough to show the project’s true progress. Fifty tests of ten steps each is better than ten tests of fifty steps each.
• Separate test data from actions in the test cases. Spreadsheet formats work well; we’ve experimented successfully with XML formats too. It’s easy to produce scripts to go from one format to another; a script that turns your spreadsheet test data into a form your test tool can use is invaluable.
• Identify areas of high business value and critical functionality. Automate tests for basic user scenarios that cover these areas. Add to them as time allows—don’t forget to budget time to maintain and refactor automated tests.
• Modularize automated tests; avoid duplicate code and create reusable modules. For example, if you are testing a web application, have a main script that calls modules to do the work of verifying the various interfaces such as logging in, running queries, adding records and so on. Split functions such as verifying that a given set of links is present in the HTTP response out into separate modules that can be reused from test to test and project to project.
• Make automated tests self-verifying. Both manual and automated tests should produce visual reports which tell “pass” or “fail” at a glance. One way to do this is