Independent Interpretation

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.

Post to Twitter Post to Plurk Post to Yahoo Buzz Post to Delicious Post to Digg Post to Facebook Post to MySpace Post to Ping.fm Post to Reddit Post to StumbleUpon

Comments (2) to “Independent Interpretation”

  1. Hi George,
    Having been a tester & developer in exactly the approach you’ve described (i.e. the better approach), I have found the shift of a tester’s focus changes a bit. It’s no longer limited to simply verifying that the requirements are met – it grows. It starts to include testing with an eye to making the product BETTER. This shift results in higher-value testing. There are tools for helping testers get better at this, namely the HICCUPPS heuristic from exploratory testing. Check it out if you aren’t familiar with it.

    Dave

  2. Hey George,

    In modern/agile/lean software shops we are finding that the focus on PREVENTING bugs is working far better than bug hunting alone ever has. In fact, I’ve been coaching and practicing dev/tester pairing, at least as far as code walk-throughs go. When a dev explains to a tester how a feature or bug fix is coded, in addition to finding bugs, issues can be prevented, and missing code and requirements can be found sooner.

    This became it’s own blog post I went off for so long. :)

    You are right! We can and are doing better than this isolated, old-school nonsense!

Post a Comment
*Required
*Required (Never published)