> ## Documentation Index
> Fetch the complete documentation index at: https://quashbugs.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Test Case

> A test case is a saved, reusable testing instruction. It defines what Mahoraga should do and what a successful outcome looks like — stored in your library so it can be run repeatedly, added to mult...

## Test Cases

A test case is a saved, reusable testing instruction. It defines what Mahoraga should do and what a successful outcome looks like — stored in your library so it can be run repeatedly, added to multiple suites, and shared across your team.

**To access Test Cases:** Click the **Test Cases** icon in the left navigation panel.

### What a test case is

Every test case has two core parts:

**An instruction** — the steps Mahoraga follows during execution. Written in plain English, the same way you would describe the interaction to a person. No selectors, no code, no element IDs.

**An expected result** — what the app should look like when the instruction completes successfully. This is the pass condition Mahoraga checks its work against and what appears in the execution report.

Beyond those two fields, a test case carries metadata — its priority, type, platform, and tags — that determines how it is filtered, grouped, and scheduled across your testing strategy.

### How test cases differ from tasks

Both tasks and test cases give Mahoraga a plain English instruction to execute. The difference is what happens before and after.

A **task** is ephemeral — you write it, run it, read the report, and move on. It is not saved anywhere. Use tasks for one-off checks and ad-hoc exploration.

A **test case** is permanent — it lives in your library, has a name, carries metadata, and can be run again at any time as part of a suite. Use test cases for anything you plan to run more than once.

A task often becomes a test case. You write a task to explore a new flow, the run goes well, and you decide you want it in your regression suite. At that point, save it as a test case — the instruction is the same, the permanence is what changes.

### How test cases fit into the bigger picture

```
Test Case
  └── A saved instruction with an expected result.
      Exists in the library. Can belong to multiple suites.

Suite
  └── A collection of test cases run together.
      One suite can contain dozens of test cases.
      Each suite run generates one unified report.

Execution Report
  └── The result of a suite run.
      Shows pass/fail per case, step screenshots, device recording.
```

The test cases library is where everything starts. Suites are how test cases become a testing strategy.

### What each test case contains

| Field               | Purpose                                                                     |
| ------------------- | --------------------------------------------------------------------------- |
| **Name**            | Identifies the test case in the library, suite views, and reports           |
| **Instruction**     | The steps Mahoraga follows — written in plain English                       |
| **Expected Result** | The pass condition — what should be true at the end of a successful run     |
| **Platform**        | Android, iOS, or Both                                                       |
| **Priority**        | Critical, High, Medium, or Low — determines scheduling and suite membership |
| **Type**            | Functional, Smoke, Regression, E2E, or Custom                               |
| **Tags**            | Freeform labels for filtering and grouping                                  |
| **Source**          | How the test case was created — Agent (generated by Megumi) or Manual       |

### Two ways to create test cases

**From Test Studio** — prompt Megumi with what you want to test, and it generates structured test cases from your descriptions, PRDs, Figma files, and codebase. Save them to the library in bulk from the Tests panel. This is the fastest path to broad coverage.

**Manually** — click **+ New Test Case** and fill in the fields directly. Use this when you know exactly what you want to test and want full control over the instruction from the start.

[→ Creating a Test Case](/test-management/test-case/creating-a-test-case)

### Next steps

* [About the Test Cases library ](/test-management/test-case/about-the-test-cases-library)— the list view, columns, filtering, and bulk actions
* [Creating a Test Case](https://claude.ai/chat/creating-a-test-case.md) — field-by-field guide to manual creation
* [Managing Test Cases ](/test-management/test-case/managing-test-cases)— editing, adding to suites, deleting
* [Best Practices ](/test-management/test-case/best-practices)— writing effective instructions and expected results