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.
Regression testing is a test approach which helps testers make sure there are no new bugs due to code changes or because a new functionality was added to an existing one. Using a requirement traceability matrix helps achieve the results with better efficiency.
Let’s discuss more in detail in the article.
What is a Requirement Traceability Matrix?
Every QA team needs to understand a client’s requirements and ensure to launch a defect-free application into the market. 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 to test cases. With regression testing, each of the test cases has to be tested separately, 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)’
RTM 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.
Creating a Traceability Matrix For Requirements
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 an RTM 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 whereas BR stands for “Business Requirements”, FR stands for “Functional/Technical Requirements”.
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.
Types of RTM
Forward Traceability
Forward matrix is used to ensure 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 ensures that every single business requirement is correctly integrated into the product and every requirement is tested thoroughly.
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 which 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, updated 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 is broken after making code changes.
When to Perform Regression Testing and how it relates to RTM?
- When new functionality is added 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.
- 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.
- At the time of performance fix – All the test cases from RTM should be executed. If time is limited, high priority test cases should be selected and executed.
- When there is environmental change – All the test cases from RTM should be executed. If time is limited, high priority test cases should be selected and executed.
- At the time of bug fix – All the test cases related to the area of bug fix/functionality impacted should be tested.
Read more about regression testing best practices here.
Types of Regression Testing
When code changes have been introduced 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.
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 test cases for the related areas can be selected from the RTM easily to perform selective regression testing. The number of selected test cases can be further reduced by filtering on the basis of priority. The high priority test cases are selected for execution here.
Read more about Prioritizing regression test cases here.
When major code changes are introduced across multiple units/functions, we need to plan for complete regression testing. All the test cases from the RTM are executed in this scenario.
To automate regression testing, read here.
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 whenever new functionalities / code changes / test cases / test scenarios, are added to the test plan.
Go!
