What is Traceability Matrix?

In software testing, an important document is called Traceability Matrix (TM) or Requirements Traceability Matrix (RTM). This is the document that connects the requirements to the test cases. The connection or mapping of the requirements to test cases is many-many. This means that one requirement is tested by one or more test cases. Conversely, it is possible to have one test case addressing one or more requirements.

If you don't understand the RTM, view the video, Requirements Traceability Matrix that explains the RTM with an example.
Next, let us see some useful points about the Requirement Traceability Matrix.

1. A well-designed TM has the Req Ids and Test Case Ids. However, it should not have any text from the requirements or test cases because it is just a mapping. The TM could also contain module/ component/ sub-system Ids against each Req Id (see point no. 9).


2. A TM can be as simple as Req Ids on one axis and Test Case Ids on the other axis. For example, a TM implemented in MS Excel could have Req Ids in a single column (vertically) and Test Case Ids in multiple columns (horizontally). A symbol could mark which requirement maps to which test case.


3. The TM should be created as early as possible in the project. It becomes tedious to create if there are already numerous requirements and test cases.


4. The TM should be updated for every requirement change. New requirement is added or an existing requirement is changed or an existing requirement is deleted.


5. The TM should be updated when a new test case is written. This update could be the final step of completing the test case. If an existing test case is updated or enhanced, the TM should be reviewed for accuracy. The TM should be updated if any test case is retired.


6. One should be careful with workflow changes because they can impact multiple requirements and therefore multiple test cases.


7. It is simpler to update the TM if the requirements and test cases are modular and contain no repetitions.


8. TM is only a document which can become corrupted. Especially if multiple people write to it in an uncontrolled way. Therefore, the TM should be stored in a revision control system with locking and backup/ restore features.


9. If the TM contains module/ component/ sub-system Ids, it becomes simpler to identify the impacted modules whenever a requirement changes.


10. Some project management software or test management software provide automatic generation of TM based on requirements and test cases stored in the system. It is even possible to run the queries against the TM because all its information lives in a database.

Happy testing!