# Test Case Manager

> Write test cases and scenarios, organise them into steps, and link failures to defects.

> For the complete documentation index, see [llms.txt](https://helpdesk.orangescrum.com/llms.txt).

Source: https://helpdesk.orangescrum.com/guide/cloud/quality/test-case-manager

---
> **Premium Unlimited**
>
> The Test Case Manager is a Premium feature.

Structured test management inside the same workspace as the work being tested —
so a failing test links to a defect, which links to the task that fixes it.

## The structure

| Level | What it is |
| --- | --- |
| **Test scenario** | A grouping — a feature area or user journey |
| **Test case** | One thing being verified |
| **Test step** | An ordered action with an expected result |
| **Defect** | Raised when a case fails |

## Writing test cases

**Start from the scenario**

    Group by feature area — "Checkout", "User registration". Scenarios keep a
    large suite navigable.

**One outcome per case**

    "Checkout succeeds with a saved card" is a case. "Checkout works" is a
    scenario.

**Write steps someone else can follow**

    Each step: an action and an expected result. If it only makes sense to the
    author, it will not survive them leaving.

**State the preconditions**

    What data and state must exist first. Most "flaky" manual tests are actually
    unstated preconditions.

> **Tip**
>
> The test is whether someone who has never seen the feature can execute the
> case from the steps alone. If not, add detail.

## Steps

Steps are ordered and reorderable. Keep them at a consistent granularity — a
case with two enormous steps and eight trivial ones is hard to execute and
harder to maintain.

## Running tests

Execute a case, record the result per step, and raise a
[defect](https://helpdesk.orangescrum.com/guide/cloud/quality/defects) from a failure. The defect carries the
link back, so whoever picks it up can see exactly what was being tested.

## Keeping a suite maintainable

This is where test suites usually fail — not in writing them, but in keeping
them true.

**Delete cases that no longer apply**

    A suite full of cases for removed features trains people to ignore failures.
    That is worse than having no suite.

**Update cases when the feature changes**

    Make it part of the task that changes the feature, not a separate cleanup
    that never happens.

**Prefer fewer, better cases**

    Two hundred maintained cases beat a thousand where half are stale. Coverage
    numbers are not the goal.

**Give scenarios owners**

    Unowned areas of the suite decay silently.

## Import and export

Test cases can be imported in bulk — useful when migrating from a spreadsheet or
another tool. Review a sample after importing; formatting rarely survives
untouched.

## Manual and automated

The Test Case Manager covers **manual** testing. It complements automated tests
rather than replacing them.

- **Automate**: Anything run every build: regression, API contracts, unit-level behaviour.

- **Test manually**: Exploratory testing, usability, visual checks, and things too expensive to automate.

> **Don't manually re-run what CI already covers**
>
> It is slow, it is boring, and bored testers miss things. Manual effort belongs
> where a human notices what a script cannot.

## API access

Test cases, scenarios and steps are all reachable from the
[Developer API](https://helpdesk.orangescrum.com/guide/api/introduction) — useful for syncing with an external
QA tool or generating cases programmatically.

- [Next: defects](https://helpdesk.orangescrum.com/guide/cloud/quality/defects): Raising, triaging and closing bugs.