This can come in many forms and this is probably an over simplified snippet.
|User Account Forms: Add User||1.1||1.1.1||22.214.171.124|
|User Account Forms: Delete User||1.3||1.3.2||126.96.36.199|
This method attempts to provided callbacks to the BRD, SRS, and Test Plan regardless of where one enters the line of inquiry. Each type of entry ( usually the BRD, SRS and Test Plan are all entered into a tool such as TFS ) should allow you to review its associated counterparts. More advanced usages of the traceability matrix include qualitative aspects such as:
- how many data points a test covers
- test case totals rows for each item in the SRS/BRD
- overall level of complexity for all test cases as a whole
There are many software packages that offer numerous variations on this and each has their own take. The main idea to take away is that it should be easy to start with the:
- BRD and query for applicable SRS and Test Case items
- The SRS and query for applicable BRD and Test Case items
- Test Plan/Cases and query for the applicable BRD and SRS items
Wikipedia hosts a well written synopsis of the tool, so I won't re-hash it here:
This version of the matrix should give insight to overcomplexity within the BRD, SRS, Test Plan, or any component thereof. In kind, a 1:1 relationship between them indicates a lack of efficiency. See my 'Agile Trifecta' post to contextualize what you want from this table.... A BALANCE IN COMPLEXITY with ADEQUATE COVERAGE. The client isn't paying for 4000 test cases, they're paying for software that works. Too many test cases for a requirement item might indicate the requirement is too vague or over-reaching.
In the wikipedia example, there are test cases that check off items across functional areas. I'm not a big fan of this practice as if something changes in the test case or SRS, implications can get complicated. I opt to limit this practice to WITHIN an SRS SECTION or FUNCTIONAL FEATURE. Reasons include:
- Feature changes won't destroy cohesion of the test plan
- No need to scour entire plan for implication of changing a test case/SRS/BRD item
- When feature changes occur, existing test may still be valid for other functional areas
This doubly applies when automation is in play. The cost to perform the same action twice is basically nil in the world of automation so it is more efficient to disregard what tests are run to perform functional testing in other areas and create complete and comprehensive tests on a per-feature basis. This makes reporting clearer, eases updates and maintenance, and simlifies the Traceability Matrix on the whole. Too much dependency and interoperability of tests and their associated SRS line items can quickly become overwhelming if things are changing rapidly. With that said, there is no problem - as in the case with orthoganal test strategies - for one test to check off numerous items in the SRS; just keep it within a functional area.