17.8. Summary Fit tests can dramatically improve the quality of existing software. But they can have a much greater impact when they are used to drive additions to existing systems or to drive new developments. In agile development, software evolves as the requirements are better understood and as external changes impact on what's needed. This evolution is managed through ongoing communication among all those involved and through feedback from using the current version of the system. In Extreme Programming, new functionality is based on stories, which are written by Customers and are scheduled into an iteration. One or two Fit tests are developed for each story to help clarify the story and aid developers in estimating the time needed to implement the story. The Customers choose stories for the next iteration, based on their business value and on the cost to implement them. Once the stories are scheduled for an iteration, the Customers and testers develop extra Fit tests to clarify the business rules associated with those stories. All the tests for a story are then used by the programmers to drive the implementation of that story. As questions arise, the programmers discuss the details underlying the story with the Customers, which may lead to additional Fit tests being written. A story is finished when all the associated tests pass and no outstanding issues remain. If the programmers go faster or slower than expected, stories may be added to or removed from the iteration, which is of a fixed time period. Exploratory testing at the end of an iteration can focus attention beyond the automated tests.
We have just skimmed the surface of applying agile software development techniques. There are many excellent books on agile development in general and on particular approaches, such as Extreme Programming [Bec04], [Coc01], [Mar02]. Questions & Answers | Q1: | Is it better to write the tests before development? We write them in parallel. | | A1: | It is better for the programmers to have at least one test to start with. Tests help them to see what the system should do. Tests extend the software just enough to pass the test, so that no work is being done on speculation, and all of it is tested. Some teams think that it's necessary to wait until the software is developed before the tests are written. That's because they write tests that operate through the user interface. We've already seen all the problems that this approach causes. It is essential that the tests be written first, which inevitably means that they have to be independent of the user interface. So it's lucky that that's the best way to write them, for many other reasons too. | | Q2: | But what if test generation is too slow? | | A2: | That's one good reason to develop some tests along with the stories, before the planning game. This happens while the developers are working on the previous iteration. It may mean that some tests are written for stories that are never chosen. But on the other hand, writing one or two tests for each story is helpful to the Customers, as it gets them thinking about some of the issues. The concrete examples in the tests are also helpful to the developers when they estimate the time for a story. If the tests are still too slow in coming, you may need more skilled testers or need to make your tests more expressive. For example, writing lots of workflow tests can be slow and ineffective, as we showed in Chapter 16. | | Q3: | Do other tests often come out of discussions between the programmers and Customers during software development? | | A3: | Yes, this happens all the time. As the programmers are getting into the details of the software, they have to think about issues that may have been missed by others. When they confirm what should happen, the best way to capture these new business rules is to write them as Fit tests. |
|
