Writing a manual case

Create one from Test cases → New case. A case needs a name that says what is being checked, and a list of steps.

The three kinds of step

An action — what the tester does, with what should follow.

Open the invoice list → The list shows the customer's 20 most recent invoices.

A check on its own — when nothing new is done, only looked at.

The total reads £120.00.

A note — context the tester needs. It has no result: it is never passed or failed, and never counts towards progress.

You will need two unpaid invoices for this case.

Writing steps people can follow

• One action per step. "Click Save and check the toast" is two steps.
• Say what to look at. "The status badge reads Paid" beats "it works".
• Put setup in preconditions, not in step 1 — what must already be true before the case starts.
• Avoid pointing at pixels. Describe the control by its name, not its position.

Values that change

Write {{name}} where a value comes from the project's variables, and the run fills it in. Write ${email}, ${int:1-100} or ${date:+7d} where every run should get something fresh. Naming one with as lets you use it again later in the same case: ${email as buyer}, then {{buyer}}.

The Syntax page in your project lists every generator with a live example.

Status, priority and owners

A new case is a Draft. Mark it Ready when it is worth running, and Deprecated when it is kept only for history. Priority and tags are your organization's own vocabulary — set them under Organization → Settings.