What is Traceability Matrix :
A traceability matrix is a document, usually in the form of a table, that correlates any two baselined documents that require a many-to-many relationship to determine the completeness of the relationship. It is often used with high-level requirements (these often consist of marketing requirements) and detailed requirements of the product to the matching parts of high-level design, detailed design, test plan, and test cases.
A requirements traceability matrix may be used to check to see if the current project requirements are being met, and to help in the creation of a request for proposal, software requirements specification, various deliverable documents, and project plan tasks.
What is the need for Requirements Traceability Matrix in Software Testing?
Automation requirement in an organization initiates it to go for a custom built Software. The client who had ordered for the product specifies his requirements to the development Team and the process of Software Development gets started.
In addition to the requirements specified by the client, the development team may also propose various value added suggestions that could be added on to the software. But maintaining a track of all the requirements specified in the requirement document and checking whether all the requirements have been met by the end product is a cumbersome and a laborious process.
The remedy for this problem is the Requirements Traceability Matrix.
What is Traceability Matrix from Software Testing perspective?
- A requirements traceability matrix is a document that traces and maps user requirements [requirement Ids from requirement specification document] with the test case ids. Purpose is to make sure that all the requirements are covered in test cases so that while testing no functionality can be missed.
- This document is prepared to make the clients satisfy that the coverage done is complete as end to end, this document consists of Requirement/Base line doc Ref No., Test case/Condition, and Defects/Bug id. Using this document the person can track the Requirement based on the Defect id
Types of Traceability Matrix:
- Forward Traceability – Mapping of Requirements to Test cases
- Backward Traceability – Mapping of Test Cases to Requirements
- Bi-Directional Traceability - A Good Traceability matrix is the References from test cases to basis documentation and vice versa.
Why Bi-Directional Traceability is required?
- Bi-Directional Traceability contains both Forward & Backward Traceability. Through Backward Traceability Matrix, we can see that test cases are mapped with which requirements.
- This will help us in identifying if there are test cases that do not trace to any coverage item— in which case the test case is not required and should be removed (or maybe a specification like a requirement or two should be added!). This “backward” Traceability is also very helpful if you want to identify that a particular test case is covering how many requirements?
- Through Forward Traceability – we can check that requirements are covered in which test cases? Whether is the requirements are coved in the test cases or not?
- Forward Traceability Matrix ensures – We are building the Right Product. and Backward Traceability Matrix ensures – We the Building the Product Right.
Disadvantages of not using Traceability Matrix [some possible (seen) impact] :
No traceability or Incomplete Traceability Results into:
- Poor or unknown test coverage, more defects found in production
- It will lead to miss some bugs in earlier test cycles which may arise in later test cycles. Then a lot of discussions arguments with other teams and managers before release.
- Difficult project planning and tracking, misunderstandings between different teams over project dependencies, delays, etc
Benefits of using Traceability Matrix :
- Make obvious to the client that the software is being developed as per the requirements.
- To make sure that all requirements included in the test cases
- To make sure that developers are not creating features that no one has requested
- Easy to identify the missing functionalities.
- If there is a change request for a requirement, then we can easily find out which test cases need to update.
- The completed system may have “Extra” functionality that may have not been specified in the design specification, resulting in wastage of manpower, time and effort.
Steps to create Traceability Martix:
- Make use of excel to create Traceability Matrix:
- Define following columns:
- Base Specification/Requirement ID (If any)
- Requirement ID
- Requirement description
- TC 001
- TC 002
- TC 003.. So on.
- Identify all the testable requirements in granular level from requirement document. Typical requirements you need to capture are as follows:
- Used cases (all the flows are captured)
- Error Messages
- Business rules
- Functional rules
- SRS
- FRS and So on…
- Identity all the test scenarios and test flows.
- Map Requirement IDs to the test cases. Assume (as per below table), Test case “TC 001” is your one flow/scenario. Now in this scenario, Requirements SR-1.1 and SR-1.2 are covered. So mark “x” for these requirements.
- Now from below table you can conclude –
- Requirement SR-1.1 is covered in TC 001
- Requirement SR-1.2 is covered in TC 001
- Requirement SR-1.5 is covered in TC 001, TC 003 [Now it is easy to identify, which test cases need to be updated if there is any change request].
- TC 001 Covers SR-1.1, SR, 1.2 [we can easily identify that test cases covers which requirements].
- TC 002 covers SR-1.3.. So on..
| Requirement ID |
Requirement description |
TC 001 |
TC 002 |
TC 003 |
| SR-1.1 |
User should be able to do this |
x |
|
|
| SR-1.2 |
User should be able to do that |
x |
|
|
| SR-1.3 |
On clicking this, following message should appear |
|
x |
|
| SR-1.4 |
|
|
x |
|
| SR-1.5 |
|
x |
|
x |
| SR-1.6 |
|
|
|
x |
| SR-1.7 |
|
|
x |
|
This is a very basic traceability matrix format. You can add more following columns and make it more effective:
ID, Assoc ID, Technical Assumption(s) and/or Customer Need(s), Functional Requirement, Status, Architectural/Design Document, Technical Specification, System Component(s), Software Module(s), Test Case Number, Tested In, Implemented In, Verification, Additional Comments.
The RTM Template shows the Mapping between the actual Requirement and User Requirement/System Requirement.
Any changes that happens after the system has been built we can trace the impact of the change on the Application through RTM Matrix. This is also the mapping between actual Requirement and Design Specification. This helps us in tracing the changes that may happen with respect to the Design Document during the Development process of the application. Here we will give specific Document unique ID, which is associated with that particular requirement to easily trace that particular document.
In any case, if you want to change the Requirement in future then you can use the RTM to make the respective changes and you can easily judge how many associated test scripts will be changing.
Click to read about other Test Documents
