How do you ensure test coverage? – One of the most common interview question. After all, client doesn’t want anything skipped in testing & then face the embarrassment of end-user failure in live application. What’s the basis for the Test coverage? Yeah! Requirements – functional, technical & non-functional – every single requirement needs to be tested. What if by mistake the Test team over-looked one of the requirement & didn’t write test cases for it? How will a Test Manager or Client come to know about it? Requirement Traceability Matrix!
What is a Traceability Matrix?
A traceability matrix is a document that co-relates any two baseline documents (section to section) that require a many-to-many relationship to check the completeness of the relationship, i.e. to ensure that everything within both documents is related in any way!
Purpose: Identification of anything that is not linked in two documents, which require further analysis.
Tracing the requirements
Applying the concept of Traceability matrix to requirements, i.e. one of the reference document will always be ‘Requirements Specification’. In simple terms, Requirement Traceability Matrix (commonly known as RTM) is a tool (mostly excel document) that traces requirement throughout the validation process, i.e. Requirement Analysis, Test Design, Test execution & Closure phase.
Simple mapping – Requirement IDs >> Test Scenario IDs >> Test cases IDs >> Defect IDs (including final status)
Purpose: To trace that all requirements are covered in Test Design, Test execution & Closure.
Types of Requirement Traceability Matrix
- Forward traceability (Building the right product): Requirement IDs >> Test Scenario IDs >> Test cases IDs >> Defect IDs.
- Backward or reverse traceability (Building the Product right): Just reverse the order: Defect IDs >> Test cases IDs (all) >> Test Scenario IDs (all) >> Requirement IDs. Purpose: to ensure everything developed has a corresponding requirement, nothing extra!
As you might have guessed, Requirement Traceability Matrix is generally bi-directional – analyzing the loop-holes (not linked) at every step (requirement, test scenarios, test cases and defects)
The purpose of Requirement Traceability Matrix
- Client Confidence: First & foremost is to build the client’s confidence that the product is being developed & tested as per the requirements
- Ensure Test Coverage: All requirements have been covered in Test Design & Execution. The aim of any testing project should be 100% test coverage. Requirement Traceability Matrix helps is uncovering the gaps.
- Track Change Requests: Maintained throughout the lifecycle of the release, changes to the requirements are also recorded and tracked in the Requirement Traceability Matrix.
- Risk Management: ensuring every requirement is testable & eventually tested
- Suggest improvements or missing functionalities
- Project Tasks: Help in the creation of a request for proposal, software requirements specification, various deliverable documents, and project plan tasks.
- Maintainability: Any change in requirements can be tracked to corresponding required change in Test Design
- Sticking to-the-scope: Using reverse traceability, ensure that no extra Testing is done which doesn’t have a corresponding requirement
- Highlight any ambiguous requirements
- Product Quality: The Test coverage & corresponding defect status gives confidence to the client about the product’s quality
- Estimate Change Requests: Using Requirement Traceability Matrix, a Test Manager can easily gauge the impact and the amount of work required if any of the requirement is changed.
- Component’s Quality: Gauging which components in the system ‘were’ most flawed (most defects), another way to highlight the high-risk areas which needs thorough testing.
- Receive the Requirements specification document
- List all the requirements in an excel (Req. ID & Description)
- Add a column specifying if the requirement is testable or not — highlight to business team if something is NOT testable
- Develop Test Scenarios & Test cases
- Update the Requirement Traceability Matrix, i.e. Requirement IDs (all) >> Test scenario IDs (all) >> Test cases IDs (all)
- Requirement Traceability Matrix is Ready!
- Verify the RTM to identify any coverage gaps — any requirement, test scenario or case that is not related to at least one other item
- Execute all the Test cases & raise defects (if any)
- Update the RTM, i.e. Requirement IDs >> Test scenarios IDs >> Test cases IDs >> Defect IDs
- Retest all the defects (once fixed)
- Update the RTM, i.e. Requirement IDs >> Test scenarios IDs >> Test cases IDs >> Defect IDs (including priority, severity & status)
- Finalize & share the RTM including any insights (keeping in mind the purpose as mentioned above)
- Maintain the RTM for any further changes & subsequent assessment
I personally prefer a very simple excel sheet with limited columns (for maintainability).
The Requirement Traceability Matrix can be created and maintained in an automated tool (such as HP QC), in an Excel spreadsheet, or MS Word table.
- Requirement ID
- Requirement description
- Testable (Y / N)
- Module / Sub-Module
- Scenario IDs
- Test Cases ID
- Defect IDs
- First of all – Requirement Traceability Matrix is not what many of the testers think, i.e. useless 🙂 if maintained properly in a simple format, RTM is a valuable tool tracking one of the most important testing aspect ‘The Test Coverage’. The way Test team maintain and update the RTM determines the effectiveness of its use.
- Requirement Traceability Matrix should be created from the requirement phase itself. It becomes cumbersome after Test Design is completed and you already have numerous test scenarios & cases.
- Requirement Traceability Matrix, if prepared during the requirement phase can be referenced in the subsequent Test Design phase to avoid over-looking any requirement.
- Don’t just stop at Requirement – Test Cases mapping. Extrapolate it all the way to defects to reap maximum benefits.
- Maintainability: The most neglected yet important task. The RTM should be updated for every requirement or test design change.
- Act: Don’t just create the RTM & keep it. Act on steps 3, 7, 12 & 13 as mentioned above to yield the benefits
- Requirement Traceability Matrix ensures that requirements & Test cases are broken down to modular level, thus ensuring better understanding & maintainability.
- RTM should be stored in a revision control system to avoid concurrent update
- Some Test Management tools like HP Quality Center (now ALM) provide automatic generation of RTM based on entered requirements, test cases & defects.
- There is no industry standard format for Requirement Traceability Matrix. Feel free to tweak (add or remove columns) the format to include / exclude multiple documents like requirement specifications, technical design, use cases, etc.
- RTM can be extended to include both Manual Test cases as well as Automated Test scripts (automation coverage)
- Requirement Traceability Matrix is used in entire software testing life cycle phases – Risk analysis, Requirement analysis, Test design, Test execution, Defect management and Test closure.
Hope this article helped in getting the basic understanding of Requirement Traceability Matrix. So what are you waiting for? Start using RTM diligently in your Test Project 🙂