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.

What is the QA Test Case Builder?

Creates a structured QA test case document with auto-numbered test case IDs, title, preconditions, numbered test steps, test data, expected results, and priority for any feature under test. It runs free in your browser on Gera Tools, with nothing uploaded.

QA Test Case Builder

Name: QA Test Case Builder
Creator: Gera Tools
License: https://creativecommons.org/licenses/by/4.0/

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.

Anatomy of a good test case

Each field serves a specific purpose, and leaving any of them vague is the main reason test cases fail to be reusable:

ID — A unique, stable reference like LOGIN-003. Bug reports, sprint notes, and pull request descriptions can cite it unambiguously. IDs should not change after a case is executed; if you delete a case, retire its ID rather than reusing it.

Title — One sentence describing the exact scenario under test. “User logs in with valid credentials” is better than “Login test” because the former tells the reader exactly what is being verified.

Preconditions — The state the system must be in before step one begins. A missing or vague precondition is the most common reason a test fails inconsistently. Examples: “User is logged out”, “Cart has exactly two items”, “User’s account is unverified”.

Steps — The exact sequence of actions a tester performs. Each step should be a single atomic action. “Enter username and password and click submit” is two steps; split it.

Test data — Concrete values used in the steps. “Enter email [email protected], password TestPass123!” is reproducible. “Enter valid email and password” is not.

Expected result — What the system should do after the final step, in observable terms. “User is redirected to the dashboard and their first name appears in the top-right corner” is better than “Login succeeds”.

Priority — High cases cover critical paths and revenue flows; they run first when time is short. Medium cases cover important but non-critical scenarios. Low cases cover edge cases and cosmetic issues.

Example test case

A login form test with concrete, reproducible fields:

ID: LOGIN-001
Title: Registered user logs in with correct credentials
Preconditions: User has a verified account with email [email protected] and password TestPass99!. User is on the login page, not signed in.
Steps: (1) Enter email [email protected] into the email field. (2) Enter TestPass99! into the password field. (3) Click the Sign In button.
Expected result: User is redirected to /dashboard. Navigation shows “Welcome back, Test User.” Session cookie is set with HttpOnly flag.
Priority: High

Tips

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.
Review test cases when the feature changes — outdated steps are worse than no steps.