Chief Quality Officer

You: “I’ve got a kick-*** test plan!”
Management: “Prove it.”
Engineering: “Prove it.”
Customers: “Prove it.”

A test plan ain’t a test plan until you can prove it does the job. And that’s where a traceability matrix comes into play. It’s the magical bridge that links what everybody says the product has to have/do/be and what you, my little QA ninja, actually test for.

A good requirements traceability matrix (RTM, from now on) not only helps everyone sleep better at night, knowing that a QA team with superpowers is saving the day, but it can also save your important little butt in the process. Here’s how to make that happen.

Setting That RTM Bad Boy Up
Start with a heaping helping of requirements. Since you’re a super-ninja QA CQO, you already have a master document listing all the requirements/design specifications/industry standards that the powers that be in SuperGloboCorp expect you to be testing against (or a collection of documents that reference each other). These are what you’re using to build up your Ultimate Test Plan.

As you build up that test plan with its powerful army of test cases, you want to make sure that those patriotic little tests are loyal to the cause and completely test against those requirements. Once you do that, building the basic RTM is a cinch. You simply note which requirements are supported by which test cases/suites. Like this:

• Requirement THX-1138 - > Test Cases CYA-9901 thru 9999
• Design Spec. NCC-1701 -> Test Suite RTFM-01
• Conformance Spec. #9 -> Test Case LOL-1337

Manage It All In One Place
What’s important here is that the RTM is its own entity - that you track the linkage between requirement and test in one document, and not as annotations in the requirements docs and the design specs. That is the path of pain, because you’ll never know where/when something gets updated.As long as the specs themselves have identifiers for the important stuff, all you have to do is link those IDs to your tests in the RTM.

Crack The Whip, Or You Are Toast
Don’t forget the most important part of the RTM … enforcing updates like a harsh samurai warrior. Nothing will undo all your hard QA work like having test plans and specifications that get updated separately and, like so many once-happy couples, drift apart. Be the bad guy (or girl) and lay down the law like a cranky mob boss, saying, “you touch-a my spec, you update-a your QA team.”

Bottom line is - you don’t do this, then suddenly you get the blame because the test plan you wrote to test apples doesn’t count anymore because someone in marketing added oranges to the spec, without telling you.

The Short of It
So to sleep like a double-burped, milk-fed baby at night, you need to make sure that:

• You have and understand all the requirements you can get your grubby little hands on
• You have created cry-your-eyes-out beautiful tests that put those requirements to the test
• You can prove it with your solid gold, awesome-plated linktastic RTM.

So get to it, and tell ‘em Dave sent you.