So, what is a Requirement Traceability Matrix?
A requirement traceability matrix is a document that helps provide a mapping between the requirements and the test scenarios/test cases. The only intent with which it is built is that none of the requirements is left been untracked. It helps to ensure all test cases or test scenarios have a mapping requirement, thereby providing full coverage of your requirements.
During the time of waterfall model, RTM was usually encouraged due to the presence of a detailed level of BRD’s(Bussiness requirement document) and FRS(Functional requirement specification) documents available. It was important to ensure all those requirements were mapped to the test scenarios/test cases and none were left without test cases. With emerging methodologies like Agile, the requirement of RTM was not needed as majorly user stories were provided by Bussiness Analyst or product owners which were already drilled down to smaller chunks of functionality. Hence test cases were written across them and one is able to track them.
I usually prefer not to make or have RTM in an agile environment because of its fast-paced nature and more focus towards delivering quality work in the shortest turn around time.
Let’s peek into, what are the key features of an RTM and how do we make it.
The main parameters include:
- Bussiness Requirement ID(Optional)
- Functional Requirement ID
- Module Name
- Sub-module Name
- Test Scenario ID
Before we discuss the details, it’s important to understand the difference between BRD and FRS.
FRS documents detail out the BRD and split each business requirement into multiple functional requirements. Hence in an RTM, you can opt to highlight both the BRD Number and FRS Number to ensure all BR’s are mapped to FR’s. So the screenshot above showcase the same wherein the BR and FR ID’s are mapped. Along with them is the module name, submodule name and description of the functional requirement and the test scenario ID mapped. Since RTM is the first process post-test Estimation, hence we may not have the test scenario ID’s, therefore the RTM remains incomplete until we get through the test scenario document.
Below is a snapshot of the test scenario document:
|Test Scenario Document|
In the above snapshot, the test scenario document highlights the test scenario ID been used in the RTM. The above document ensures all test scenarios cover all requirements mentioned. Similarly is a test case document which shows the mapping between the test scenario ID and test cases. When we aim to execute the test cases, we can update the results across the RTM also, just to back-track that all the requirements have been executed.
Closing the note, with really worth mentioning quote:
“More than the act of testing, the act of designing tests is one of the best bug preventers known. The thinking that must be done to create a useful test can discover and eliminate bugs before they are coded – indeed, test-design thinking can discover and eliminate bugs at every stage in the creation of software, from conception to specification, to design, coding and the rest.” – Boris Beizer
Author: Sadhvi Singh