Here's a bit of a problem I'm encountering in 9.2:
On the requirements module, we cannot pull any historical reports using the DCS (direct cover status), as DCS = Last execution status, and not what actually happened for that particular cycle. In a practical example:
Requirement 1 (tested on Cycle 01):
Test 001 Passed
Test 002 Passed
Test 003 Passed
Requirement 2 (tested on Cycle 02):
Test 001 Failed
Test 002 No run
Test 003 No run
If I pull a summary report/graph filtered on Cycle 2, the direct cover status for Tests 002 and 003 will automatically be set to Passed, as inherited from Cycle 01, which is wrong, as they should be No run, which makes reporting inaccurate.
This is problem no. 1.
Problem no. 2 consists of the fact that once we start off on a new cycle, reporting accurately (coverage analysis) can only be done in the Coverage analysis view in the requirements module, once you select your filter to whichever release/cycle the requirements are assigned to. The direct cover status will show the last execution status (based on the time-stamp, as per the example above), while the coverage will be the only accurate indicator whether that particular requirement/children was/were failed/no run/ passed etc. for that particular cycle. The only issue is that we cannot pull any reports from this particular view. Also, if I try to set filters based on the DCS, I will loop back to problem #1.
The issue that we have is that we are in the position of executing tests against the same requirements, over and over again, over different cycles, and its impossible for us to retain accurate historical data on the requirements, nor report accurately on the current requirements coverage on the cycle (not talking about the progress tab in the release management module Im only referring to the plain and simple requirements module only), as we can only use the DCS for filtering, and not able to pull reports based on coverage analysis.
Additional notes: The execution reporting from the lab poses no issues whatsoever; copy pasting requirements is also not a valid solution (we have a few thousands).