AppReviewX Log in

Test case template with examples

Fields that make a test case repeatable, with three worked examples.

In this guide

A good test case lets someone else repeat your test and get the same result. That needs a known starting point, exact steps and a clear expected result. Use it for flows that must not break: sign-up, purchase, restore, anything on your regression list.

Template (copy and paste)

ID:            TC-<number>
Title:         <what is checked, in one line>
Area / flow:   <e.g. sign-up>
Priority:      <high / medium / low>
Preconditions: <app version, account state, device state, data needed>
Test data:     <exact values to enter>

Steps:
 1. <action>
 2. <action>
 3. <action>

Expected result:
 - <observable outcome, one line each>

Actual result:  <fill when run>
Status:         <pass / fail / blocked>
Device / OS / build: <fill when run>
Notes / bug link:    <optional>

Three examples (illustrative, app-agnostic)

Example 1: sign-up with a valid email

ID: TC-001   Title: New user can sign up with email and password
Area: sign-up   Priority: high
Preconditions: fresh install, no account for test@example.com, network on
Test data: email test@example.com, password Tr1al-Pass!
Steps:
 1. Open the app and tap "Create account".
 2. Enter the email and password.
 3. Tap "Continue".
Expected result:
 - The home screen opens.
 - The email appears in Settings > Account.

Example 2: invalid input is rejected clearly

ID: TC-002   Title: Sign-up rejects an invalid email
Area: sign-up   Priority: medium
Preconditions: fresh install, network on
Test data: email "test@", password Tr1al-Pass!
Steps:
 1. Open "Create account".
 2. Enter the email and password.
 3. Tap "Continue".
Expected result:
 - No account is created.
 - A message next to the email field says what is wrong.
 - The entered password is kept.

Example 3: data survives a restart

ID: TC-003   Title: A saved item is still there after force-closing the app
Area: data   Priority: high
Preconditions: logged in, list is empty
Test data: item name "Test item 1"
Steps:
 1. Add the item.
 2. Force-close the app.
 3. Reopen the app.
Expected result:
 - "Test item 1" is listed once.

How to adapt it

  • Cut fields you never use. Minimum useful set: title, preconditions, steps, expected result.
  • One test case, one purpose. If a title needs "and", split it.
  • Write expected results you can see. "Works correctly" can't fail; "the list shows one item" can.
  • Name the data. Say which account, which values; "a valid email" leaves room for doubt.
  • Link bugs both ways. When a case fails, file it with the bug report template and note the link in the case.

Start free to have other developers run your flows and report what they find.