Many organizations segregate their programmers and testers in order to achieve independent validation of requirements.  If the system is tested according to an independent interpretation of the requirements than used for implementation, then errors in those interpretations may be detected.

This course of action is obviously prudent when the requirements are handed down to the development organization in the form of a document. It does not, of course, detect errors in the requirements document itself. Nor does it detect errors of interpretation if both the programmers and the testers read the requirements in the same, incorrect way. When there is significant distance between writer and readers, this is distressingly common.

It’s difficult work to write clearly in prose. Publishing industries have developed the roles of editor and proofreader to check documents so that erroneous or unclear segments may be rewritten before they’re seen by potential readers. People who write requirements documents are frequently better versed in the desired functionality than in the process of writing them. And, they frequently don’t have so much help.

It’s also difficult to precisely interpret the writings of others, particularly of people you don’t know. A word may have an obvious and precise meaning in the context of the business, but an obvious and different meaning in the context of software development. In the fields of literature and law, expert interpreters may spend years or centuries honing a consensus interpretation of the written word. In software development, we rarely have time for lengthy discussion of complicated passages. If the writing is ambiguous or contradictory, faithful interpretation of the intent is even less certain.

We often seek clarification of the requirements to back up our reading of the document. Sometimes it’s difficult to get sufficient access to the document authors, and the programmers and testers may turn to each other for what clarification they each offer. I’ve had testers from a different company ask me how my software was supposed to work because they had insufficient access to the requirements document author.

Cross-checking the interpretation of programmers and testers punches holes in the wall of independence, of course. This sad state of affairs is a major source of defects in which the software “works as designed” but not as desired.

We can do better than this!

Instead of the business representative writing the requirements and handing them off as a document, imagine the business representative telling them to a programmer and tester (everyone taking notes as needed to keep things from being forgotten). Imagine the programmer and tester testing their understanding in real time with questions made directly to the business representative while things are still fresh on everyone’s mind. In doing so, they can not only challenge each others interpretation of the requirements, but also the assumptions of the business representative. Together they can hone the requirements to a sharper edge than possible when working separately.