Test Case Structure: Writing Clear, Repeatable Checks

Why structure matters

A test case is a written, repeatable check that anyone on the team can execute and get the same result. A strong structure prevents “tribal knowledge” (things only one person knows) and reduces ambiguity. The goal is not to write long documents; the goal is to write precise instructions and observable expected results.

Essential components of a well-formed test case

1) Unique ID

Purpose: Traceability and easy reference in conversations, bug reports, and test runs.

• Good: TC-LOGIN-001
• Weak: Login test

2) Title

Purpose: A short, specific description of what is being verified.

• Good: Login fails with valid email and wrong password
• Weak: Check login

3) Objective

Purpose: The intent of the test case in one sentence, focusing on behavior and outcome.

• Good: Verify the system rejects incorrect credentials and shows an error message without logging the user in.
• Weak: Verify login works.

4) Preconditions

Purpose: What must already be true before steps start (environment, user state, configuration).

Continue in our app.

You can listen to the audiobook with the screen off, receive a free certificate for this course, and also have access to 5,000 other free online courses.

Or continue reading below...

Download the app

• Examples: User account exists; user is logged out; application is reachable; email service is enabled (if relevant).

5) Test data

Purpose: The exact inputs to use so results are reproducible. Put concrete values here rather than burying them in steps.

• Examples: Email: user1@example.com; Password: WrongPass!23

6) Steps

Purpose: Actions the tester performs. Steps should be unambiguous and executable by someone unfamiliar with the feature.

How to write clear steps:

• Use numbered actions with one main action per step.
• Refer to UI elements by their visible label (e.g., “Email” field, “Sign in” button).
• State navigation explicitly (where to start, which page/screen).
• Avoid “and then” chains that hide multiple actions in one step.
• Do not include expected results inside steps; keep them in the Expected Results section (or per-step expected results if your team prefers).

7) Expected results

Purpose: Observable outcomes that can be verified (what you can see, hear, measure, or confirm in the system state).

Make expected results explicit:

• Specify messages, page changes, status indicators, and system state (e.g., “User remains logged out”).
• Use exact text only when it matters; otherwise specify key phrases or behavior (e.g., “An error message is displayed indicating invalid credentials”).
• Avoid vague words like “works”, “correct”, “properly”, “successfully” unless you define what that means.

8) Postconditions

Purpose: The state after execution (especially if cleanup is needed). Postconditions help keep tests independent.

• Examples: User remains logged out; no session token created; account is not locked (unless the test is about lockout).

Good vs. weak wording (make outcomes observable)

Replace vague terms with verifiable checks

• Weak: “Login works.”
• Better: “User is redirected to the dashboard page and the header shows the user’s name.”

• Weak: “Error is shown.”
• Better: “An inline error message appears below the Password field and the user remains on the Sign in page.”

• Weak: “Email is validated.”
• Better: “When the Email field contains ‘user@’, the ‘Sign in’ button remains disabled and a message indicates the email format is invalid.”

• Weak: “Data is saved correctly.”
• Better: “After clicking Save, a success toast appears and reopening the profile shows the updated phone number.”

Write steps so another person can execute without guessing

Ambiguity often hides in missing starting points, unclear UI names, or unspecified inputs.

• Weak step: “Go to login and enter credentials.”
• Clear steps: “Open the application home page.” “Click ‘Sign in’.” “In the ‘Email’ field, enter user1@example.com.” “In the ‘Password’ field, enter WrongPass!23.”

• Weak step: “Submit the form.”
• Clear step: “Click the ‘Sign in’ button.”

• Weak step: “Verify user is not logged in.”
• Clear expected result: “The page remains on ‘Sign in’ and no user avatar/name is shown in the header.”

Test case template (copy/paste)

ID: TC-____-___
Title: 
Objective: 
Preconditions:
- 
Test Data:
- 
Steps:
1) 
2) 
3) 
Expected Results:
- 
Postconditions:
- 

Worked example: one scenario turned into multiple detailed test cases

Below is a single scenario (high-level) that can be expanded into several test cases with explicit expected results. The scenario is intentionally broad so you can see how structure creates clarity.

Scenario: User attempts to sign in with different credential combinations.

Test Case 1: Valid email + wrong password

ID: TC-LOGIN-001
Title: Login fails with valid email and wrong password
Objective: Verify the system rejects incorrect credentials and keeps the user logged out.
Preconditions:
- User account exists with email user1@example.com and password CorrectPass!23
- User is logged out
Test Data:
- Email: user1@example.com
- Password: WrongPass!23
Steps:
1) Open the Sign in page.
2) In the 'Email' field, enter user1@example.com.
3) In the 'Password' field, enter WrongPass!23.
4) Click the 'Sign in' button.
Expected Results:
- The user remains on the Sign in page.
- An error message is displayed indicating the credentials are invalid.
- The user is not logged in (no user name/avatar is shown in the header).
Postconditions:
- User remains logged out.

Test Case 2: Unregistered email + any password

ID: TC-LOGIN-002
Title: Login fails with unregistered email
Objective: Verify the system does not authenticate a user that does not exist.
Preconditions:
- User is logged out
Test Data:
- Email: not_registered@example.com
- Password: AnyPass!23
Steps:
1) Open the Sign in page.
2) In the 'Email' field, enter not_registered@example.com.
3) In the 'Password' field, enter AnyPass!23.
4) Click the 'Sign in' button.
Expected Results:
- The user remains on the Sign in page.
- An error message is displayed indicating the credentials are invalid (or account not found, depending on product behavior).
- No authenticated session is created.
Postconditions:
- User remains logged out.

Test Case 3: Empty password

ID: TC-LOGIN-003
Title: Password is required to sign in
Objective: Verify the Password field is mandatory and the user cannot submit without it.
Preconditions:
- User is logged out
Test Data:
- Email: user1@example.com
- Password: (empty)
Steps:
1) Open the Sign in page.
2) In the 'Email' field, enter user1@example.com.
3) Leave the 'Password' field empty.
4) Click the 'Sign in' button.
Expected Results:
- The user remains on the Sign in page.
- A validation message indicates the Password field is required.
- No login request is accepted (user is not authenticated).
Postconditions:
- User remains logged out.

Test Case 4: Successful login (positive check)

ID: TC-LOGIN-004
Title: User can sign in with valid credentials
Objective: Verify a user can authenticate and reach the authenticated area.
Preconditions:
- User account exists with email user1@example.com and password CorrectPass!23
- User is logged out
Test Data:
- Email: user1@example.com
- Password: CorrectPass!23
Steps:
1) Open the Sign in page.
2) In the 'Email' field, enter user1@example.com.
3) In the 'Password' field, enter CorrectPass!23.
4) Click the 'Sign in' button.
Expected Results:
- The user is redirected to the dashboard (or landing page for authenticated users).
- The header shows the user is signed in (e.g., user name or avatar is visible).
Postconditions:
- User is logged in.

Guided activity: expand one scenario into multiple test cases

Goal: Take one scenario and produce 3–6 test cases with clear steps and explicit expected results.

Step 1: Pick one scenario statement

Use this example scenario (or substitute one from your project):

• Scenario: User resets their password using “Forgot password”.

Step 2: List variations that change expected outcomes

Write variations that lead to different observable results. Example variations:

• Registered email vs unregistered email
• Valid email format vs invalid email format
• Reset link used within validity period vs expired link
• New password meets rules vs fails rules
• Confirm password matches vs does not match

Step 3: Turn each variation into a separate test case

Create one test case per variation so each has a single clear objective. Use the template and fill in concrete data.

Step 4: Write steps with no hidden knowledge

For each test case, ensure steps include:

• Starting page/screen
• Exact UI element labels to click/type into
• Exact test data values
• One main action per step

Step 5: Write expected results as observable outcomes

For each test case, include outcomes you can verify without interpretation:

• What message appears (and where)
• Whether navigation occurs (and to which page)
• Whether the user is authenticated or not
• Whether an email is sent (if your test environment allows verification)
• Whether the password is actually updated (e.g., old password fails, new password succeeds)

Activity worksheet (fill-in)

Scenario: User resets password using “Forgot password”.

Variation A (name it): 
Test Case ID: 
Title: 
Objective: 
Preconditions:
- 
Test Data:
- 
Steps:
1) 
2) 
3) 
Expected Results:
- 
Postconditions:
- 

Variation B (name it): 
Test Case ID: 
Title: 
Objective: 
Preconditions:
- 
Test Data:
- 
Steps:
1) 
2) 
3) 
Expected Results:
- 
Postconditions:
-