Use Test Execution Reports in Test Reporting & Analytics
Create, view, filter, export, and share Test Execution Reports to track coverage, stability, flakiness, and failures across builds and projects.
A test execution report aggregates test executions across the builds, projects, tags, or metadata you select. This report shows how each unique test’s status is aggregated across every build in scope.
In test execution reports, status displays the latest test execution state. So, a test that failed in an earlier build but passed on its most recent run shows as Passed.
When to use a test execution report
Use a test execution report to answer one question: ‘Is my suite ready to release?’ It lists every unique test in scope and its consolidated status across all the builds and projects you include. This report shows a single, deduplicated pass/fail picture of your test suite, so that you don’t have to check builds one by one.
Common uses:
- Release readiness (go/no-go): Confirm every unique test is green using the Summary, New failures, and Always failing tiles before shipping.
- Stability and flakiness tracking: Monitor results over a chosen time window.
- Cross-project coverage audit: See what’s covered across projects in one view.
- Proof-of-coverage snapshot: Share a deduplicated picture of your suite for sign-off or compliance.
Reports is a paid capability. Test data comes from the BrowserStack SDK or Test Observability, so builds using a non-SDK or unsupported SDK integration might not appear. You can create a report as private, visible only to you, or public, visible to everyone in your organization.
What a test execution report includes
Each test execution report offers:
-
Data sources: Select a data source type:
- Static: Select specific build runs.
- Dynamic: Define criteria using filters. Time frame and Projects are mandatory. Add any of the following optional filters to narrow the data source further:
- Users
- Unique build names
- Build tags
- Test tags
- Hooks visibility
- Host names
- Folder names
- CI runs only
- Branch
- Device
- OS
- Browser
- Stat tiles: High-value metrics such as summary counts, flaky tests, new failures, always failing, and open issues.
- Tabular view: Customizable columns such as test name, status, browser version, OS, project name, build name, file path, failure rate, average duration, flakiness percentage, last 10 runs, smart tags, test tags, failure category, and open issues.
- Drilldown: Click a test row to open test health or the debugger, or click a stat tile to apply a filter such as New Failures.
Stat tiles
Each stat tile surfaces a different signal about the tests in scope:
| Stat tile | What it means | How to read it |
|---|---|---|
| Summary | Pass, fail, and skip counts across every unique test in scope. | Your topline release-readiness number. |
| Flaky tests | Tests that pass on a retry or flip status across recent runs. | Investigate before you trust their results in a release decision. |
| New failures | Tests failing with an error not seen in recent runs. | A new regression, triage before release. |
| Always failing | Tests continuously failing with the same error across recent runs. | Chronically broken, quarantine or fix before gating. |
| Open issues | Tests already linked to a bug or ticket in your issue tracker. | Already tracked, confirm the fix ships instead of re-triaging. |
How to create a test execution report
Follow these steps to create a test execution report:
- Open Reports from the sidebar.
- Select Create Report.
- Select Test Execution Report as the report type.
- Add a data source:
- Click Add Data.
- Enter a name for the data source.
- Select a data source type: Dynamic to query data using filters, or Static to select specific runs.
- For a dynamic data source, select a time frame and one or more projects, then click Add filters to narrow the data source further with build tags, test tags, branch, device, OS, browser, and more.
- For a static data source, select a project and date range, then select the specific builds you want to include.
- Click Create. Repeat to add more data sources.
- Click Save and finish.
- Enter a name for the report.
- Switch on Public Report if you want to share it within your organization.
- Click Create Report.
How to view a test execution report
Follow these steps to view a test execution report:
- Open Reports from the sidebar.
- From the list of available reports, select the test execution report you want to view. The list contains a column to denote whether it is a test execution report or a build comparison report.
- Search and filter the table. Your personal filter state does not change the saved configuration:
- Use the search bar to find tests by name, file path, or error.
- Use Filters to refine by status, flaky, new failure, always failing, open issues, hooks visibility, user, folder, and project custom fields.
- Interact with stat tiles. Click a tile, for example Failed, to filter the table to that status.
- Drill down:
- Click a test row to open the test’s detail panel with history, trend, build information, and custom fields, or the debugger.
- Hover over the Last 10 runs sequence for run status tooltips.
- Expand failure stack trace column entries for detailed logs.
- Refine the table view. Sort, search, and filter within columns. Global search applies across fields.
- Export the report using the download buttons in the top-right corner.
- Share the report:
- Copy the link to retain current filters.
- Use the public URL if visibility is org-wide.
Best practices
Follow these best practices to get the most out of test execution reports:
- Keep filters consistent when performing trend comparisons.
- Quarantine highly unstable tests surfaced in flakiness metrics before release gating.
- Use test execution reports as proof of coverage for sign-off meetings.
- Regularly export and archive test execution reports for compliance trails.
Troubleshooting
If you encounter issues while using test execution reports, consider the following troubleshooting tips:
- Incomplete data: Verify project access, retention window coverage, and that the builds use the BrowserStack SDK or Test Observability. Non-SDK or unsupported SDK builds might not appear.
- Missing columns: Re-enter Edit Mode to enable additional fields.
- Unexpected duplicates: Check overlapping data source segments. Deduplication might mask intended separate entries.
Related resources
- Build Comparison Reports: Compare two builds to surface regressions and coverage changes.
- Custom dashboards: Understand whether a report or dashboard suits your use case.
We're sorry to hear that. Please share your feedback so we can do better
Contact our Support team for immediate help while we work on improving our docs.
We're continuously improving our docs. We'd love to know what you liked
We're sorry to hear that. Please share your feedback so we can do better
Contact our Support team for immediate help while we work on improving our docs.
We're continuously improving our docs. We'd love to know what you liked
Thank you for your valuable feedback!