Traceability matrix in software testing
A traceability matrix can be described as a document that co-relates any two or more documents require a numerous relationship for maximum coverage. It means to check the fulfillers of any testing project. It is utilized to track the necessities and also to check the meets of all prerequisites.
RTM ( Requirement Traceability Matrix) establishes a way to check the total requirement specified by the client or by the team. It simply means that it is such sort of document that can maps and traces all the coverage aspect with test cases.
Why it is needed?
Organizations consistently focuses on 100% test coverage. They always try to cover almost all aspects and features of the software product under the test. The full-coverage in test cases ensures identification of maximum defects and thereby enhancing the quality of the product. The main intent behind TM is to guarantee 100% test coverage. Thus, it helps in validating the fulfilment of all requirements under the test.
Apart from business and user requirements, the developer may also modifies (add or delete) some of the original requirements, based on the client-demand. This makes the task of covering all functionalities and requirements in the test cases, more tedious and troublesome. Traceability matrix is the best solution that provides ease in bringing all requirements, whether original or modified, static or dynamic, and test cases in one single document and grouping them, accordingly, to ensure that no requirement is left out.
Various types of Traceability Matrix:
- Forward traceability: To verify the progress on the desired product and in the right direction, this matrix has been utilized. In short, this matrix do mapping on requirements to test cases. It also ensures that each specified need is applicable and tested.
- Reverse traceability: This can be utilized to make sure that current product ruins in the right direction. Unless expanding the project by putting additionally design elements, any code, or any other work that are mentioned in the requirements. You can determine Reverse traceability as mapping test cases to requirements.
- Bi-directional traceability (forward reverse): This matrix investigates the changes of requirements that may get affected by defects in a product and vice versa.
Work Flow of Traceability Matrix:
Traceability Matrix is one of the initial steps of a project as the project's scope, and the accepted result or deliverables would produce on the basis of Matrix. Let's make it easy to understand by the following steps
- Proposal request
The approved template of the TM consists of following specification.
- Requirement ID
- Requirement Type
- Requirement Description
- Trace to Design Specification
- Unit Test Cases
- Integration Test Cases
- System Test Cases
- User Acceptance Test Cases
- Trace to Test Script
Benefits of Traceability Matrix:
- Ensures that all the prerequisites are present in the test case.
- Also ensures that developers are not developing the un-required feature.
- Any lost or missed functionality can be identified quickly.
- Test cases can be updated quickly whenever any change is required.
Disadvantages of not using traceability matrix:
- Poor or many other defects can affect the production.
- Various difficulties came across during planning and tracking.
- Delays in finding bugs may cause expensive fixes in the development cycle.
- Guarantees 100% test-coverage.
- It should be prepared as early as possible, with the start of the project.
- Provides ease to find out the unseen or missing functionality or requirement.
- Ensures each and every requirement is fulfilled by one or more test cases.
- Flexible to update, on the basis of changing requirements.
- It provides a good base for preparing the test strategy and cases.
Traceability Matrix is testing for ensuring maximum test coverage. This testing is important QC tool that is over emphasized or over simplified. Tester's intelligence can make the Traceability Matrix more effective by updating. Traceability Matrix is to determine the requirements met, often detailed requirements of a product, test plan, test cases, detailed design, commonly in the form of a table.