What is Traceability Matrix from Software Testing perspective?

Posted on May 28 2008 - 8:00pm by Raj

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 customer’s needs?
  • How can I ensure that the final software product will meet the customer’s 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 customer’s 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 Messages
Business rules
Functional rules
SRS
FRS
So 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

Requirement Identifiers Reqs Tested REQ1
UC
1.1
REQ1
UC
1.2
REQ1
UC
1.3
REQ1
UC
2.1
REQ1
UC
2.2
REQ1
UC
2.3.1
REQ1
UC
2.3.2
REQ1
UC
2.3.3
REQ1
UC
2.4
REQ1
UC
3.1
REQ1
UC
3.2
REQ1
TECH
1.1
REQ1
TECH
1.2
REQ1
TECH
1.3
Test Cases 321 3 2 3 1 1 1 1 1 1 2 3 1 1 1
Tested Implicitly 77













TC1.1.1 1 x












TC1.1.2 2
x x










TC1.1.3 2 x









x

TC1.1.4 1

x










TC1.1.5 2 x










x
TC1.1.6 1
x











TC1.1.7 1

x










TC1.2.1 2


x
x







TC1.2.2 2



x
x






TC1.2.3 2






x x




TC1.3.1 1








x



TC1.3.2 1








x



TC1.3.3 1









x


TC1.3.4 1









x


TC1.3.5 1









x


etc…














TC5.6.2 1












x

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.

 

Change management through traceability matrix:
It will be lot easier for you to track changes if you have a good traceability matrix in place. For example REQ1 UC1.1 we know upfront from the traceability matrix that what test cases I need to modify to incorporate those changes. In the above case we need to modify TC1.1.1, TC1.1.3 and TC1.1.5 only. 

About the Author

Leave A Response