qTest Reporting: Test Metrics, Coverage Reports, and Executive Dashboards

qTest reporting converts raw test execution data into information that QA leads, project managers, and executives can act on. The built-in reports cover requirements traceability, defect trends, execution progress, and test coverage — all without exporting to Excel. This guide covers the reports that matter most and how to set them up.

The Reporting Model

qTest organizes reporting around three data sets:

1. Requirements: what the system should do (imported from Jira or entered manually)
2. Test Cases: how requirements are verified
3. Test Runs: actual execution events with pass/fail outcomes

Reports join these data sets: coverage reports show which requirements have linked test cases and which test cases have been executed. Defect reports show what broke and in which test cycle. Execution reports show who ran what and when.

All reports pull live data — there's no need to export and refresh. Filter by project, release, cycle, date range, or tester.

Requirements Coverage Report

What it shows: For each requirement (Jira story or manually entered), how many test cases cover it and what's the current pass/fail status.

Access: Reports → Requirements Coverage

Key metrics:

• Requirements with 0 linked test cases (no test coverage)
• Requirements with test cases that have never been executed
• Requirements where all linked tests have passed
• Requirements where one or more tests have failed

Practical use: Before a release, run this report filtered to the release's requirements. Any requirement showing "0 test cases" or "0 executions" is a coverage gap that needs to be addressed before sign-off.

Export: CSV, PDF, or embed in a qTest dashboard widget.

Execution Progress Report

What it shows: Real-time status of a test cycle — how many test runs are in each status (Passed, Failed, Blocked, Not Run, Skipped).

Access: Reports → Test Execution → Execution Progress

Burn-down view: Shows how the Not Run count decreases over time. A flat line means testing stalled. A steep drop at the end suggests the team rushed execution before the deadline.

By tester: Break down execution progress by team member — who has executed the most runs, who has the most blocked tests, who is behind on their assignment.

Practical use: Daily standup view. Open this report before the meeting to see exactly where execution stands without asking each tester for an update.

Defect Analytics

What it shows: Defects found in testing — count by severity, status, reporter, assignee, and trend over time.

Access: Reports → Defects → Defect Summary

Key views:

Defect density by feature: Which feature area has the most defects? If the authentication module has 30 defects and search has 5, that's signal about where to focus testing and development attention.

Defect status distribution: How many open defects are Critical vs. Major vs. Minor? What percentage are fixed vs. still open? This is the metric that matters for release readiness decisions.

Defect trend over time: Is the team finding more bugs each week or fewer? A decreasing new-defect rate late in a release cycle is a signal that the code is stabilizing. A spike suggests a risky change was merged.

Time to fix: Average days from defect creation to resolution, broken down by severity. Chronic long fix times for critical defects indicate a process problem.

Test Case Quality Metrics

Execution frequency: Which test cases are run most often? Frequently executed tests that frequently fail are candidates for investigation — either the feature is unstable or the test is flaky.

Test age: When was each test case last updated? Old test cases that were written years ago and never revised may test behavior that no longer matches the application.

Execution history: For any test case, view every execution across all cycles — when it ran, who ran it, and the result. Useful for investigating a test that started failing after a specific build.

Executive Dashboard

The qTest dashboard is configurable: drag and drop widgets to build a view appropriate for different audiences.

QA lead dashboard — operational view:

• Execution progress widget (pie chart of current cycle status)
• Defect count by severity (open defects only)
• Blocked test runs (needs immediate attention)
• Test assignment summary (who has what)

Engineering manager dashboard — coverage and quality:

• Requirements coverage percentage
• Defect trend (last 30 days)
• Pass rate by feature area
• Automated vs. manual execution split

Executive dashboard — release readiness:

• Overall pass rate for the current release
• Critical/high defects open
• Requirements coverage percentage
• Go/no-go indicator based on defined thresholds

Setting up the executive dashboard:

1. Dashboard → New Dashboard → name it
2. Add Widget → choose from the widget library
3. Configure each widget: which project, which cycle, date range, grouping
4. Share the dashboard URL with stakeholders — it updates live

Traceability Matrix

What it shows: A grid with requirements on one axis and test cases on the other. Each cell shows the execution status of that test-case-to-requirement link.

Access: Reports → Traceability Matrix

This is the most comprehensive view of test coverage in a single screen. At a glance:

• Empty cells = no test coverage for that requirement
• Red cells = test coverage exists but the test is failing
• Green cells = covered and passing

Filter to a specific release or sprint to scope the view. Export to Excel for stakeholder presentations or audit documentation.

Scheduled Reports

For recurring reporting needs (weekly status emails, sprint summaries), configure scheduled reports:

1. Reports → Scheduled Reports → Create
2. Choose the report type
3. Set the schedule: daily, weekly, at sprint end
4. Configure recipients (email addresses)
5. Set the format: PDF or CSV attachment

Common scheduled reports:

• Weekly defect summary (every Monday morning) to the engineering manager
• Sprint close requirements coverage report (triggered manually at sprint end)
• Daily execution progress during release testing periods

qTest Insights (Advanced Analytics)

qTest Insights is a separate analytics module (included in some license tiers) that provides:

• Historical trend analysis: compare pass rates across releases, not just within one cycle
• Flaky test detection: tests that alternate between passing and failing without code changes
• Test efficiency metrics: time spent per test run, tester productivity
• Predictive coverage: AI-based suggestions for which tests to run based on code changes

Insights connects to your qTest data warehouse and uses a separate reporting interface. If your team needs multi-release trend analysis or automated flakiness detection, it's worth evaluating.

Integration with External Reporting

qTest data is available via API for integration with external BI tools:

REST API: Every metric available in the qTest UI is accessible via API. Pull test execution data, defect counts, and coverage percentages into Tableau, Power BI, or any custom dashboard.

Webhooks: Configure webhooks to fire when test runs complete or defects are created — pipe this data to a data warehouse or Slack channel in real time.

JUnit XML: Test results export to JUnit XML, which is consumable by Jenkins, Azure DevOps, and any CI tool that parses JUnit format for trend tracking.

Reports That Actually Drive Decisions

The reports QA teams use most heavily in practice:

1. Requirements Coverage before release — confirms every story has test coverage and all tests pass
2. Open critical/high defects — the release-blocking view that engineering and product check before shipping
3. Execution progress during active testing — daily view, replaces manual status updates
4. Defect density by feature — tells development where to focus code review and testing investment

The rest are available when you need them, but these four cover the core of what test management reporting needs to deliver.

Common Report Mistakes

Reporting execution count instead of coverage: A cycle with 500 test runs that all pass looks great. But if those 500 tests only cover 40% of requirements, you don't have coverage — you have thoroughness in a narrow area. Always pair execution metrics with requirements coverage.

Not filtering by build: Execution results from an old build version pollute the current release view. Filter reports to the specific build or cycle, not the entire project history.

Ignoring Blocked status: Blocked tests are not passing, and they're not failing — they're invisible to pass rate calculations. A 95% pass rate looks fine until you realize 20% of tests are Blocked and excluded from the denominator.