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 spreadsheet below:

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.

SPONSORED LINKS