Early Involvement of Testers

Think of the Eiffel Tower. Think of that wonderful photographic series of its construction by Boyer Viollet showing the tower rising upwards in stages. We see each stage building on the foundation laid by the previous one. Naturally, any defects introduced in the early stages will result in disaster for the latter ones.

Think of software. Think of its construction where each stage of its construction — scoping, requirements, design, etc. — builds on the foundation left by the previous ones. Now think of testing. The software is tested when it is close to being delivered, and rarely do the testers become involved in testing the earlier deliverables. This is the equivalent of Gustav Eiffel building to the top of his tower and saying "Alors! Now I will test the concrete foundations to see if they can carry the full load."

There are many deliverables in software development that benefit greatly from being tested. And generally speaking, the earlier the deliverable, the greater the benefit gained by testing it. The early trilogy of Scope—Stakeholders—Goals is the foundation that the requirements activity is built on. And yet, I rarely see testers involved to drive out any ambiguities or inconsistencies in these crucial deliverables.

Think of this. The scope document should have several properties: it should firstly be clear as to what is included in the business area under study, and what is excluded. It is easy enough to test that this document (preferably diagram) has clean, sharp edges. It is not that difficult to test the list of stakeholders — the people who provide the requirements — to ensure that all of them are linked to the scope, and that none have been overlooked. Is the goal an unambiguous statement of intent that conforms to the scope (and vice versa); it is achievable within the budget and will it provide a benefit to the organisation?

Why should testers be doing this kind of testing? Because they are the best people in the organisation to do it. Testers are, by and large, people who see things in black and white: it works; it does not work. This is the correct scope; this is an incomplete scope. This goal is correctly measured, and it is compatible with the scope; or it is not.

There are more. Requirements are early deliverables that can profitably be tested: Is this requirement within scope? Does it have a fit criterion, or some other way of measuring whether its implementation exactly matches the requirer's need? And obviously, is it the right requirement? The design of the software, the architecture, and others all benefit from the early involvement of the testing crew.

The savings from early detection of errors of staggering. Each year, corporations spend millions (estimates go up to $3 billion) correcting errors in their software — errors that were introduced early in the development process (60% are introduced at requirements time) and discovered late, when correction is most expensive. And yet, the cost of the kind of testing I am advocating is tiny.

If you are sceptical about what I am saying, go ask your testers.

  — James Robertson