Test Case Template (2026)

What a 2026 test case looks like

The 2010s test case was a step-by-step manual script written in a spreadsheet. The 2026 test case is a hybrid artifact: it documents the intent for humans, links to the automation that enforces it, carries tags that determine when it runs, and supports data variants for parameterised execution. Same document, three audiences: the QA engineer writing it, the developer fixing the failure, and the CI pipeline selecting what to run.

Steps vs Gherkin (BDD) — when to use which

Step-by-step is right when the next action depends on the previous result — exploratory tests, complex manual flows, accessibility verification with a screen reader. Gherkin (Given/When/Then) is right when the test maps to an automated suite using Cucumber, Behave, SpecFlow, or Playwright-cucumber. Many teams use both: Gherkin for the automated regression suite, steps for the manual exploratory queue. This template supports both with a single toggle so you don't fragment the format across the team.

Tags — the CI selector you've been missing

Tags turn a test catalog into a filter language. Common tag sets:

• Speed: smoke (under 5 min, every commit), regression (full, nightly), perf (slow, weekly)
• Type: unit, integration, contract, e2e, visual, a11y, security
• Domain: auth, checkout, billing, onboarding
• Risk: critical-path, compliance, flaky (quarantined)

The CI pipeline reads tags to decide what to run. Playwright supports tag filtering via --grep @smoke. Vitest supports it via test.skip patterns. Pytest supports it via marks.

Linked automation — bridging manual and CI

The automation link (e.g., tests/auth/login.spec.ts:34 or @smoke @login) connects the test case to its enforcement. Three benefits:

• When CI fails, the failure URL jumps you to the manual case in seconds — no "what was this test supposed to do?" archaeology.
• When the manual case changes, you know which spec to update — no drift.
• Coverage reporting can join manual catalog × automation suite to show which manual cases lack automation — pure data for the QA backlog.

Data variants — parameterise the same case

Data variants let you run the same case against multiple inputs without duplicating the documentation. Classic uses:

• Boundary value analysis: min, min-1, min+1, max-1, max, max+1
• Equivalence partitioning: valid format, invalid format, empty, oversized
• Locale matrix: en-US, de-DE, ar-EG, ja-JP
• Plan tier: free, pro, max, enterprise

Maps cleanly to parameterised tests: Vitest's describe.each, Playwright's data-driven loops, pytest's parametrize.

How this template works with Jira / Linear / TestRail

The Markdown export pastes cleanly into Linear, GitHub Issues, GitLab, and Notion. For Jira, paste into the description field — the new editor renders Markdown. TestRail accepts CSV import with the columns this template emits. Auto-save means you can write the case, paste to your system, refine, paste again — without losing data on refresh.