Test cases & steps

A test case defines how you prove something works. It’s a record you author — with its own identity, fields, lifecycle, and history — and it sits on the thread, linked to the requirements it verifies.

Authoring a test case

You create a test case in the Tests module the same way you create any item: it’s a controlled record, governed by its item type and workflow, versioned from the moment it exists. Give it a clear objective so anyone running it knows what it’s meant to demonstrate.

Structured steps

The heart of a test case is its steps. Rather than a wall of prose, a test case is broken into discrete steps, each with the action to perform and the expected result. Structured steps make a test repeatable and unambiguous, and they let execution be recorded step by step — so a result points to exactly which step passed or failed.

Behavior-style steps

For behavior-driven testing, steps can follow the Given / When / Then form — establishing preconditions, the action under test, and the expected outcome. This keeps acceptance-style tests readable and ties them cleanly to the behavior a requirement describes.

Linking to requirements

A test case earns its place by verifying something. Linking a test case to the requirement (or requirements) it covers is what makes verification real: the requirement now has a test behind it, and the test has a reason to exist. These links drive coverage and suspect status — when a verified requirement changes, its tests are flagged for re-execution. Coverage is covered in its own article; creating the links is covered in Traceability.