In traditional project testing we use the V model. In the V model, we have five or more levels of testing. At each level, we use one of the traditional project documents as the basis of validation for various system components. At the top of the V and the furthest apart on the diagram we have the first document we produced. Often this is the habitually insubstantial business case validating the very latest and most up to date output we deliver (the release).

So, a business case document so eagerly released many months before our eagerly awaited project began is used as the font of knowledge to approve the outcome of a lengthy project involving many twists and turns and changes of direction as well as many new stakeholders disconnected with the original business case. Hmm, Let us look further.

The requirements document is used to validate acceptance, the system specification is used for system testing, the system design is used during interface testing and component design documents are used as the arbiter of component testing. As you will doubtless appreciate, we rely on total accuracy and consistency in the documents as the final authority on system acceptance and quality. We rely on the deep understanding of the author and the accurate interpretation, without any ambiguity, of the document reader.

We make the assumption that the original author was exact, accurate, complete and thorough in their description and, if we cannot make that assumption, we introduce enhancements to the document as well as business processes to augment our understanding and to repair this process. In many cases, because we like specialists with specialist roles, the author of the original document has long since moved on to another project to perform the same job.

We make the assumption that the reader of the document can interpret the document to its full extent and accurately. In our experience of traditional projects, these documents are produced with a focus on requirements, system specification design not with a focus on how the elements of the system are going to be tested. So the reader of a document is to interpret the deep, true and full meaning before they can set about understanding the tests.

If we cannot make these assumptions, we set about reviewing the original documents in a meeting or a workshop with the author interrupted on their new project along with a larger, broader business audience than was used to derive the original document. These debates are often lively though, from a business perspective, provide little added benefit (though use substantial costs) other than update the author with the latest status of the project.

As you move down the shape of the V model, the closer the two activities become in time and hopefully, in accuracy. So, component testing follows swiftly after component development which, in turn, followed swiftly after component design. These, in theory, will demand less debate. However, the V model has another hidden trick waiting to catch you.

It says that, at component level, you should use an independent team to test components. So, yet another stream of people will read, understand, ask questions, harass you with e-mails about the documentation surrounding your component design and development.

Do not get this wrong, we have worked within independent testing teams and they have a value, an important value but not (in our view) inside the V model. There is a more efficient way and this is where the V model can be challenged. In the Toolkit, we do not rely on weighty tomes of dusty paper to approve or disapprove the intense (and often expensive) efforts of learned and professional teams. We rely on the people inside those learned and professional teams.

We do not throw away the business case idea. A business case is an important concept. It is important because it describes the original objectives of the project. We do not throw away the project requirements list. The project requirements list is an important document. It is used throughout the project to validate whether we have achieved and delivered our project requirements. You will see elsewhere in the Toolkit, there are other vital documents too.

However in the Toolkit, we do not dictate that your components are documented, that the overall design of your system is documented that you produce a system specification. That decision is driven by guidance, given by and in liaison with, your technical coordinator (for more information see roles & responsibilities). The governance rules of your organisation may dictate, at this point in time, that all projects will provide such documentation. In our experience, as the organisation performs more and more agile projects using the Toolkit it gradually understands that it needs such documentation less and less.

Does this mean my testers will do less? No. They will do no less and they will do no more, it is just that the emphasis for the responsibility of quality has shifted to the business. Testers will work more directly with the business, day-to-day. The testing team is there to guide and to provide promotional advice to the business team, on the subject of testing.

The change of role and the importance of the testing team is something that, unfortunately, takes an organisation a lot longer to learn and to deploy. The change to agile testing is fundamental and we believe the V-model is dead in its current guise but agile teams and agile testers will formulate their own versions as agile testing is localised.