We’re seeing inconsistent test coverage percentages between the quality-mgmt module dashboard and our custom reports, and it’s causing confusion in release readiness discussions.
The quality-mgmt dashboard shows 78% test coverage for our current release, but when I query test case links directly, I calculate only 64% coverage. The 14-point discrepancy is significant enough that stakeholders are questioning our metrics reliability.
I suspect the issue relates to how each calculation handles requirement status filtering or test case linking validation, but I need to understand the exact coverage formula used by Polarion’s quality-mgmt module.
Here’s my custom coverage query that produces the 64% figure:
SELECT
COUNT(DISTINCT r.id) * 100.0 /
(SELECT COUNT(*) FROM requirements WHERE status='approved')
FROM requirements r
JOIN test_links tl ON r.id = tl.requirement_id
WHERE r.status = 'approved';
What am I missing in this calculation compared to Polarion’s built-in quality-mgmt coverage metrics?
Requirement status filtering is definitely part of the puzzle. Beyond approved status, check if Polarion’s calculation excludes certain requirement categories or custom statuses. Our project has informational requirements that shouldn’t require test coverage, and the quality-mgmt module automatically filters these out based on requirement type field. Your SQL query would need similar filtering logic.
I’ve encountered similar discrepancies. Polarion’s quality-mgmt module likely includes draft or in-review requirements in the denominator while your query only counts approved requirements. Also check if the built-in calculation considers indirect test coverage through parent-child requirement relationships. Your direct link query might miss those hierarchical coverage paths.
Have you validated that your test_links join is capturing all link records? Polarion stores traceability links in a complex schema with multiple relationship tables. Direct SQL queries can miss links stored in certain relationship types. The quality-mgmt module uses Polarion’s internal API which has more sophisticated link resolution logic than simple SQL joins.
Check your test link types. Polarion distinguishes between verifies, validates, and tests link types. The quality-mgmt coverage calculation might only count specific link types as valid coverage, while your SQL query includes all link types. We configured our instance to only recognize verifies links for formal coverage metrics, which initially caused confusion until we updated our custom reports to match.