When I was told that I needed to create a Requirements Traceability Matrix, the first thing that sprang to mind was how I should go about doing so. There is a difference between having theoretical knowledge and really putting it into practice. Let us know what RTM is and how to prepare it in detail
What is Requirements Traceability Matrix (RTM)
RTM is a document used to map and trace business requirements with test cases. It is prepared in tabular format. It captures all the requirements proposed by the clients and for each requirement required test cases are prepared. The main purpose of the Requirements Traceability Matrix is to validate that all requirements are checked through test cases such that no functionality is left while testing. It gives an overall view of business requirements, the number of test cases runs to achieve those requirements and there are no blockers to achieve that requirement.
It ensures a hundred percent test coverage and also helps if there is a change in requirements. Most of the industries use RTM to ensure that No requirements are missed out and have a bug-free release. It validates that for each requirement enough testing is done keeping in mind all test scenarios. End to End testing of an application is achieved. If there is a change in requirement from the client, all the artifacts that are affected can be modified and new test cases can be added.
Who prepares it?
RTM is prepared by the QA team to track requirements by preparing test cases and map defect leakage if any. The QA team creates test cases to ensure that The QA team creates test cases to guarantee that appropriate testing is carried out for each and every need.
It is prepared in the Requirement Analysis phase of STLC when the requirements are listed with various stakeholders and continues till all the requirements are met.
Types of RTM
1. Forward Traceability
It maps business requirements to test cases which in result shows the progress of the project. For every requirement test cases are created. The objective is to ensure that each requirement is implemented in the product and tested thoroughly through test cases. A product requirement can be traced forward to its design, technical requirement, test case run, and defects. If any requirement has no adequate test case written then this ensures that the product may have defect leakage that will impact the quality of the product. If there is a change in requirement a forward traceability matrix can help in changing the associate requirement and all the artifacts that impact the change.
2. Backward Or Reverse Traceability
This type of matrix ensures that the evolving products are on the correct track by mapping test cases to requirements. It ensures that the scope of the projects remains unchanged. If there is any relevant test case that cannot be mapped to requirement then there are two possibilities. The first possibility could be that product requirement is missing as the product element cannot be neglected. The second possibility could be any additional requirement is added which was not originally planned. In both cases, backward traceability helps in identifying if any product requirement is overlooked or if the scope of the requirement is enlarged.
3. Bi-Directional Traceability
This type of matrix gives reference to both Forward and Backward traceability. All the test cases can be traced to requirements and all the requirements can be traced to test cases. This is an ideal type of traceability matrix which forms a connection between both artifacts.
Steps to prepare RTM
1. Takedown all the business requirements from the client. The number of requirements depends on the development environment. Some may have few while some may have many. All the requirements should be considered while listing the business requirements.
2. List all the technical requirements needed to develop the product based on the business needs.
3. QA team creates test cases that cover all of the requirements’ functionality. Test cases are required for both manual and automation testing. There can be multiple test cases required to test a particular scenario. A few test cases used to validate our scenario are mentioned below.
4. In your RTM, add the Test Design parameter. This will indicate whether the UX/UI is ready for the Front-end requirement. When the design is ready, the QA team will mark it as Complete/ Not Complete.
5. Map all the test cases to business requirements or vice versa to create RTM.
6. Test execution will determine if the test is passed or not. If the test passes, the QA team will record the test case as Passed; if the test fails, the test case will be marked as Failed.
7. If a test case fails, a Defect ID is generated and a defect is reported.
Ways of creating RTM
RTM may be created in a variety of methods, though. It depends on the industry how they want it. Some industries use limited parameters like these-
However, I believe that this sort of RTM does not give a complete overview of the project. A thorough mapping includes more than just test cases and requirements. It should also indicate how the RTM helps in bug tracing and its status.
A standard example of an RTM is the one which we created above-
Tools used in RTM
Various tools may be used to make RTM. The most widely used tool for RTM preparation is Excel.
If you feel excel is not your type and find copying and pasting every Requirement, Test Case, and Test Scenarios from documents and mapping them to Excel to be a tedious task, then you can also use products like Jade ALM, HP ALM, Visure Requirements, ReQtest, and others to manage your requirements.
Lets sum up
- It’s a tool that allows you to link test cases to business requirements.
- It makes certain that the product is free of bugs.
- It avoids inconsistencies in documents.
- Clients, stakeholders, managers, developers, and the Quality Assurance team all evaluate it to ensure that no requirements are missed.
- It is used in both manual and automated testing tasks.
Leave a Reply