The concept of Traceability Matrix is very important from the Testing perspective. It is document which maps requirements with test cases. By preparing Traceability matrix, we can ensure that we have covered all the required functionalities of the application in our test cases.
What is Traceability Matrix from Software Testing perspective?
The concept of Traceability Matrix is very important from the Testing perspective. It is document which maps requirements with test cases. By preparing Traceability matrix, we can ensure that we have covered all the required functionalities of the application in our test cases. Some of the features of the traceability matrix:
It is a method for tracing each requirement from its point of origin, through each development phase and work product, to the delivered product
Can indicate through identifiers where the requirement is originated, specified, created, tested, and delivered Will indicate for each work product the requirement(s) this work product satisfies
Facilitates communications, helping customer relationship management and commitment negotiation
Traceability matrix is the answer of the following basic questions of any Software Project:
How is it possible to ensure, for each phase of the lifecycle, that I have correctly accounted for all the customers needs?
How can I ensure that the final software product will meet the customers needs? For example I have a functionality which checks if I put invalid password in the password field the application throws an error message Invalid password. Now we can only make sure this requirement is captured in the test case by traceability matrix.
Some more challenges we can overcome by Traceability matrix:
Demonstrate to the customer that the requested contents have been developed
Ensure that all requirements are correct and included in the test plan and the test cases
Ensure that developers are not creating features that no one has requested
The system that is built may not have the necessary functionality to meet the customers and users needs and expectations. How to identify the missing parts?
If there are modifications in the design specifications, there is no means of tracking the changes
If there is no mapping of test cases to the requirements, it may result in missing a major defect in the system
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.
If the code component that constitutes the customers high priority requirements is not known, then the areas that need to be worked first may not be known thereby decreasing the chances of shipping a useful product on schedule
A seemingly simple request might involve changes to several parts of the system and if proper Traceability process is not followed, the evaluation of the work that may be needed to satisfy the request may not be correctly evaluated
Step by step process of creating a Traceability Matrix from requirements:
step1: Identify all the testable requirements in granular level from various requirement specification documents. These documents vary from project to project. Typical requirements you need to capture are as follows:Used cases (all the flows are captured)Error MessagesBusiness rulesFunctional rulesSRSFRSSo on
example requirements: login functionality, generate report, update something etc.
step2: In every project you must be creating test-cases to test the functionality as defined by the requirements. In this case you want to extend the traceability to those test-cases. In the example table below the test-cases are identified with a TC_ prefix.Put all those requirements in the top row of a spreadsheet. And use the right hand column of the spreadsheet to jot down all the test cases you have written for that particular requirement. In most of the cases you will have multiple test cases you have written to test one requirement. See the sample spreadsheet below:
Sample traceability matrix
step3: Put cross against each of the test case to each requirement if that particular test case is checking that particular requirement partially or completely. In the above table you can see REQ1 UC1.1 is checked by three test cases. (TC1.1.1, TC1.1.3, TC1.1.5).
Another example of traceability matrix where requirement documents (use case) are mapped back to the test cases.