> For the complete documentation index, see [llms.txt](https://docs.bugbug.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.bugbug.io/organizing-tests/reporting/standard-reports.md).

# Standard reports

Download PDF summary and JUnit XML reports for BugBug test runs and suite runs: what each contains, the JUnit XML structure and properties, retries, and how to get reports through the API for CI.

BugBug provides standard reports for both **test runs** and **suite runs**. You can access all reports in the [Runs History](/debugging-tests/runs-history.md) module.

{% hint style="success" %}
The PDF summary is available on all plans, including Free. JUnit XML is available from the Core plan. See [pricing](https://bugbug.io/pricing/).
{% endhint %}

### Available report types

* **PDF summary** - visual summary of test results. Test run report includes general information and step statuses. Suite run report provides general information and test run statuses.

> You can view an example [here](https://files.gitbook.com/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MKixgeBPbLvnD0l1eiV%2Fuploads%2FaSpE2N3Rn1rJNpcqJp9A%2FStaging_-_E2E_Regression_tests_2025-10-31_90490.pdf?alt=media\&token=1d8c9f31-a37d-427c-bfaa-0c5c313dec93).

* **JUnit XML** – A structured summary of test results in the output format used by software testing frameworks. See [What's in the JUnit XML report](#whats-in-the-junit-xml-report).

> You can view an example [here](https://files.gitbook.com/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MKixgeBPbLvnD0l1eiV%2Fuploads%2FNYRS6j4VtZq8FbRM2cV4%2FStaging_-_E2E_Regression_tests_2025-10-31_90490.xml?alt=media\&token=ffd6e1dc-fb2f-4451-b8a6-1d8a8b7b6f16).

{% hint style="info" %}
If you need more detailed reports — including screenshots for each step or raw data in CSV or JSON format — see the [Advanced Reports](/organizing-tests/reporting/advanced-reports.md) section.
{% endhint %}

### How to download a standard report

1. Go to the desired **test run** or **suite run**.
2. Open the dropdown menu and click `Download report` .<br>

<figure><img src="https://3168433179-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MKixgeBPbLvnD0l1eiV%2Fuploads%2Fje3jTjyK85GxUdgNLNOG%2Fimage.png?alt=media&amp;token=9de173c0-f802-4002-9bf6-f4084044d282" alt=""><figcaption></figcaption></figure>

3. Select the report type that you need and click `Continue`.

<figure><img src="https://3168433179-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MKixgeBPbLvnD0l1eiV%2Fuploads%2F3TbHHYjeptC4dEhCYYQD%2Fimage.png?alt=media&amp;token=73c14cfa-6d82-4f56-8a0c-a158298f94c9" alt=""><figcaption></figcaption></figure>

4. Add a custom note if you need to include some additional context in the report, and click `Download`.

<figure><img src="https://3168433179-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MKixgeBPbLvnD0l1eiV%2Fuploads%2FbUuJthHccpy8wZiPBDyT%2Fimage.png?alt=media&amp;token=3487c706-6234-4de0-9266-48cafcf5c033" alt=""><figcaption></figcaption></figure>

### Get the JUnit report in CI

The [Public API](/integrations/public-api.md) returns the JUnit XML of a finished run:

```bash
# Suite run
curl -H "Authorization: Token $BUGBUG_API_TOKEN" \
  -o bugbug-junit.xml \
  "https://api.bugbug.io/v2/suiteruns/<suite-run-id>/report/junit/"

# Test run
curl -H "Authorization: Token $BUGBUG_API_TOKEN" \
  -o bugbug-junit.xml \
  "https://api.bugbug.io/v2/testruns/<test-run-id>/report/junit/"
```

Most CI systems (GitHub Actions, GitLab CI, Jenkins, Azure DevOps and others) can read this file to show test results.

### What's in the JUnit XML report

The report follows the common JUnit XML format: a `<testsuites>` root with one `<testsuite>` inside.

**Suite run report**

* `<testsuites>` and `<testsuite>` have the totals: `tests` (number of tests), `failures`, `errors`, `skipped`, `time` (duration in seconds) and `timestamp` (start time). `<testsuites>` is named `BugBug Report for project '<project name>'`, and `<testsuite>` has the suite's name.
* Each test of the suite is one `<testcase>`, with `name` (test name), `classname` (suite name), `time`, `test_run_id` and `sequence` (the run number shown in BugBug).
* A test with the **failed** status has a `<failure>` element, a test with the **error** status an `<error>` element, and a **skipped** test a `<skipped>` element. The `message` names the error code of the failed step, for example `Step failed: ELEMENT_DOES_NOT_EXIST`, and the element's text lists the failed steps with their IDs, error codes and groups.
* `<system-out>` of each test has a summary of its steps: the number of passed, failed and ignored failed steps (**Continue on failure**), the first three steps, and the failed steps. Test notes are included too.
* `<system-out>` of the suite has a summary line, the suite's notes, and a message when no tests were run.

**Test run report**

The same structure with one `<testsuite>` named `Test_<test name>` and one `<testcase>`.

**Retries**

When a test was [retried automatically](/organizing-tests/suites.md), it still appears as one `<testcase>`. Its result is the result of the last attempt, and each earlier failed attempt is a `<rerunFailure>` or `<rerunError>` element. `<system-out>` lists all attempts with their statuses and failed steps. The totals count each test once, by its last attempt.

**Properties**

`<testsuite>` has a `<properties>` element. Properties with no value are left out.

| Property                          | Suite run | Test run | Value                                                                                              |
| --------------------------------- | :-------: | :------: | -------------------------------------------------------------------------------------------------- |
| `report_id`                       |     ✓     |     ✓    | ID of this report.                                                                                 |
| `generated_at`                    |     ✓     |     ✓    | When the report was generated.                                                                     |
| `generated_by`                    |     ✓     |     ✓    | Who generated the report.                                                                          |
| `finished`                        |     ✓     |     ✓    | When the run finished.                                                                             |
| `profile_name`                    |     ✓     |     ✓    | [Profile](/editing-tests/variables.md) used for the run.                                           |
| `run_mode`                        |     ✓     |     ✓    | `local` or `server` (cloud).                                                                       |
| `sequence`                        |     ✓     |     ✓    | Run number.                                                                                        |
| `triggered_by`                    |     ✓     |     ✓    | What started the run: `user`, `api`, `webhook`, `scheduler`, `github`, `cli`, `agent` or `vercel`. |
| `report_format_version`           |     ✓     |     ✓    | Version of the report format, currently `1.1`.                                                     |
| `project_name`                    |     ✓     |          | Project name.                                                                                      |
| `suite_id`                        |     ✓     |          | Suite ID.                                                                                          |
| `parallel_run`                    |     ✓     |          | Whether tests ran in parallel.                                                                     |
| `parallel_slots`                  |     ✓     |          | Number of parallel slots.                                                                          |
| `test_id`                         |           |     ✓    | Test ID.                                                                                           |
| `auto_retry_attempt`              |           |     ✓    | Retry attempt number, 0 for the first run.                                                         |
| `browser_name`, `browser_version` |           |     ✓    | Browser used for the run.                                                                          |
| `browser_width`, `browser_height` |           |     ✓    | Browser window size.                                                                               |
| `os_name`                         |           |     ✓    | Operating system.                                                                                  |
| `extension_version`               |           |     ✓    | BugBug extension version.                                                                          |
| `screen_size_type`                |           |     ✓    | `desktop` or `mobile`.                                                                             |

### Examples of standard reports

Below, you can see examples of a PDF and a JUnit XML report for a single suite run containing multiple tests.

{% file src="/files/EAxyYWdZDghE98aaacN1" %}

{% file src="/files/G6aib1q8swnPHv0IvifT" %}

### FAQ

<details>

<summary>Which properties does the JUnit XML report contain?</summary>

A suite run report has `report_id`, `generated_at`, `generated_by`, `finished`, `parallel_run`, `parallel_slots`, `profile_name`, `project_name`, `run_mode`, `sequence`, `suite_id`, `triggered_by` and `report_format_version`. A test run report has the test and browser details instead of the suite ones. See [Properties](#properties).

</details>

<details>

<summary>How are skipped tests shown in the JUnit report?</summary>

A test that was switched off in the suite is skipped in the suite run. In the JUnit XML it has a `<skipped message="Test was skipped"/>` element and is counted in `skipped`.

</details>

<details>

<summary>Which plans include standard reports?</summary>

The PDF summary is available on every plan, including Free. JUnit XML needs the Core plan or higher. [Advanced reports](/organizing-tests/reporting/advanced-reports.md) need the Business plan.

</details>

<details>

<summary>How do I get the JUnit report from CI?</summary>

Download it from `GET /v2/suiteruns/{id}/report/junit/` (or `/v2/testruns/{id}/report/junit/`) after the run has finished. See [Get the JUnit report in CI](#get-the-junit-report-in-ci).

</details>


---

# 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://docs.bugbug.io/organizing-tests/reporting/standard-reports.md?ask=<question>&goal=<user_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.