Requirement Traceability Matrix | How RTM Relates to Regression Testing?

Adding new functionalities into an existing application or making new code changes due to bug fixes can possibly result in new issues in a software application; QA teams need to follow different procedures to ensure no new issues have been introduced due to code changes, so here comes the Requirement Traceability Matrix in Testing and Regression testing.

Regression testing is a test approach that helps testers make sure there are no new bugs due to code changes or because of the introduction of new functionality to the existing ones. Using a requirement traceability matrix helps achieve the results with better efficiency.

Let’s discuss this in more detail in the article.

Every QA team needs to understand a client’s requirements and ensure to launch of a defect-free application into the market. And clearly, to achieve this goal, the QA team should be aware of the end-to-end requirements & should draft the test plan covering all the functionalities/requirements. QA team needs to split the software requirements provided by the client into multiple scenarios and then test cases. With regression testing, each of the test cases undergoes separate testing, covering all the dependent requirements as well.

A question arises here on how the QA team ensures that all possible scenarios/cases are covered in the test plan. How do we ensure that all the requirements are covered in the testing cycle? A simple & easy solution is to map the requirement with related test scenarios and respective test cases; this map can be called a ‘Requirement Traceability Matrix(RTM)’

What is Requirement Traceability Matrix (RTM)?

Requirement Traceability Matrix is typically a spreadsheet that contains the business requirements with its complete test scenarios, test cases. RTM is a single document constructed with the purpose of covering all test cases at one place and mapping them to respective requirements/functionalities. Using RTM, one can rest assured that when a new functionality is tested, all dependent functionalities/features of the application are also tested and verified.

Why is Requirement Traceability Matrix (RTM) Important?

Behind every bug-free software is a QA who followed the requirement criteria by word!

The primary goal of RTM is to offer visibility into all the phases of software development, including design, creation, testing, delivery, and deployment. The higher your QAs have the ability to understand the requirement thoroughly and create positive and negative test cases, the better the chances to produce quality software. But how to ensure that every test case, positive and negative, is present while validating the final product? And what if you miss any of the requirements before market release? You turn to Requirement Traceability Matrix.

It helps to:

• Simplify the defect classification for bigger projects
• Improve test case management by mapping a test case to its source requirement and identifying the defects
• Empower you to move through different project management tools to seamlessly trace the progress from the requirement to the defects
• Make sure to maintain a detailed and necessary documentation.

Parameters in Requirement Traceability Matrix

In almost every case, an RTM is created in an excel sheet that contains all the necessary information about understanding the software requirements. Generally, it covers a few parameters that QAs and stakeholders want to monitor:

• Requirement ID and Priority
• Test Case Description corresponding to the requirement ID
• Test Case ID and Status (Pass/Fail)

Above is a basic example of what an RTM looks like. But there are many other parameters you can add to and track using RTM, such as test execution environment, defects found, defect status and ID, and requirement coverage status.

How to create Requirement Traceability Matrix?

For creating a Requirement Traceability Matrix, QA team needs to collect the necessary artifacts like Business Requirement, Test cases, Test Results, Test Status & Defect details, etc. Mostly, spreadsheet is used to create an RTM where we can easily align all the above-mentioned artifacts & inter-relate to each other. Below is a requirement traceability matrix example, which is derived from sample business & functional requirements.

Business Requirement:

Below are some of the sample business requirements, which the QA team received from a client.

Business Requirement #90: Login process to a mail application

Business Requirement #91: Sending a mail

Functional Requirement:

Below mentioned functional requirements have been derived from the above business requirements.

Functional Requirement #90.1: Directly login with existing credentials

Functional Requirement #90.1: Creating new user & login with new credentials

Functional Requirement #91.1: Creating a new email & sending it.

Functional Requirement #91.2: Sending an email from Draft items

Functional Requirement #91.3: Replying to an inbox email

A sample RTM is given below .

Now we can see how the business & functional requirements are mapped to test cases. This helps the QA teams to ensure all the requirements are covered with all possible test cases & nothing is missed out.

If any code changes / new functionalities are implemented due to requirement changes or bug fixes, RTM helps QA team to identify the possible impact areas/test cases, where code changes have been implemented. 

What are the 3 Types of Requirement Traceability Matrix?

Not every RTM document will work for you. And not every RTM is necessary for every software development and testing process. Here are the 3 different types of Requirement traceability that you should know about:

Forward Traceability

A forward matrix ensures that the project is progressing in the right direction. In simple words, we can say, “Forward Traceability maps the requirements to the test cases”. It helps to make sure that every single business requirement is correctly integrated into the product and that every requirement is thoroughly tested.

Backward Traceability

The backward or reverse traceability matrix is “mapping the test cases with its requirements”. This type of matrix helps us in ensuring that we are not expanding the goals of the testing by covering extra features or functionalities in test coverage that were not a part of the initial requirements.

Bi-Directional Traceability

This is the mix of both Forward and Backward traceability matrices.

Advantages of RTM

1. Confirms 100% test coverage.

2. Highlights any missing requirement and document inconsistency.

3. Gives complete “issues filed” and “test case execution” status.

4. Helps analyze and estimate the retest if any changes occur in the requirement.

What is Regression Testing?

Regression testing is a type of testing which is performed to ensure that a small code change which is made in one part of the system is not breaking the existing functionality elsewhere in the system. In simple words, we do regression testing by re-executing the test cases in the modified application to ensure whether the modified code is not breaking anything which was working earlier.

RTM helps a tester decide the high impact areas which might be affected due to code changes/new functionality additions while planning for regression testing.

During regression testing, new elements of the code changes are first tested. Anytime an application is modified with new code changes, the QA team should do regression testing. Regression testing ensures that no functionality breaks after making code changes.

When to Perform Regression Testing and How it Relates to RTM?

1. When developers add new functionality to existing functionality – In the RTM, all the test cases related to that functionality should be updated and then executed. Also, all test cases related to dependent functionalities should be executed.
2. When there is a change in requirements (CR) – In the RTM, all the test cases related to that requirement should be executed; also, all test cases for dependent requirements should be executed.
3. At the time of the performance fix – All the test cases from RTM must undergo execution. If there is less time, high-priority test cases must receive extra attention ahead of other test cases for execution.
4. When there is environmental change – All the test cases from RTM should be executed. If there is less time, high-priority test cases must receive extra attention ahead of other test cases for execution.
5. At the time of the bug fix – All the test cases related to the area of bug fix/functionality should undergo testing.

Read more about regression testing best practices here – Defining Regression Checks – Why, When & its Best Practices and here about our automated regression testing tool .

Types of Regression Testing

What you add or write in the RT of your project is your choice. But there are still some elements that you would need to take care of as per Regression testing type when it comes to working with RTM documents.

a) Unit Regression Testing

When developers introduce the code changes in a small area, then the testing/dev team executes all previously passed specific test cases related to that unit before merging it to master code. Because these test cases are automated, all of the test cases can be automated, or an RTM document could be used to figure out what test cases should be executed if the time taken for execution is more.

b) Selective Regression Testing

When there is a change in program-dependent areas like functions/variables/boundary values, then the related test cases would be rerun. The testing team needs to analyze & select the possible affected areas due to code changes. The related areas’ test cases can be easily selected from the RTM to perform selective regression testing. You can further reduce the number of selected test cases by filtering on the basis of priority. The high-priority test cases go first for execution here.

Read more about Prioritizing regression test cases.

c) Complete Regression Testing

When major code changes happen across multiple units/functions, we need to plan for complete regression testing. All the test cases from the RTM are run in this scenario.

Thus, in addition to identifying affected areas due to code changes, RTM can help decide the number of tests required, what types of tests are required, and whether these tests can be automated or have to be done manually.

It’s much easier to track changes if we have a good traceability matrix at the time of regression testing because it also improves the quality of a QA process.

And it is mandatory to update the Requirements Traceability Matrix document with new new functionalities/code changes/test cases/test scenarios in the test plan.

Frequently Asked Questions (FAQs)

What is the main purpose of RTM?

The main purpose of RTM is to document the details of the technical requirements associated with a test scenario and its status. It helps the testing team understand and follow the testing level of the product.

Is RTM required in Agile?

RTM is a useful option to implement if you follow the Agile methodology. It assists teams in keeping track of requirements for every sprint, along with the evolving changes that add to the requirements with time.

What is the RTM format?

Usually, RTM format is in an excel sheet in the form of a table with necessary information/parameters to understand the status of the test scenarios and cases.

Suggested Reading

Automated Regression Testing

Functional Regression Testing

Selenium Regression Testing

Advantages of Regression Testing

Regression Testing Frameworks

Regression Testing

Test Cases for regression testing

9 Tips for Selecting Test Cases for Regression Testing

Entry and Exit Criteria For Regression Testing

Full Regression Testing in Agile

Types of Regression Testing

Visual Regression Testing

What are the risks in regression testing ?

What do we do in Regression Testing? 

What is regression testing ? – explained with an example

Regression Testing VS Retesting

Regression Testing and Best Practices