In this course we will have a brief look into visualising the results of test execution , namely , having a step by step walk into the requirement coverage.
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
execution
result may be one of many and be very specific to your use case.
Let’s start by detailing the different possible values for the requirement, Test and Test step statuses. In the end, we’ll see how they’ll impact on the calculation of the coverage status of a requirement in some specific version.
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.
Image Added
Info
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
UI Step
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)
