| Consider a particular implementation of the described XP process augmentation. A company, "C," moved from a traditional development process toward XP. After successful early product iterations, time pressures and perhaps a reluctance to spend time creating tests bore down on the developers, and they began to do less unit testing. The QA team, recognizing lower quality levels in the code they were receiving, decided to step in to provide testing. The team adopted the following guidelines. -
The team standardized on the use of both JUnit and Test Mentor for unit testing. They took advantage of Test Mentor's integration with JUnit and the ability to enable testers to create unit tests simply. -
Each day the development and QA team conducts a stand-up meeting in which testers and developers coordinate which tests are going to be needed to validate components. If it turns out that a tester is too loaded with work to be able to supply a test to a developer within the required time, the developer takes on that test development task. -
Once a component is identified and its interface is defined, the developers involved sit down with a tester and define a set of component user stories. At this time they perform light design of the tests to identify which tests should be developed by the tester and which ones by developers. Often, this dialog identifies design decisions that hamper testability, which may then result in redesign or refactoring of the component in question. -
Developers create unit tests for lower-level and implementation-dependent component functionality. This functionality typically is not part of the component's public interface. -
For distributed components such as EJBs,developers are responsible for deploying the components on an application server and notifying the testers of how to access them. -
As the end-user interface becomes available, testers transition into a more traditional role of validating at that level.
Observed Results The quality of unit tests, as shown by Test Mentor's code coverage profiling, has improved because of the dialog between testers and developers in designing those tests, and as a consequence, the quality of the code under test has also improved. Despite their general reluctance to create tests, the developers are perfectly happy to run tests created by testers, as a gateway to code release. An unanticipated but beneficial side effect is that developers tend to be more inclined to build on existing tests created by testers than to create and organize tests completely from scratch. Testers have a higher rate of use (they are more consistently occupied) throughout the development process. |
