Requirements Testing 101 - Involve Your Team

So many projects suffer from "over the fence syndrome": that is, the business analysts put together a specification (if you're lucky) and throw it over the fence to the developers. The developers code up the system and throw it over the next fence along to the testers. The testers sign off on the developed system, maybe even referring back to the original requirements spec, and then the system gets released - thrown over the really big wall (with the barbed wire at the top) to the customer waiting outside. That's not the way to operate.

In theory, the sort of project I've just described ticks the boxes of "failsafe development": there are requirements specs, analysts, even a team of testers and a release process. So what could possibly go wrong?

The problem is that in this kind of setup, no-one talks to each other. Each department regards itself as a separate entity, with delineated delivery gateways between them. Throw a document into the portal, and it emerges at some other point in the universe, like an alien tablet covered in arcane inscriptions that will take thousands of years for linguistic experts to decipher. Naturally, requirements are going to be misinterpreted. The "sign-off" from the testers will be pretty meaningless, as they were never closely involved in the requirements process: so their understanding of the true business requirements will be superficial at best.

Really effective testers will question the requirements and spot loopholes in business logic. And you'll be eternally grateful to them when they prevent a project from being released into production with faulty requirements. But the testers don't stand a chance of doing this if they're not closely involved with developing the requirement tests.

Let the testers "own" the requirement tests (i.e. be responsible for their development and maintenance). The customer and your business analysts build the requirements up; the testers write tests to knock them down again.

Another way to think of the business tests suite is that it's an independent audit created by a testing organization to show that the system created by the developers does what the customer intended. If the developers are left to manage the testing themselves, then you end up with the Green Bar of Shangri-La syndrome: the system tells us there's a green bar, so everything's okay man... This is why it's vital to have a separate team - the QA testers, who are answerable to the business, not to the developers - verifying the software. And if the testers are involved early enough, they will also verify the requirements themselves.

DDT Chapter 8 (Requirements Testing) is now up on the Apress Alpha Books page...