What fields belong in a QA test case?

A complete test case has an ID, title, preconditions, ordered steps, test data, an expected result, and a priority. The builder enforces exactly these fields so every case is runnable by another tester without guesswork.

How are test case IDs generated?

Each case gets an ID built from your feature prefix plus a zero-padded sequence number, like CART-003. IDs renumber automatically as you add or remove cases so they stay sequential.

What is the difference between preconditions and steps?

Preconditions are the state the system must be in before the test begins, such as a logged-in user; steps are the actions the tester performs. Separating them keeps the test repeatable and the failure cause clear.

Why assign a priority to each case?

Priority tells the team which cases to run first when time is short. High-priority cases usually cover critical paths and revenue flows, so the builder includes a High, Medium, or Low selector per case.

Does this store my test cases?

No. The tool runs entirely in your browser with no uploads, so your test cases stay private. Copy the output to save it into your own system.

QA Test Case Builder

Email me this result

Get this tool's output sent to your inbox, plus one useful tool a week. No spam, unsubscribe any time.

Runnable test cases in a consistent format

A test case is only useful if another tester can run it without asking questions. This builder produces well-structured cases — ID, title, preconditions, steps, data, expected result, and priority — in a consistent layout, with IDs that renumber themselves as your suite grows.

How it works

You set a feature prefix, and each test case is assigned an auto-numbered ID combining that prefix with a zero-padded sequence number. For every case you capture the title, the preconditions that must hold first, the ordered steps a tester performs, the test data to use, the expected result, and a priority of High, Medium, or Low. The tool normalises your step lines into a clean numbered list and renders the whole suite as a copy-ready document. Removing a case automatically renumbers the rest so IDs never have gaps.

Tips and example

Use a short, stable prefix per feature — LOGIN, CART, SEARCH — so IDs are easy to reference in bug reports.
Keep one expected result per case; if a flow has two outcomes, split it into two cases.
Put concrete values in the test data field, like email: [email protected], so the case is reproducible.
Mark critical-path cases High so they run first under time pressure.