Unlike code coverage, which tells you whether the code was executed, requirements coverage tells you whether the code did what it should. With TPT you can do requirements-based testing to its full extent.
“Testing should always be requirements-based testing”
“Testing should always be requirements-based testing, so you can test whether the system does what you want it to do. In my opinion, requirements coverage is therefore one of the most important factors of software testing.”
CEO of PikeTec, Dr. Jens Lüdemann
In particular, TPT links tests and requirements and shows missing tests. Furthermore, when requirements are modified you can analyse the changes. TPT verifies whether newly imported requirements have changed and shows which test cases are impacted by the requirements that have changed since the last verification. As a result, TPT tells you if any of your test cases need to be adapted due to the changed requirements.
Moreover, requirements are checked dynamically with TPT. Your requirements only need to be linked to your assessment or assesslet and TPT can check specifically which particular requirement is or is not yet fulfilled.
If your test case links to multiple requirements, or one particular requirement is tested by multiple test cases, you will need to keep track of what you are doing. After all, for completeness you should make sure that there is at least one test case for each requirement. Safety norms as ISO 26262 require traceability of tests and requirements. Hence, traceability is a prerequisite for safety systems. You can do so easily in TPT because test cases and requirements are linked to one another and the test specifications can even be imported as they are written down in your ALM tool, like codeBeamer, DOORS or Polarion.
Once the test is completed you will find that the test reports include a requirement view indicating whether your code worked as you wanted it to work.
Feel free to browse through our Glossary of Test Terms in case you are looking for terminological explanations.