Runs & execution

A test run is an actual execution of a test plan. It’s where verification stops being a plan and becomes evidence: testers work through the cases, record what happened, and the results are captured as a permanent record.

Creating a run

You create a run from a plan and give it the context it needs:

• a run name identifying this pass
• the test plan it executes (and whether to include all of its cases)
• a due date and the milestone it belongs to
• references to related items, such as the requirements or tickets it relates to
• assignees — who’s responsible for executing it

This turns a plan into a scheduled, owned unit of work.

Executing step by step

Within a run, each test case is executed by its steps. As a tester performs an action, they record the result for that step, so the outcome is captured at the granularity of the test — not just “this case failed,” but exactly where. Per-step results include passed, failed, blocked, skipped, and retest, with anything not yet executed shown as outstanding.

Capturing evidence

Execution is where evidence is collected. A run records who executed what and when, and supporting evidence can be attached to results — the proof that a verification was actually performed. Under regulation this is the point: the run is contemporaneous, attributable evidence rather than a recollection after the fact.

Run status and what follows

A run’s overall status reflects its results, so you can see at a glance whether the plan passed, where it’s stuck, and what remains. A failed step is the natural trigger for logging a defect (covered in Defects), and the results feed verification coverage across the program. Because runs are independent records, you can execute the same plan again for the next iteration with a clean, separately recorded result.