> For the complete documentation index, see [llms.txt](https://docs.mozark.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.mozark.ai/no-code-studio/running-and-reporting/running-tests.md).
# Running tests
Take the tests you recorded and run them unattended, on as many devices as you like, now or on a schedule.
**Prerequisites:** at least one saved test case, and an app build uploaded from the **Test Creation** screen.
## Launch a run
Go to **Test Suites**.
| Field | What to do |
| ----------- | -------------------------------------------------------------------------------------------------------------------------------------- |
| Suite name | Optional label for the run, for example *Checkout smoke - nightly*. Shows up in reports |
| Tests | Tick one or more test cases |
| Devices | Tick one or more devices. Every test runs on every device you pick |
| Application | The build to install. **Always set this**: see below |
| Test data | The data set to bind. Optional for device-keyed sets. See [Test data](https://docs.mozark.ai/no-code-studio/authoring-tests/test-data) |
| Schedule | Off runs immediately. On runs weekly |
Click **Run now**. With a schedule set the button reads **Schedule run**.
The footer summarises what you are about to launch, for example *"3 tests · 5 devices · movie\_names"*, so you can sanity-check before committing device time.
### Always choose an Application
The Application dropdown defaults to *"Auto - the app each test was recorded against"*. That works only if the test case already remembers a build. If it does not, the run installs nothing, launches nothing, and comes back **DID NOT RUN** several minutes later with no obvious cause.
{% hint style="danger" %}
Pick the build explicitly. It takes a second and removes the single most common cause of a wasted run.
{% endhint %}
Only builds that match your selected devices' platform are offered. Each option shows the app name, version, package name, platform and upload time, so two builds of the same app are easy to tell apart:
```
Streaming App · v4.2.1 · com.example.streaming · Android · 2 hours ago
```
## How a run is split into jobs
**One job = one platform + one app.** App Studio groups your selection accordingly and submits one job per group.
| Your selection | Jobs |
| ---------------------------------------------------------- | ------------------------ |
| 3 tests, 4 Android devices, one app | 1 job |
| 3 tests, 2 Android + 2 iOS devices | 2 jobs, one per platform |
| 2 tests recorded against different apps, 4 Android devices | 2 jobs, one per app |
This is expected, and each job gets its own report. Submitting a mixed selection is fine; you just get more than one result to read.
## Scheduling
Turn **Schedule** on and pick a day of the week and a time. The run fires at the next matching slot.
Scheduled runs do not open a report immediately. Check **Test Reports** after the scheduled time.
## When a run is rejected
Before any device time is used, App Studio checks every `${variable}`, data-set column, element and module reference in your selection. If something does not resolve you get:
> Some ${references} could not be resolved. Close this to see the details below, fix them, and try again.
The unresolved names are listed under the form with the test case they came from. Typical causes:
| Message points at | Usually means |
| ----------------- | ------------------------------------------------------- |
| A variable name | It was renamed or deleted after the step was recorded |
| A data-set column | The column was renamed or removed |
| A module | The module was deleted while a test still referenced it |
| An element | The element entry a step points at is gone |
Nothing was run. Fix the names and submit again.
## Export a runnable bundle
Need to run a test outside App Studio, or hand a reproducible suite to a developer? On the **Test Cases** screen, select one or more test cases and choose **Download bundle**.
You get a zip named after the test and the time, for example:
```
Add a movie to the watchlist 2026-08-27 1432.zip
```
It contains everything the test needs (steps, modules, locators and your data grids) for both platforms. Run it with the Optics CLI:
```shell
optics execute .
```
The bundle is generated the same way a real run is, so what you download is what would have executed.
## After you submit
A successful submission takes you straight to the report for the job. If the submission produced more than one job, you land on the reports list instead.
Next: [Reports](https://docs.mozark.ai/no-code-studio/running-and-reporting/reports)
---
# 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.mozark.ai/no-code-studio/running-and-reporting/running-tests.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.
