> For the complete documentation index, see [llms.txt](https://docs.qyrus.com/web-testing/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.qyrus.com/web-testing/analyze/testlab.md).

# Test Lab Reports

Test Lab Reports is where you read the results of everything run from Test Lab. It works the same way as [Sprint Reports](/web-testing/analyze/sprints.md), minus the sprint — Test Lab belongs to the project, so there is nothing to select — and plus scheduling, which is a Test Lab feature.

## Opening Test Lab Reports

Open your project, then in the **Analyze** group click **Reports** under **Test Lab**.

![The Test Lab buttons in the Analyze group](/files/Fkdj1Ohcxvq5CcpbXuO2)

Once you are inside the project you can also use the **Reports** menu in the top bar and choose **Test Lab**.

The screen has two top-level tabs, **Test Lab Reports** and **Scheduled Tests**, and **Active Runs** in the top right showing how many runs are going on now.

**Test Lab Reports** holds five sub-tabs: **Test Lab Dashboard**, **Test Lab Detail**, **Executions**, **Dry Runs** and **Performance**.

These are the same five tabs Sprint Reports has, but **in a different order** — Sprint Reports puts Dry Runs before Executions, Test Lab puts Executions first. Check the tab you are on before you conclude a run is missing.

## Test Lab Dashboard

![The Test Lab Dashboard](/files/Az5H7aHZYANK7mbfCmkD)

| Panel                                  | What it tells you                                |
| -------------------------------------- | ------------------------------------------------ |
| **Overall tests executed in Test Lab** | Total runs, split into **Passed** and **Failed** |
| **Test Suites** / **Test Scripts**     | How much is in Test Lab                          |
| **Scheduled tests**                    | How many schedules are set up                    |
| **Daily test executions**              | Runs per day                                     |

## Test Lab Detail

One row per suite, with its pass rate.

![The Test Lab Detail tab](/files/UUMn55xJYVkB9ebSplAT)

| Column                        | Meaning                                  |
| ----------------------------- | ---------------------------------------- |
| **Test suite / Test scripts** | The name of the suite or script          |
| **Total Execution**           | How many times it has run                |
| **Total Pass**                | How many of those runs passed            |
| **Total Fail**                | How many failed                          |
| **Last 5 Executions**         | The result of each of the last five runs |
| **Pass %**                    | The overall pass rate                    |

Running a suite counts as more than one execution — the suite gets a row and so does each script inside it, so a suite holding one script shows **Total Execution 2** after a single run.

The arrow at the end of a suite row is meant to reveal the scripts inside it. On this screen it changes direction but lists nothing — a known fault. Use **Executions** to see per-script results in the meantime.

## Executions

The full history of everything run from Test Lab.

![The Executions tab](/files/4hbrDPXryZJ8QtUcLZWw)

| Column             | Meaning                        |
| ------------------ | ------------------------------ |
| **Test scripts**   | The script or suite that ran   |
| **Executed on**    | Date and time of the run       |
| **Execution time** | How long it took               |
| **Platform**       | The operating system it ran on |
| **Browser**        | The browser it ran in          |
| **Status**         | **Pass** or **Fail**           |

Use **Search Test Lab Report...** to find a run, **Refresh** to update statuses, and **Delete All** to clear the list.

Three icons sit between **Browser** and **Status** on a finished run: **Video** plays the recording, and **Healer** opens what Healer AI did.

### The row menu

Click the **⋮** on any row.

![The row menu on an execution](/files/O9c5gwR9Se2Mx9PwKbnm)

| Action              | What it does                                    |
| ------------------- | ----------------------------------------------- |
| **Download Report** | Downloads the report for that run               |
| **Mail Report**     | Emails the report to addresses you enter        |
| **Retry**           | Runs it again, as a new entry in the list       |
| **Create Ticket**   | Raises a ticket in your connected issue tracker |
| **Delete**          | Removes that report                             |

### While a run is going

A run appears in the list straight away and works through its statuses — **Allocating Browser** first, then **Running**, then **Pass** or **Fail**.

![A run still allocating a browser](/files/rzYSDeXqpJlUySdL5BYB)

A run in progress shows no execution time and fewer row icons than a finished one.

## Reading a single run

Click the arrow at the end of a row to open the **Run Result**.

![A Test Lab run result](/files/YxvcUXJ5lT6qxrdtYGKT)

The tiles give **Test Cases**, **Passed Tests** and **Failed Tests**, then the conditions of the run and its timings. The **Test Report** tab lists every step with its **Expected Output**, **Actual Output**, **Data** and **Status**, and the icon at the end of a step row opens the screenshot taken at that moment. The **Console Logs** tab beside it shows what the browser logged.

Five buttons sit under the run name: **video**, **Mail Report**, **Download Report**, **Performance Metrics** and **Download PDF**. [Sprint Reports](/web-testing/analyze/sprints.md) covers this screen in more detail — it is the same screen wherever the run came from.

**Performance Metrics** is the one worth knowing about. It opens **Performance Metrics Preview**, a record of the files the browser loaded while the test ran and how long each one took, with a **Download Metrics** button. Every run records it, executions and dry runs alike, with nothing to switch on. See [Performance Metrics](/web-testing/analyze/sprints.md#performance-metrics).

## Dry Runs

Dry runs are listed separately from ordinary executions.

![The Dry Runs tab](/files/DAdReLjtQnTMqtBnmuGT)

The columns and the row **⋮** menu match Executions. The search box is **Search Dry Run Report...**, and until you run one the tab reads "No Dry Run Reports for project". See [Dry Run](/web-testing/run/dryrun.md) for how to start one.

## Performance

The **Performance** tab lists **performance runs**. It is not where you find the timings for an ordinary execution — those are under **Performance Metrics** on the run result itself.

The columns match [Sprint Reports](/web-testing/analyze/sprints.md): **Test Scripts**, **Total Simulations**, **Start Time**, **End Time**, **Executed By** and **Status**.

![The Performance tab](/files/mqaZP5AbMNEU7Qe8KI6U)

The arrow at the end of a row opens the detail of each execution.

![A performance run expanded](/files/0kJoACVypxwJ7aNQ47x1)

Opening a performance run shows its steps, exactly as an ordinary run result does.

![A performance run result](/files/hzpx7b6AhfZMMbAebSu9)

The toolbar offers a download and the **Performance Metrics** view.

![Performance run options](/files/kt66WuC5JaszpnQIGBLM)

**Console Logs** works here too, showing what the browser logged during the run.

![Console logs for a performance run](/files/QTqjow3k5mrFlesGhpmq)

If your **Performance** tab is empty, no performance run has been recorded. An ordinary execution and a dry run do not produce one, and there is no performance option on the **Execute Test** or **Dry Run** configuration screens — so on most projects this tab stays empty.

When the tab is empty its message reads "No Performance Run Reports for selected Sprint", even though Test Lab has no sprints. Ignore the word *Sprint* here.

## Scheduled Tests

The second top-level tab, **Scheduled Tests**, lists reports from runs that a schedule started.

![The Scheduled Tests tab](/files/hAjEKWtTiSUQm4wssBBN)

A schedule that has not fired yet produces no report, so this tab can read "No Scheduled Reports for project" while the dashboard still counts scheduled tests. That is not a fault — it means the time has not come round yet.

## Scheduled Runs

**Scheduled Tests** shows runs that have already happened. **Scheduled Runs** shows the ones still to come. Open it from the project home page, under **Analyze** → **Test Lab** → **Scheduled Runs**.

![The Scheduled Runs screen](/files/BQ0MjMzXz89tEMc53NpM)

Schedules are grouped by type — **Scheduled once** here — with the time, the script, the date it will run, and the platform and browser it will use. **Search Test** filters the list.

### Checking a schedule

Click the **i** on a row for **Schedule Info**: who set it up, when they set it up, and when it will run.

![The Schedule Info popup](/files/6bgaV5wn1j762mflqBrm)

### Pausing or deleting a schedule

The **⋮** on a row offers **Pause** and **Delete**. Pausing keeps the schedule but stops it firing.

![Pause and Delete on a scheduled run](/files/iz9UJ1HA5Ao1l4cml54Y)

### Changing a schedule

Click the pencil on a row to open **Edit scheduling**.

![Editing a one-off schedule](/files/CoPVN2resWGdkN3IqFld)

**Schedule once** runs the test one time. Set **Choose Date**, **Time** and **Timezone**, tick **Share reports after execution** if you want the report emailed out, and click **Save**.

**Schedule repeat** runs it again and again.

![The repeat options](/files/bGiDRJDKKt39axCQL5cx)

All three modes — **Weekly**, **Daily** and **Hourly** — ask for **Choose End Date**, **Time** and **Timezone**. **Weekly** adds a day picker, SUN to SAT, so you can run only on the days you choose. Set the end date to the point you want the schedule to stop.