Do you believe in using the trace matrix as the best indicator of test coverage?
Requires Free Membership to View
When you register, you'll receive targeted emails designed to keep you informed of the most relevant information on Agile development, application security, testing & QA, software requirements, and more.
Hannah Smalltree, Editorial Director
The trace matrix is an established testing tool. The trace matrix proposes that each requirement has one or more tests identified. Allegedly if you have one or more test cases tied to each requirement, and each test case is executed, you have proof that the application has been tested.
My challenge to the trace matrix is, what about requirements that are implied or assumed? Or what about testing ideas that don't map back to a requirement? Many great testing ideas come to mind while we're testing. If the trace matrix prevents test ideas from being executed because there is no stated requirement to trace back to, then I would challenge the practice of the trace matrix. In fact, by focusing on filling out a trace matrix, testing ideas can be stymied. This is the core reason why I don't believe a trace matrix is necessarily the best indication that a system is well tested.
However, if you're working in a regulated environment where you are governed that the trace matrix shall be used to demonstrate complete test coverage, then the trace matrix must be updated. As long as the requirements and trace matrix can be updated all the way until the end of a project, then a trace matrix can be the indicator of test coverage. If the requirements are frozen and the trace matrix is not updated up until the project is complete, then the trace matrix is not necessarily the best indicator of test coverage.
My challenge to the trace matrix is, what about requirements that are implied or assumed? Or what about testing ideas that don't map back to a requirement? Many great testing ideas come to mind while we're testing. If the trace matrix prevents test ideas from being executed because there is no stated requirement to trace back to, then I would challenge the practice of the trace matrix. In fact, by focusing on filling out a trace matrix, testing ideas can be stymied. This is the core reason why I don't believe a trace matrix is necessarily the best indication that a system is well tested.
However, if you're working in a regulated environment where you are governed that the trace matrix shall be used to demonstrate complete test coverage, then the trace matrix must be updated. As long as the requirements and trace matrix can be updated all the way until the end of a project, then a trace matrix can be the indicator of test coverage. If the requirements are frozen and the trace matrix is not updated up until the project is complete, then the trace matrix is not necessarily the best indicator of test coverage.
This was first published in February 2007