> For the complete documentation index, see [llms.txt](https://quash.gitbook.io/quash-documentation/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://quash.gitbook.io/quash-documentation/running-tests/task-overview.md).

# Task Overview

## Tasks

A task is the most direct interaction you can have with Quash. Write a plain English instruction, select a device, and Mahoraga executes it immediately. No test library to manage, no suite to configure, no setup beyond having a device connected.

**To access Tasks:** Click **New Task** in the left navigation panel.

<figure><img src="https://752090225-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FhoGlOS0eqN560gbwRZtT%2Fuploads%2FmTzs7ZIm1RsEiAzRrQKd%2Fimage.png?alt=media&amp;token=c8d07970-472e-410c-ac77-4d7f63cd0100" alt=""><figcaption></figcaption></figure>

### What a task actually is

A task is a single instruction session between you and [Mahoraga ](/quash-documentation/getting-started/core-concepts/megumi-and-mahoraga.md)— Quash's execution agent. You describe what you want tested in plain English. Mahoraga reads your instruction, opens your app on the connected device, and carries it out step by step — tapping, typing, scrolling, and navigating exactly as a human tester would.

Every task run captures a full screen recording, a step-by-step screenshot log, and an AI-written summary of what happened. The result appears in [Reports](/quash-documentation/execution-reports/report-dashboard.md) immediately after the run finishes.

### What tasks are for

Tasks are built for speed and flexibility. They are the right tool when you need an answer quickly — not when you are building systematic test coverage.

**Use a task when:**

* You want to quickly verify a specific bug fix before closing a ticket
* You are exploring a new feature or flow for the first time
* You need a fast sanity check before pushing a release
* You are testing something once and have no plans to repeat it
* You want to see how Mahoraga behaves on a particular screen before writing a formal test case

**Do not use a task when:**

* You need the test to run repeatedly on a schedule or in CI/CD — use a [Suite](/quash-documentation/running-tests/suites-overview.md)
* You want to build organised, reusable test coverage — use [Test Cases](/quash-documentation/test-management/test-case.md)
* You need to generate tests from a spec or PRD — use [Test Studio](/quash-documentation/test-studio/recipe.md)

### How tasks fit into the bigger picture

Quash has three levels at which you interact with test execution. Tasks are the most immediate.

```
Task
  └── A single ad-hoc run. No library, no setup.
      Run once, read the report, move on.

Test Case
  └── A saved, reusable instruction in your library.
      The same task — formalised, named, and ready to repeat.

Suite
  └── A collection of test cases run together.
      Your testing strategy, executed as a unit.
```

A task often becomes a test case. You write a task to explore a flow, the run goes well, and you decide you want to run it regularly. At that point, you save the instruction as a test case in your library and add it to a suite. The task was the starting point — the test case is the permanence.

### The task interface

When you open Tasks, you see two things: the task input area on the left and the device view on the right.

**Task input area** This is where you write your prompt. There is no character limit. The input also accepts context attachments — you can reference a [Test Data ](/quash-documentation/test-management/test-data-overview.md)dataset using `/slug` syntax, and [Backend Validations ](/quash-documentation/running-tests/backend-validations.md)using `@slug` syntax, directly inside the prompt.

**Device picker** Above the prompt, you select which connected device Mahoraga runs the task on. Any device showing as **Available** in your [Devices ](/quash-documentation/devices/overview.md)section can be selected. If the list is empty, connect a device first.

**App picker** Select which app Mahoraga should test. The list shows apps you have added in [Apps](/quash-documentation/apps/adding-an-app.md). If [Credentials ](/quash-documentation/apps/credentials.md)are configured for the selected app, Mahoraga uses them automatically whenever authentication is needed during the run.

**Device view** The right panel shows a live stream of the device screen during execution. Watch every tap and swipe in real time. After the run, the device view shows the session recording — you can replay, pause, and scrub through the full run.

### What Mahoraga does with your instruction

When you run a task, Mahoraga:

1. Reads your full instruction before taking any action
2. Launches the selected app on the device
3. Navigates to the starting point your instruction describes
4. Executes each step — tapping elements, entering text, scrolling, swiping
5. Takes a screenshot after each significant action
6. Evaluates whether the expected outcome in your instruction was met
7. Returns a Pass, Failed, or Partial Success verdict with a full report

Mahoraga uses Android's accessibility APIs to detect and interact with UI elements. It does not rely on hardcoded selectors or element IDs — it reads the live screen the same way a human would, which means it adapts naturally to minor UI changes without requiring prompt updates.

### Task history

Every task you run is saved to your task history. From the Tasks section you can:

* See all previous task runs with their prompts, devices, and outcomes
* Reopen any past task to view its report
* Rerun a previous task with the same prompt on any available device
* Use a past task prompt as the starting point for a new one

Task history is workspace-scoped — all team members with appropriate access can see tasks run by others. This makes tasks useful for async debugging: a developer can run a task to reproduce a bug, and a QA engineer can open the same report and see exactly what the agent did.

### Next steps

* [Creating a task](/quash-documentation/running-tests/task-overview.md) — prompt structure, examples, running, and outcomes
* [Test Cases ](/quash-documentation/test-management/test-case.md)— formalise a task into reusable coverage
* [Suites](/quash-documentation/running-tests/suites-overview.md) — run multiple test cases together
* [Test Data](/quash-documentation/test-management/test-data-overview.md)[ ](/quash-documentation/apps/test-data-in-app.md)— run the same task with multiple input sets using `/slug`
* [Backend Validations ](/quash-documentation/running-tests/backend-validations.md)— verify API state during a task run using `@slug`