> For the complete documentation index, see [llms.txt](https://learning.contextqa.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://learning.contextqa.com/enterprise-application-testing/reporting.md).
# Reporting Overview
An overview of the dashboards, reports, and analytics that ContextQA provides to help QA teams, developers, and engineering managers understand test health at every level.
> **Documentation owner:** [Deep Barot](https://contextqa.com/academy/) · **Last updated:** October 22, 2026
{% hint style="info" %}
**Who is this for?** QA managers, engineering managers, and VPs who need clear visibility into test health, pass rates, flakiness trends, and release readiness — without manual spreadsheet tracking.
{% endhint %}
ContextQA centralizes all test quality data into a set of dashboards and reports so every stakeholder has the right view of what is happening across the test suite. From a real-time execution feed to AI-generated quality observations, the reporting layer surfaces the information you need without requiring manual spreadsheet tracking or log diving.
## Quick answer
ContextQA reporting combines a workspace overview, execution health, test results, coverage signals, failure analysis, and risk views. Testers use result evidence to debug a run; QA managers use activity, drafts, trends, and consistently failing tests to manage suite health; engineering leaders use scoped readiness and risk signals to support release decisions. A dashboard is decision support, not a replacement for reviewing the underlying execution or pull-request evidence.
## Key takeaways
* ContextQA reporting combines a workspace overview, execution health, test results, coverage signals, failure analysis, and risk views.
* The Dashboard is the workspace starting point.
* All reporting surfaces are reachable from the left sidebar: Dashboard — top-level platform summary Execution Dashboard — run history and per-run detail Reports — detailed pass/fail reports with screenshots, video, and step logs ---
***
## Who uses reporting in ContextQA?
| Role | Primary concern | Recommended starting point |
| ----------------------------------- | -------------------------------------------------------------------------------------- | --------------------------------------------------------------- |
| **QA engineer** | Did my last run pass? What failed and why? | Execution Dashboard → test run detail |
| **QA manager** | What needs review, and what is our pass rate, flakiness, and coverage trend? | Dashboard → Review drafts or Execution Dashboard → Coverage tab |
| **Developer** | Which specific step failed, what did the UI look like, and what is the fix suggestion? | Test result detail page → Failure Analysis |
| **Engineering manager / executive** | Are we shipping with confidence? How is quality trending across sprints? | Dashboard → Insight tab → RBT tab |
***
## What is available
### Workspace overview dashboard
The **Dashboard** is the workspace starting point. Depending on workspace availability, it can show:
* summary cards for test cases and recorded bugs;
* estimated time and cost saved;
* regressions caught and pull requests checked;
* connected integrations;
* module or coverage status;
* recent test, requirement, and pull-request activity;
* a **Finish setup** checklist;
* a workspace standing or trial banner; and
* a live activity terminal while setup or analysis is running.
A **Review drafts** card appears only when PR Impact has draft recommendations waiting for review. Its count is a work queue, not a release verdict. Open the drafts and inspect the associated pull request, recommendation, confidence, and evidence before taking action.
```mermaid
flowchart LR
A[Workspace dashboard] --> B[Finish setup]
A --> C[Recent activity]
A --> D[Module and coverage status]
A --> E{PR Impact drafts exist?}
E -- Yes --> F[Review drafts card and count]
E -- No --> G[Card remains hidden]
F --> H[Open evidence-backed recommendation]
C --> I[Open underlying test, requirement, or PR]
```
Treat estimated savings and coverage values as directional unless your organization has validated the inputs and definition. Use the linked test, requirement, pull request, execution, or usage record for an auditable decision.
### Execution analytics dashboard
The execution analytics view summarizes activity and run health over a selected period. Use the date range and available plan filters to scope the view to a sprint or release window before comparing trends.
### Execution Dashboard
The **Execution Dashboard** gives a live and historical view of every test run. Key panels include:
* Run-level summary: total executed, passed, failed, aborted, and success rate versus previous period
* Execution trend graph: daily pass/fail/aborted counts over time
* Test distribution widget: environment breakdown (web, mobile, API)
* Consistently failing test cases: a ranked list with root cause and failure count per case
### Coverage Dashboard
The **Coverage** tab inside the Execution Dashboard shows which application modules have test coverage and which do not. Each module card lists positive, negative, and ad-hoc scenarios and flags unresolved issues with a red badge.
### Insight and Risk-Based Testing
The **Insight** tab surfaces test health and readiness blockers — missing test data, broken prerequisites — with priority, source, and status for each blocker. The **RBT (Risk-Based Testing)** tab provides a heatmap matrix mapping test cases and defects against business priority and usage frequency so you can direct effort toward the highest-risk areas.
### Test Result Detail Pages
Each individual test execution has a detail page showing step-by-step pass/fail results, screenshots, video replay, and downloadable Playwright trace files. See [Test Results](/enterprise-application-testing/reporting/test-results.md) for a full walkthrough.
### Failure Analysis
The failure analysis view provides AI-generated root cause explanations, fix suggestions, and flaky test detection. Failures can be pushed directly to Jira or Azure DevOps. See [Failure Analysis](/enterprise-application-testing/reporting/failure-analysis.md).
***
## Navigating to reports
All reporting surfaces are reachable from the **left sidebar**:
* **Dashboard** — top-level platform summary
* **Execution Dashboard** — run history and per-run detail
* **Reports** — detailed pass/fail reports with screenshots, video, and step logs
***
## In this section
* [Test Results](/enterprise-application-testing/reporting/test-results.md) — understanding execution result pages
* [Analytics Dashboard](/enterprise-application-testing/reporting/analytics-dashboard.md) — dashboards, trends, and AI insights
* [Failure Analysis](/enterprise-application-testing/reporting/failure-analysis.md) — root cause analysis, flakiness, and bug tracker integration
***
## Execution Evidence
The following recording is from a live ContextQA execution of the analytics dashboard:
***
## FAQs
Why do I not see the Review drafts card?
The card appears only when PR Impact has draft recommendations waiting for review. If it is absent, verify that PR Impact is enabled for the workspace and check the PR Impact or Requirements view directly.
How do I scope dashboard data to a specific sprint or date range?
Use the date range picker at the top-right of the Dashboard page to filter all widgets to a specific window. You can select a preset (last 7 days, last 30 days) or define a custom range.
Can I export test results for stakeholder reporting?
ContextQA does not currently offer a general PDF or CSV export for a complete execution result. Share the authenticated execution URL, download the available evidence artifacts, or retrieve structured result JSON through MCP. The separate **Execution history** matrix can export its active view to CSV. See [Exporting Reports](/enterprise-application-testing/reporting/exporting-reports.md) for the exact boundaries.
Where do I see which tests are consistently flaky?
The Execution Dashboard's **Consistently failing test cases** panel ranks tests by failure count. The [Failure Analysis](/enterprise-application-testing/reporting/failure-analysis.md) view provides AI-generated root cause explanations and flaky test detection across your suite.
{% hint style="info" %}
**Get release readiness reports your stakeholders understand** [**Book a Demo →**](https://contextqa.com/book-a-demo/?utm_source=learning.contextqa.com\&utm_medium=referral\&utm_campaign=docs_demand_gen\&utm_content=reporting_overview)
{% endhint %}
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://learning.contextqa.com/enterprise-application-testing/reporting.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.