QAing · Test Case Design Guide and Template

Test case design turns requirements and risks into clear examples that can reveal defects. Good test cases explain the behaviour, data and expected result without tying the reader to unnecessary implementation detail.

On this practical guide

Design flow Approaches Gherkin Examples Template Checklist

A practical design flow

Read the test basis. Review the story, acceptance criteria, design, API contract and related risks.
Identify test conditions. List behaviours or risks that need evidence.
Apply design techniques. Select representative partitions, boundaries, rules, states and combinations.
Choose the right level. Decide whether the case belongs at unit, API, integration, UI or exploratory level.
Write observable outcomes. Verify user, API, data and system effects where relevant.
Review for coverage and duplication. Keep cases focused and traceable.
Prioritise. Run critical and high-risk cases first.

Common test design approaches

Approach	Best used for	Example
Equivalence partitioning	Groups of inputs expected to behave alike.	Valid, expired and unsupported coupon.
Boundary value analysis	Limits where defects commonly occur.	0, 1, 99, 100 and 101 characters.
Decision tables	Combinations of business rules.	Role × account state × requested action.
State transitions	Behaviour controlled by current state.	Draft → Submitted → Approved.
Pairwise testing	Large configuration combinations.	Browser × OS × language.
Use-case or journey testing	End-to-end user goals.	Customer places and tracks an order.
Error guessing	Experience, incidents and known weak areas.	Double click, refresh during save or stale session.
Exploratory charters	Learning, usability and unexpected interactions.	Explore payment recovery under poor network conditions.

Combine techniques: Gherkin structures examples. It does not replace boundary, decision-table or state-transition analysis.

Prioritise Gherkin scenarios

Gherkin expresses behaviour in a shared language using Given, When and Then. It works especially well for acceptance criteria and examples discussed by product, development and QA.

Keyword	Purpose
`Feature`	Capability and its business value.
`Rule`	One business rule inside the feature.
`Background`	Short setup shared by every scenario. Use sparingly.
`Scenario`	One concrete behaviour example.
`Given`	Relevant starting context.
`When`	Action or event under test.
`Then`	Observable outcome.
`And` / `But`	Additional context, actions or outcomes.
`Scenario Outline`	Same behaviour with several example rows.

Good Gherkin principles

Describe business behaviour, not clicks, selectors or code methods.
Keep one main action and outcome per scenario.
Use concrete examples and meaningful names.
Write steps that a product stakeholder can understand.
Keep setup minimal. Mention only context that changes the result.
Make outcomes observable and measurable.
Do not combine unrelated rules to reduce the scenario count.

Gherkin examples

Clear acceptance scenario

Feature: Apply a discount coupon

  Rule: A valid coupon reduces the order total

    Scenario: Customer applies a valid percentage coupon
      Given the customer has a basket worth €100
      And the coupon "SAVE10" provides a 10% discount
      When the customer applies the coupon
      Then the order total should be €90
      And the applied coupon should be shown in the summary

Scenario Outline for representative values

Scenario Outline: Coupon is rejected when it cannot be used
  Given the customer has a valid basket
  And the coupon is 
  When the customer applies the coupon
  Then the coupon should be rejected
  And the message should be ""

  Examples:
    | coupon_state        | message                    |
    | expired             | This coupon has expired    |
    | already used        | This coupon was already used |
    | for another country | This coupon is not available |

State transition example

Scenario: Approved order cannot return to draft
  Given order "ORD-123" is approved
  When an editor requests to return the order to draft
  Then the request should be rejected
  And order "ORD-123" should remain approved
  And the rejected action should be recorded in the audit log

What to avoid in Gherkin

# Too technical and fragile
Scenario: Login
  Given I navigate to "/login"
  When I fill "#email" with "qa@example.com"
  And I click ".primary-button"
  Then the URL contains "/dashboard"

# Better: behaviour-focused
Scenario: Registered user signs in
  Given Ana has an active customer account
  When Ana signs in with valid credentials
  Then Ana should see her customer dashboard

Avoid long scripts with many And steps.
Avoid vague results such as “it works” or “success is shown”.
Avoid using Scenario Outline as a spreadsheet for unrelated cases.
Avoid repeating UI navigation in every scenario.
Avoid automating every written scenario at the UI level.

Detailed test case fields

Gherkin can be the main behaviour specification while metadata records execution details.

Field	Purpose
ID and title	Stable reference and clear behaviour name.
Requirement / risk	Why the case exists.
Priority	Execution order based on impact and likelihood.
Level and type	API, UI, integration, regression, security and so on.
Preconditions	Required state that is not part of the action.
Data	Exact values or method for generating them.
Scenario	Gherkin or concise actions and outcomes.
Expected side effects	Database, audit, email, event or external-system result.
Automation status	Manual, candidate, automated or not suitable.
Evidence	Report, screenshot, trace or execution link.

Copy-ready test case template

# Test Case — [ID]: [Behaviour title]

Requirement / story: [Link or ID]
Product risk: [Risk controlled by this case]
Priority: [Critical / High / Medium / Low]
Test level: [Unit / Component / API / Integration / UI / E2E]
Test type: [Functional / Regression / Security / Accessibility / Other]
Execution: [Manual / Automation candidate / Automated]
Owner: [Role or name]

## Preconditions
- [Required user, system and data state]
- [Required feature flag or dependency]

## Test data
| Field | Value / generation rule |
|-------|-------------------------|
| [Field] | [Value] |

## Scenario
Feature: [Capability]

  Rule: [Business rule]

    Scenario: [Concrete behaviour]
      Given [relevant initial context]
      And [additional context only when needed]
      When [single main action or event]
      Then [observable primary result]
      And [important secondary result]

## Expected technical effects
- API: [Status, contract or request]
- Data: [Stored or unchanged state]
- Events / messages: [Expected event]
- Audit / logs: [Expected record]
- Notifications: [Expected message]

## Cleanup
- [Data or state to restore]

## Traceability
Related regression suite: [Suite / tag]
Related defects: [Links]
Automation test: [Path / link]
Last reviewed: [Date]

## Execution result
Build / environment: [Details]
Result: [Pass / Fail / Blocked / Not run]
Evidence: [Links]
Notes / defect: [Details]

Lightweight story template

For normal sprint work, a smaller version is often enough:

Scenario: [Business behaviour]
Risk: [Why this matters]
Priority: [H/M/L]

Given [context]
When [action]
Then [observable outcome]

Data: [Values]
Level: [API/UI/etc.]
Automation: [Yes/No/Later]
Evidence: [Link after execution]

Review checklist

Each case traces to a requirement, rule or risk.
Positive, negative, boundary, role and state cases are considered.
Gherkin describes behaviour rather than interface mechanics.
Expected results are specific and observable.
Test data is clear, safe and repeatable.
The test runs at the lowest sensible level.
Cases are independent or document their dependency.
Duplicate cases are removed.
Priority reflects risk, not creation order.
Automation is chosen for value and stability.

Useful links

Gherkin reference ↗ — official keywords and syntax.
Cucumber BDD guidance ↗ — collaborative discovery and executable examples.
ISTQB Foundation Level ↗ — test analysis and design techniques.
Playwright tags and annotations ↗ — organise automated coverage and reports.