Traceability matrix (sometimes can be named requirements traceability matrix or (R)TM) is a tool in software testing. How and why is it applied? It depends on the form in which it is created.
In its most basic form, it shows which of the customer’s requirements are already checked with tests and which are not. In a more advanced form, it can be used as an analytics and metrics evaluation tool.
To better grasp the definition above, let’s start by breaking down what is traceability in software testing.
The term ‘traceability’ includes two words: ‘trace’ and ‘ability’. ‘Trace’ means to track down step by step and find something; in our case — the tests and requirements. And ‘ability’ is confirmation that it can be completed. In other words, traceability is the property of the subject to be under observation every moment of its existence, as well as the fixation of changes occurring to it.
In software testing, engineers are not interested in traceability itself, but in its level. And precisely RTM because of its properties shows us this level. It looks just like a standard two-dimensional matrix, which has rows and columns and in such a way connects two sets:
- software requirements;
- test cases.
How does traceability matrix (with example) look like
A TM implemented in basic form is a table where:
- the first row (from left to right) involves unique numbers of test cases;
- the first column (from top to bottom) involves unique numbers of requirements.
And at their intersection, there are marks that show how the requirement corresponds to the test case. These marks can be any symbol (e.g., ‘+’) or just shaded cells.
Simplest RTM
A quick glance at this visualization can inform you whether all requirements have been checked or not. Also, you can conclude where the number of tests is excessive and where they are insufficient.
Nonetheless, if you spread the traceability matrix by adding advanced parameters to it, it will be even more useful. But to understand what its value is and how exactly a software tester can use RTM, it is worth discussing its classification.
Types of software testing traceability matrix
Common classification of traceability matrix (TM) is:
- forward TM;
- backward TM;
- bidirectional TM.
These types are directly related to extending the matrix by adding parameters.
Explaining the forward TM, the expansion comes due to additional test parameters. That is, in the table we specify not only test IDs, but also, for instance, their description, current statuses, and dates of addition.
In the case of the backward TM, we add requirements parameters. That is, besides identifiers we specify their other features, for example, who added them and who approves them.
Speaking of the bidirectional TM, we can call this type an amalgamation of the previous two. That is, we can add parameters of both datasets.
There is also another classification:
- 1 to 1. Each item is linked to only one item.
- 1 to n. One requirement can be tested by several different tests.
- n to n. Multiple items can be linked to multiple items. Keep in mind that there can be no RTM where one case covers many requirements.
What type of traceability matrix to choose
It depends on what your goals are. And that brings us back to the question of how exactly RTM can be useful.
Forward TM is handy when you want to evaluate exactly how the requirements are tested. And backward TM allows to go deeper into understanding the requirements themselves. Accordingly, if you don’t know which is more essential to you, choose the third type of TM.
Benefits of RTM for project and QA engineers
When talking about software testing, test cases are more often considered than requirements. Why, then, do you need the second type of TM?
Well, it should be understood that this tool is needed not only by QA engineers. It helps improve the final product and its development process in general. Therefore, it is useful for all those involved in it, especially business analysts and project managers. And these specialists work more with the customer and his requirements.
But it should be noted that, one way or another, you all have one goal: to create a product that satisfies the customer. And make it right away. RTM just protects us from situations where it turns out that some requirement was not paid enough attention to. Or the testing wasn’t done correctly.
Quality assurance engineers find it easier to work with RTM at their fingertips if the requirements:
- are frequently updated;
- are not all currently in development;
- need visual prioritization;
- can be divided into sub-requirements and tested by individual cases.
In addition, with the traceability matrix, you can quickly spot technical debt by documentation.
How to create (R)TM
Since RTM is primarily a table, you can easily create it with any table tool. For example, Microsoft Excel or Google Sheets.
Important: There is no generally accepted tool in which you must create an RTM. So if you prefer some other program with similar features (and your manager is okay with that), you can safely use it.
Your next steps depend on which matrix you decide to create. But in general, they can be fit into this scheme:
- Decide independently or with a team which parameters you will monitor.
- Determine their order.
- Draw them up in the selected program.
Now let’s see in detail what parameters you can operate with to build a RTM.
For requirements:
- Name and description. It must be short and clear.
- Business needs. You must describe what rationalizes the requirement — in other words, why it is needed.
- Who requested it and, accordingly, who approves it.
- References to the specification and design.
- Project objectives, meaning what goals the requirement meets.
Again, the list can be expanded or narrowed as needed.
For test cases:
- The priority — how important it is.
- Title and/or description. It also shouldn’t take up a lot of space and be complicated.
- The current status. For instance, it may be ‘in progress’ or ‘need to be updated’.
- Whether it is automated — at the ‘0/1’ or ‘True/False’ level.
- Estimation. The unit of measure for this parameter is determined on each project individually.
Conclusion
If you are wondering what is a requirements traceability matrix (RTM) and in what way it differs from a traceability matrix (TM), the answer is that it doesn’t. They are the same instrument — a table that displays the connection between requirements and test cases.
The value of RTM depends on the number of its parameters. In its simplest form, this tool shows the level of test coverage of the requirements. Advanced RTM can be used by QA engineers for testing analytics.
Also, let us add that the usefulness of RTM is negated if you don’t put up-to-date data into it.
