Does anyone remember the kids’ game “Operator” (not, the silly surgery game, Operation). In Operator, which for us was usually played while sitting at the lunch table, the first kid would pick a simple phrase like “there is a cat in my house” and then, they would whisper this phrase into the ear of the person next to them. Of course, since it was a loud lunch-room, it’d get slightly misheard and by the time it had been passed along 20 kids or so, the last kid would hear “there is a flat on my grouse” (which doesn’t make a lot of sense, of course). The final kid would say the phrase they heard aloud and everyone would laugh, particularly when the first kid would announce what they had originally started with. All in all, it was a very silly game, but kids liked it.
Today, we apparently still play that game, only we play it with more serious consequences. When your testers write test cases directly from the system design or technical design, you’re playing operator. Each time down the line, you’re counting on the translation from the prior step to this step to be faithful. Like making a copy of a copy of a copy of a copy of an original document, it just keeps getting blurrier and blurrier.
If you want your testers to produce the most faithful interpretation of the requirements they can, they need to work from the requirements document. If they assume that the analyst or technical lead has done the translation faithfully, then they are working from something that is potentially suspect.
Now, I’m all for using tools to do requirements trace-ability, but I have to say, even with tools like ReqPro or others that offer what they often call “ReqPro Lite” functionality, there’s still sense in making sure that your final check of the system is linked directly back to the original document you started with.
Don’t play Operator with your customer’s requirements. Everyone should hear them first-hand, especially those who are responsible for checking they were implemented properly.