> 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/getting-started/user-journey.md).
# User journey
Record a test on a real device, run it across a fleet, read the result.
```
CREATE EXECUTE
────────────────────────────────────────── ─────────────────────────
Upload app → Start session → Record → Run → Report
│
┌─────────┴─────────┐
Modules Data sets
(reuse steps) (vary the values)
```
## Create your test
1. **Upload your app.** Go to **Test Creation**. In the **Uploaded Apps** panel, click **Upload** and choose your `.apk` or `.ipa` (up to 250 MB). Wait for the row to show *ready*, then click it to select it.
2. **Start a session.** Pick any free device from the list and click **Start Testing**. A live screenshot of the real device opens in the **Workspace**.
3. **Record a step.** Tap and type on the device screenshot to reach the screen you want, then right-click any element and pick a command. The step appears on the right with its locator already filled in.
4. **Verify.** Click **Run all** to replay your steps on the device. Use **Run from here** to skip a long login while you iterate on the last step.
5. **Stop the session and name the test case.** **Stop** saves your steps and releases the device, then opens the recording on the **Test Cases** screen. Type a name and click **Save**.
## The three commands that cover most tests
| Command | What it does |
| ------------------- | ---------------------------------------------------------------------------------- |
| **Press Element** | Taps the element |
| **Enter Text** | Taps the element, then types into it |
| **Assert Presence** | Checks that something is on the screen. This is what turns a recording into a test |
## Reuse steps with modules
Select a group of steps and click **Create module**. It becomes a single block you can drop into any other test.
Modules are versioned. Each test stays pinned to the version it was built against, so improving a module never changes a passing test until you choose to update it. See [Modules](https://docs.mozark.ai/no-code-studio/authoring-tests/modules).
## Vary the values with data sets
A data set is a table with a key column, almost always `device_serial`. To use one, click into a step's field, click the data set button, and pick the column. The field becomes `${movie_name}`.
Run that one test on two devices and each types its own movie name.
{% hint style="info" %}
One test, many devices, not many loops. Each device reads its own row, in parallel. It does not run twice on one device.
{% endhint %}
See [Test data](https://docs.mozark.ai/no-code-studio/authoring-tests/test-data).
## Run your test
Open **Test Suites → New test suite**, tick the tests and devices, **choose the Application explicitly**, and click **Run now**. Details in [Running tests](https://docs.mozark.ai/no-code-studio/running-and-reporting/running-tests); results in [Reports](https://docs.mozark.ai/no-code-studio/running-and-reporting/reports).
## Next
* [Author your first test](https://docs.mozark.ai/no-code-studio/getting-started/author-your-first-test): the same flow, step by step.
* [Core concepts](https://docs.mozark.ai/no-code-studio/concepts/core-concepts)
---
# 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/getting-started/user-journey.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.
