Creating a Test Run
Go to Test Runs in the sidebar and click Start New Run. Give the run a name that makes its scope clear at a glance, then fill in the details.
| Field | Description |
|---|---|
| Name | e.g. "Release 3.2 — Regression Suite" or "Sprint 24 Smoke". Be specific — this name appears in reports. |
| Description | Scope, environment, and any prerequisites testers need before they start |
| App Version | The build or version number being tested — printed in the final report |
| Release | Optionally associate this run with a release. Runs can be filtered by release on the Test Runs list page. |
Duplicating a run
Use the ⋮ menu → Duplicate on any existing run to create a copy with the same name, description, app version, and selected cases. Useful when re-running the same regression suite for a new build.
Selecting Test Cases
After saving the run, the case picker opens. Add cases individually or in bulk by folder.
Adding cases
- Select entire folders to include every case inside them in one click.
- Filter by priority before selecting — useful for composing a Critical-only smoke run.
- Search by title to add specific cases from across your folder hierarchy.
- Cases already in the run are highlighted so you avoid duplicates.
Run scope guidance
Smoke run
15–30 critical-path cases. Run before every deployment to confirm nothing is fundamentally broken.
Sprint regression
All cases linked to tickets in the current sprint, plus your smoke cases.
Full regression
Every case in the library. Reserve for major releases — it's thorough but time-consuming.
Executing Tests
Click into a test run to open the execution view. Each case is listed with its steps and expected result. Work through them one by one and mark a result for each.
Result statuses
| Field | Description |
|---|---|
| Passed | Test executed successfully — all steps matched the expected result. |
| Failed | One or more steps did not match the expected result. Add a note describing what went wrong and optionally create a ticket. |
| Blocked | Cannot execute — a dependency, environment issue, or prerequisite is preventing the test from running. |
| Retest | The case was previously failed, a fix has been applied, and it needs to be re-executed to confirm the fix. |
| Skipped | Out of scope for this run — for example, the feature has not been deployed to the target environment yet. |
Logging failures
- When marking a case as Failed, add an execution note describing exactly what went wrong and on which step.
- Attach screenshots, log files, or screen recordings directly to the case result.
- Click Create Ticket to open a pre-filled bug report linked to the failed case — the ticket appears on the project board automatically.
- Mark as Retest after the developer pushes a fix to flag it for re-execution.
Run progress indicator
Each run on the Test Runs list shows a circular progress ring. The ring fills as cases receive any result status — it represents execution progress, not pass rate. The badge row beneath it breaks down counts by status: Passed, Failed, Retest, and Skipped.
Multi-Assignee Support
Distribute a large run across your QA team to finish faster without losing accountability.
Open the Assign panel
Inside the test run, click Assign to open the assignment drawer.
Assign cases to team members
Select individual cases or entire folders, then pick an assignee. A tester can be assigned any number of cases across the same run.
Track per-person progress
The Assignees tab shows a completion bar per person — easy to spot who needs support.
Reassign mid-run if needed
If a tester is unavailable, reassign their remaining open cases to someone else. Completed results are unaffected.
Reports & Export
Live dashboard
- The run header shows overall execution progress and a real-time breakdown of Passed / Failed / Blocked / Retest / Skipped counts.
- A bar chart breaks results down by folder, giving you a per-suite quality view.
- The run list page shows all runs with their status — filter by release to compare runs within the same release cycle.
Generating a report
Once all cases have a status, navigate to Reports in the sidebar and select the run. Click Download PDF. The report includes:
- Executive summary — pass rate, total cases, environment, app version
- Detailed results — every case with its status, execution notes, and attached evidence
- Failure summary — all failed cases with links to the tickets created from them
- Assignee breakdown — per-person completion and pass rate
Best Practices
Start runs early
Don't wait until the end of a sprint. Kick off a smoke run the moment a feature lands in the staging environment.
Note every failure
A failed test without a note wastes developer time during triage. Always describe what went wrong, on which step, and in which environment.
Attach evidence at execution time
Screenshots and logs attached immediately are far more accurate than ones recalled later. Make it a habit during the run, not after.
Create tickets immediately
File the bug ticket the moment you mark a case as Failed — don't batch them up. Context fades fast, and delays extend fix cycles.
Use Retest deliberately
Mark cases as Retest only when a specific fix has been pushed. Don't use it as a placeholder — it signals to the team that verification is pending.
Review runs in retros
Walk through the run report at the sprint retrospective. Pass-rate trends over multiple sprints reveal whether quality is improving or eroding.