Inhibitors to Collaboration between Developers and QA Members

Skills

Testers who perform late-cycle testing typically operate on systems using a graphical user interface, an activity that does not normally require programming skills. As evidence of this, testers usually tend to automate tests by recording user interface interactions, with the addition of lightweight scripting. If we assume that testers do not possess strong programming skills, this raises the question of how we can expect them to create tests that interact directly with code.

Testers need the following skills or abilities to participate in early testing of components.

• Testers must understand the nature of components as service providers. That is, they must understand that components provide services via calls to methods in objects that may or may not require parameters and may or may not return values. This implies the need to understand the mechanics of passing parameters in the form of objects and, in the case of languages like Java, to understand concepts such as primitive types and operator overloading.

• Testers must understand the notion of object instantiation and the mechanics of creating object instances and holding them within a fixture.

• Testers must understand how to perform validation on:

  - Simple and recursive object state. That is, testers should be able to describe a strategy of extracting an object's field (or fields), including those of any referenced objects, as required.

  - Returned values, ranging from primitive to complex objects.

  - Exceptions that are expected to be thrown as a result of calling methods under certain circumstances.

• Testers must understand how to test objects that are distributed on application servers, if that deployment scheme is used. In Java, objects that have been deployed on application servers, such as Enterprise JavaBeans (EJBs), require extra effort to test because the test case is a remote client of the bean and needs to interact with middleware to access it.

One possible answer is to train testers to have the minimal programming skills required to develop tests in the required programming language. For testing Java components, implementing a reasonable set of unit tests would require understanding all or most of type casting, primitive/reference type conversions, exception handling, file access, and other Java syntax and language specifics. Unfortunately, training, especially to the level required to write unit tests, incurs a very high cost.

Rapid Design Evolution

XP is low on up-front design and high on rapid evolution through incremental functionality, refactoring, and feedback through testing. Because code is constantly in flux, it follows that tests need to change rapidly as well. Given this, one might conclude that communication and synchronization overhead between developers and testers as code evolves might add an undue burden on the team.

Test First

An ideal practice would be for testers to develop unit tests and then pass them to developers, who would then create code that satisfies those tests. This is certainly a clean separation of labor but ignores the practicalities of evolutionary design that is, that the entire set of interfaces for each component would need to be known beforehand, which is not always the way things work out. It also ignores the benefit of the incremental "create test and write code for test" cycle. An alternative approach would be for developers to follow standard XP practices to create a minimal set of tests that validate basic functionality, with testers following up to add a set of tests that validate interesting variations and boundary conditions.

Poorly Factored Code

Poorly factored code helps no one, least of all test developers. Cumbersome component interfaces, side effects, private implementations, large numbers of dependencies, and high object coupling all contribute to overly complex and convoluted component user stories, which make writing tests for those components that much more difficult. Fortunately, applying the test-first approach as a process imperative helps identify design deficiencies, which then contributes to their elimination.

Note

Within the context of unit testing, a "user story" is a story that describes the interactions necessary to validate some aspect of a component's functionality. In this case the "user" is a consumer of the component's services, such as another component or, in this context, a unit test case. A user story may or may not be as detailed as a use case scenario. The level of detail depends on the test developer's familiarity with the component.