Test case template

A test case is a short, repeatable check: start here, do this, expect that. A set of good test cases lets anyone, human or AI, run the same beta test on every build and get comparable results. Copy the template, see a filled-in example, and run your test cases with an AI beta tester.

Who it’s for

  • Teams turning beta scenarios into repeatable checks
  • Developers who want a regression suite without writing automation code
  • Product managers defining what "works" means for a feature
  • Beta testers asked to follow structured tests

Updated 2026-10-19.

What a test case is (and is not)

A test scenario is a goal: "a user can reset their password". A test case is one concrete, repeatable check inside it: "requesting a reset for an unknown email shows a neutral message". Scenarios suit exploratory beta testing; test cases check the same thing the same way on every build. A good beta test uses both.

A good test case has one clear expected result, so it either passes or fails. If you cannot tell, the case is too vague.

The full test case template

TEST CASE ID:    [e.g. TC-AUTH-003]
TITLE:           [What is verified, e.g. "Reset link for unknown email shows neutral message"]
FEATURE / AREA:  [e.g. Authentication]
PRIORITY:        [High / Medium / Low]
TYPE:            [Functional / UI / Accessibility / Regression / Smoke]

PRECONDITIONS
  - [State before starting, e.g. "Logged out", "Test account exists with plan X"]

TEST DATA
  - [Inputs, e.g. email: [email protected]]

STEPS
  1. [Action]
  2. [Action]
  3. [Action]

EXPECTED RESULT
  [The one observable outcome that means pass]

ENVIRONMENT
  [Browser / device / viewport / build]

ACTUAL RESULT:   [Filled in when run]
STATUS:          [Pass / Fail / Blocked / Not run]
EVIDENCE:        [Screenshot or recording link]
BUG LINK:        [If failed]
RUN BY / DATE:   [name or tester, date]

Short version (one line per case)

Useful for a spreadsheet or a smoke test list that runs on every build.

ID | Title | Preconditions | Steps | Expected | Status
TC-ONB-001 | New user can sign up with email | Logged out | Open /signup, enter
  new email + password, submit | Lands on dashboard, welcome message shown | [ ]
TC-ONB-002 | Duplicate email is rejected | Account exists | Sign up with same
  email | "This email is already registered" shown, no second account | [ ]

How to write test cases, step by step

  1. Pick one feature and list its scenarios as user goals.
  2. For each scenario, write the happy path case first.
  3. Add cases for empty input, invalid input, wrong permissions and limits (longest name, maximum items).
  4. Write the preconditions and exact test data for each case.
  5. Give each case one observable expected result.
  6. Set priority: High for core flows like signup, checkout and saving data.
  7. Run the cases on the current build, record status and link a bug for every failure.

How to fill in each field

  • ID: use a prefix per area (AUTH, CHECKOUT, ONB) so cases stay organized as the list grows.
  • Title: what is verified, written as the expected behavior. Reading only the titles should show your coverage.
  • Preconditions: everything that must be true before step 1. Most "flaky" cases are really missing preconditions.
  • Test data: exact values. "A long name" is vague; "a 256-character name" is a test.
  • Steps: one action per step, no expected results mixed in. If a case has 20 steps, split it.
  • Expected result: "works correctly" is not one; "the message 'If an account exists, we sent a link' appears" is.
  • Status: Blocked is not Fail. Blocked means an earlier problem stopped you running the case.

Example (fictional): a habit-tracking web app

ID: TC-HAB-007          PRIORITY: High        TYPE: Functional, Regression
TITLE: Habit name longer than 60 characters is rejected with a clear message
PRECONDITIONS: Logged in as a test user with fewer than 10 habits
TEST DATA: name = 61 characters ("a" x 61)
STEPS:
  1. Open /habits and click "New habit".
  2. Paste the 61-character name.
  3. Click "Save".
EXPECTED: Habit is not saved; the message "Use 60 characters or fewer"
          appears under the field; the typed text is kept.
ENVIRONMENT: Chrome desktop and 390px mobile viewport, build 0.9.4
ACTUAL: Habit saved with the full 61 characters; no message shown.
STATUS: Fail       BUG: Habits: names over 60 characters are saved (Major)

Which failures to fix first

Failed High priority cases in core flows come first, especially anything that loses data or blocks signup or payment. Then failures that show up on several browsers or devices, then Medium cases. Re-run every failed case after the fix, plus the cases around it, before marking it Pass.

Common mistakes

  • Several checks in one case: when it fails, you don't know which part failed.
  • Vague expected results that two people would judge differently.
  • Hidden dependencies between cases. Make each case stand alone, or say so in the preconditions.
  • Only happy paths: add invalid input and wrong-permission cases.
  • Never updating cases after the product changes, so they fail for the wrong reasons.

Running test cases manually vs with an AI beta tester

Writing test cases is the slow part; running them on every build is the boring part. Paste your cases into a task and an AI beta tester (betatest.ing) runs each one in a real browser or on phones, fills in actual result and status, and attaches an annotated screenshot or recording to every failure. It can draft cases after exploring a feature, and scheduled runs after each deploy give you a regression suite without automation code. Keep human beta testers for what cases can't capture: whether the flow makes sense to real users, plus real-device conditions such as offline networks, camera, GPS or push notifications.

The test task

What you send your AI beta tester. It works out the steps and tests like a real user.

Run these test cases on [APP URL] and fill in the results: [YOUR TEST CASES]. For each case: check the preconditions first, follow the steps exactly with the given test data, compare with the expected result, and set STATUS to Pass, Fail, Blocked (say what blocked it) or Not run. Run every case on desktop and again at a 390px mobile viewport unless the case says otherwise. For every Fail, log a finding with steps to reproduce, the actual result with exact error text, console errors from the logs, an annotated screenshot and a recording. If a case is ambiguous, run it as written and suggest a clearer version. Do not make real payments or delete real data. End with a results table (ID, title, desktop status, mobile status, bug link) and a pass rate per feature area.

Fill in your details

Here, or later in the chat with your tester.

  • [APP URL] The link to the site or app (staging is ideal).
  • [YOUR TEST CASES] Paste your test cases in the template format, or a numbered list of steps and expected results.

What the AI beta tester checks

  • Preconditions before each test case
  • Every step with the exact test data given
  • The actual result against the expected result
  • Each case on desktop and at a mobile viewport
  • Console errors and failed requests during each case
  • Ambiguous cases, with a clearer rewrite suggested

What you get

  • A results table with status per test case on desktop and mobile
  • A bug report for every failure, with steps and annotated screenshots
  • Recordings of failed cases
  • A pass rate per feature area
  • Suggested rewrites for unclear test cases

How to run it with betatest.ing

  1. Add your app as a project with a test login that meets your preconditions.
  2. Paste your test cases into the task above and send it.
  3. Review the results table and the bugs filed for failures.
  4. Schedule the same task after every deploy as a regression run.

Tips

  • Start with 10 to 20 high-priority cases covering your core flows; grow from there.
  • Keep test data in the case itself so every run uses the same inputs.
  • Tag cases by type (smoke, regression) so you can run a quick subset after small deploys.
  • Ask the tester to draft cases for a new feature, then review and keep the good ones.

Test case template: FAQ

What is a test case template?

A fixed structure for writing tests: an ID, a title, preconditions, test data, numbered steps, one expected result, the environment, and fields for the actual result, status and evidence. It makes tests repeatable and comparable between runs.

What is the difference between a test case and a test scenario?

A test scenario is a goal to explore, such as "a user can check out". A test case is one specific, repeatable check within it, with exact steps, data and a single expected result.

How many test cases do I need for a beta?

Enough to cover your core flows and their most likely failures. For a small web app, a few dozen well-chosen cases often cover the critical paths; add cases whenever a bug escapes so it cannot come back unnoticed.

Should beta testers follow test cases?

Use both approaches. Give human beta testers scenarios and freedom to explore, because that finds unexpected problems. Use test cases for the checks that must pass on every build, which an AI beta tester can run each time.

Can an AI beta tester run my test cases?

Yes. Paste the cases into a task and it runs each one in a real browser on desktop and mobile, records pass or fail, and attaches a bug report with an annotated screenshot and a recording for every failure.

What is the difference between a test case and a test plan?

A test plan describes the whole testing effort: goals, scope, who tests, timeline and exit criteria. Test cases are the individual checks that the plan calls for. A beta test plan usually links to a list of test cases for the flows that must pass before launch.

Can I write test cases in a spreadsheet?

Yes. One row per case with ID, title, preconditions, steps, expected result and status works well for small teams. Move to a test management tool only when the list gets hard to filter or several people run cases at once.

What is a negative test case?

A negative test case checks that the product handles wrong or unexpected input gracefully, such as an invalid email, an empty required field or a user without permission. The expected result is usually a clear error message and no saved data. Many real bugs hide in these paths, so write at least one negative case per form or flow.

Related beta testing guides

  • Regression testing after deploys — Regression testing checks that what worked yesterday still works after today’s change. For small teams shipping often, a short regression suite run after every deploy prevents most "it used to work" bugs from reaching users.
  • Smoke testing — A smoke test is a short, shallow test that answers one question: is this build working well enough to use and test further? It takes minutes, and it is the first thing to run after any deploy.
  • Bug report template — A good bug report lets a developer reproduce the problem on the first try. This template has every field that matters and nothing extra. Give it to your beta testers, or ask your AI beta tester to file every bug in exactly this format.
  • Beta test plan template — A one-page beta test plan keeps a beta focused: what you are testing, who tests it, for how long, and what "ready to launch" means. Copy the template below, fill in each part, or let your AI beta tester explore your app and draft the plan for you.
  • Form validation testing — Forms are where users give you their data, and where broken validation quietly loses leads, orders and signups. This page lists the edge cases worth trying on every form and a ready test task for your AI beta tester.
  • Free tool: Test case generator — A table of test cases with steps, data and expected results, edge cases included. CSV and Markdown export.

More in templates