All of these problems combine to make Test perpetually perceived as the “long pole”, since most Test work is done very late in the milestone. Most modern product and feature teams acknowledge that involving Test early in the development process (that is, including testers in the feature specification process from at least the first spec review) brings big dividends. We can test the spec itself, ferret out inconsistencies, and identify areas that are not as testable as they could be.

We can also define our test cases at a conceptual level. We could write the test cases as well, but the effort required to keep each test case up-to-date in the face of continued changes in the feature definition, feature implementation, and fine tunings of the feature’s UI can be overwhelming and is often not worth the trouble.

As a result, testers can’t write very many tests until their developers release functionality to them. At this point the developers are done (until such time as the testers start logging bugs against the features, anyway) and so move on to something else. Implementing test cases and helper methods and test infrastructure takes time. Testers find and log bugs from the moment they start this process, but as the developers are now immersed in something new and exciting they are often reluctant to put that work down and return to a feature they are “done” with. Thus bugs languish and test cases incorporate workarounds that must later be removed when the corresponding bugs are fixed. By the time a tester finishes all this work another set of functionality has been released and is waiting for their attention and the cycle starts all over again.

We have developed a process for front-loading much of the testing process and for enabling Development and Program Management to do their part in the testing process without breaking the “separation between church and state” that a separate Test organization provides.