Test run
A selected set of test cases executed together for a purpose, against a specific build and environment, with an owner and a result per case. The run is the unit that carries execution history. Creating a run rather than editing statuses on the cases themselves is what lets you compare this release with the last one.
Also called: test cycle, test execution
Name it so it still makes sense in six months
"Regression" is a bad run name. "Regression, web, build 4.12.0, staging" is a good one. A run is read long after it closes, by someone comparing releases or chasing a defect, and the name is often the only place the build and environment are recorded. If the tool has fields for build and environment, fill them; if not, put them in the name.
Scope a run by purpose
A run should answer one question: is this build ready, did this fix hold, does this feature work on mobile. Runs that try to answer several questions mix results that mean different things, and the pass rate stops describing anything. A smoke run, a full regression and a retest of fixes are three runs even if they happen on the same day.
Close it
An open run keeps accepting results, and a run that stays open across two builds ends up with results from both. Close or complete a run when its build is done, and start a new one for the next build. Group the runs for a release under a milestone to see the release as a whole.
Manual and automated runs
An automated pipeline produces a run every time it executes. Those runs belong next to the manual ones so a release view shows both, but they arrive far more often, so filter by source when reading trends.
In QAM Hub
A run is built from selected cases, cases can be assigned to testers, and each result records status, comments and attachments. Automated runs arrive from the Playwright and Cypress reporters or from JUnit XML through the CLI. Details are in running tests and recording results and assigning testers.