Overview
A requirement may be either covered by one or multiple Tests. In fact, the status of a given requirement goes way further than the basic covered/not covered information: it will take into account your test results.
As soon as you start running your Tests, the individual test result may be one of many and be very specific to your use case.
To make your analysis even more complex, you may be using sub-requirements and executing related Tests.
Requirements may be validated directly or indirectly, through the related sub-requirements and associated Test cases.
A sub-requirement can come from the relation Epic → Story or by the use of Sub-Tasks as Requirements and parent linkage to other Requirements
Revising the main definitions of the objects in Scope
Test – a test case template (not related with execution)
Test Run – represents a run of a given Test in the context of some scheduled Test Execution; it’s like an
instance of the Test containing both the specification and the recorded results
“Requirement” – a coverable issue (i.e. an issue that you can cover with Tests); can be a any issue type,
including Story, Epic and other, as long as they’re configurable to be handled as “requirements”. If you
want, you can also configure Bug or similar issue types to be handled as “requirements” (i.e. coverable with
test cases)