Chapter 16. Writing Acceptance Tests


We have now accumulated quite a fair bit of information about the acceptance tests. If this were a traditional software project, we'd begin writing the information down in the form of an acceptance test plan or acceptance test design, and possibly both. But since this is an Extreme Programming project, we're going to skip all that and go directly to writing the tests. We aren't going to write documents about the tests; we're going to write the tests themselves, in an executable format, so we can start running them early and as often as possible.

This may seem a bit radical if you're accustomed to spending several weeks (or months!) writing, reviewing, and revising documents about testing prior to actually doing any. You don't have time for that on an XP project. The primary function of acceptance tests on an XP project is to pass or fail, and thereby provide feedback on the project's progress or lack of progress toward the customer's goals. The entire iteration will be completed next week, and the first running code is probably going to be available tomorrow. You must have a bias for getting tests running as quickly as possible.

You still have plenty of details to work out, and doing so with the customer and the rest of the team will increase their understanding of the stories. This will help them avoid some types of defects altogether and will take the place of the traditional review cycle on documents about testing. As you get the details about how the system should behave, you put them directly into the executable tests.



Testing Extreme Programming
Testing Extreme Programming
ISBN: 0321113551
EAN: 2147483647
Year: 2005
Pages: 238

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net