Requirements for a Unit Testing Tool That Enables QA and Development Collaboration

Because we are augmenting the XP process, our view is that we should not significantly change the way developers perform testing, but extend XP to include testers where appropriate. Any test tool should reflect the same viewpoint.

To promote developer and tester collaboration, a test tool should do the following.

• Make it possible for testers to describe the services to be tested and what to validate, without having programming skills. In addition, the testing tool should provide a lightweight test definition representation that is rich enough to represent aspects of testing such as stimuli on objects under test, preconditions, postconditions, invariants, expected exceptions, and input data sources, without the need to write test code.

• Allow developers to continue to develop simply. The testing tool should appeal to developers' preference for lightweight tools and for being able to quickly create test cases as code, preferably in the same programming language that is used for the project. If developers are faced with learning a new scripting language or creating test cases as anything other than code, it reduces their willingness to participate in continuous testing.

• Have built-in test behavior that testers can leverage to create better tests faster. This is important because we do not want to require testers to become bogged down in implementing test-specific infrastructure.

• Enable developers and testers to share their automated test assets so that each group can reference, use, and expand on the other's work. These automated test assets become the common currency of exchange between the two groups. There will be cases where testers create tests to be used by developers and where testers need to integrate more code-intensive tests as provided by developers. A tool should promote back-and-forth sharing and reuse.

• Facilitate brief and concise problem reports so that any problem can be expressed by referencing one or more automated test cases. Now that developers and tests can share a common set of test cases, it is possible to specify problem reports in terms of an automated test case. For example, "If you run x test, it will fail with y results."