Software Testing Traceability Matrix

What to Include in a Software Testing Traceability Matrix 

A traceability matrix is an essential tool for any thorough software tester. It should be referenced throughout the entire software development life cycle to bring transparency and completeness to software testing efforts.

Testing Requirements Traceability Matrix

In simple words, a testing requirements traceability matrix is a document that traces and maps user requirements, usually requirement IDs from a requirement specification document, with the test case IDs. The purpose of this document is to make sure that all the requirements are covered in test cases so that nothing is missed.

The traceability matrix document is prepared to show clients that the coverage is complete. It usually includes the following columns: requirement, baseline document reference number, test case/condition and defect/bug ID. Using this document the person can track the Requirement based on the Defect id.

Adding a few more columns to the traceability matrix gives you a good test case coverage checklist.

Types of Traceability Matrices

1. Forward Traceability: Mapping of requirements to test cases. 
2. Backward Traceability: Mapping of test cases to requirements. 
3. Bi-Directional Traceability: A good example of a bi-directional traceability matrix used insoftware testing is the references from test cases to basis documentation and vice versa. 

A forward traceability helps us see which requirements are covered in which test cases? Or whether a requirements is covered at all.
A forward traceability matrix ensures that we are building the right product.
A backward traceability matrix helps us see which test cases are mapped against which requirements.

This will help us in identify if there are test cases that do not trace to any coverage item. If the test case does not trace to a coverage item, it is either not required and should be removed, or else 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.

A backward traceability matrix ensures that we are building the product right.

A bi-directional traceability matrix contains both forward and backward traceability.

Why use traceability matrices?

The traceability matrices are the answer to the following questions when testing any software project:

• How is it feasible to ensure, for each phase of the SDLC, that I have correctly accounted for all the customer’s needs? 
• How can I certify that the final software product meets the customer’s needs? It lets us make sure requirements are captured in test cases. 

Disadvantages of not using traceability matrices include the following:

• More defects in production poor or unknown test coverage. 
• Discovering bugs later in the development cycle resulting in more expensive fixes. 
• Difficulties planning and tracking projects. 
• Misunderstandings between different teams over project dependencies, delays, etc… 

Benefits of using traceability matrices include the following:

• Making it obvious to the client that the software is being developed as required. 
• Ensuring that all requirements are included in the test cases. 
• Ensuring that developers are not creating features that no one has requested. 
• Making it easy to identify missing functionalities. 
• Making it easy to find out which test cases need updating if there are change requests. 

How to create a traceability matrix

1. Open Excel to create Traceability Matrix:

2. Define following columns:

• Use case ID / requirement ID. 
• Use case / requirement description. 

3. One column for each test case.

3. Identify all the testable requirements in granular level from requirement document. Typical requirements you need to capture are as follows:

1. Used cases (all the flows are captured)

2. Error Messages

3. Business rules

4. Functional rules

5. Software requirement specifications

6. Functional requirement specifications

4. Identity all the test scenarios and test flows.

5. Map Requirement IDs to the test cases. Assume (as per below table), Test case “TC 001” is one flow or scenario. SR-1.1 and SR-1.2 are covered .

6. Now from below table you can easily identify which test cases cover which requirements and which test cases need to be updated if there are any change requests.

 

Requirement ID	Requirement Descriptions	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, the 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 columns and make it more effective. Here are some columns you should consider adding:

• ID 
• Assoc ID 
• Technical Assumptions 
• Customer Needs 
• Functional Requirement 
• Status 
• Architectural/Design Document 
• Technical Specification 
• System Component 
• Software Module 
• Test Case Number 
• Tested In
• Implemented In 
• Verification 
• Additional Comments