Test plans and test runs

Plan what to test, execute cases, file bugs from failures and sign off.

Test plans

A test plan describes what you'll test and how: scope and out-of-scope, objectives, strategy, phases, risks and exit criteria, plus the list of test cases. Create one from Test Plans → New plan. A plan can be linked to a requirement and a release, assigned to an owner, and sent for review. Runs started from a plan stay linked to it: the plan page lists them with their progress and pass rate, and a run started from a plan inherits the plan's release unless you pick another.

Draft cases can be added to a plan, but runs only include approved cases. sqale labels the draft ones "not in runs" so nothing is dropped silently.

Start a test run

Test Runs → New run. Choose what to include:

All approved cases in the project
A custom selection from your suites, with search and filters
A test plan's cases, or a requirement's cases

Optionally set an environment (staging, production…), an assignee, a due date and a release.

Execute

Open a run to execute it. For each case:

Open the case (click it, or press Enter on a focused row).
Record a result for each step and/or an overall result: Pass, Fail, Blocked or Skipped.
Add notes (they're saved when you close the drawer or move to the next case).
On a failure, choose File bug. It's pre-filled with the case, the steps and your notes, and linked to this execution.

Use Previous/Next to move through the cases in the order and filter you see on screen. Select several cases to set a result or assignee in bulk. Every result records who executed it and when. If a case is re-tested, the earlier attempts are kept. Each result also keeps the test case as it was run (title, preconditions and steps). If someone edits the case later, a completed run still shows what was actually tested, and an active run flags the case so you know to re-test it.

Progress and pass rate

The run shows progress (cases with a result ÷ total) and pass rate = passed ÷ (passed + failed + blocked). Skipped cases don't count either way. The same numbers appear on the run list, the closure report, share links, Slack messages, Insights and Reports.

Complete, reopen, retest

Complete run: available once every case has a result. A completed run is read-only.
Reopen run: if results need to change after completion.
Retest: creates a new run with only the failed and blocked cases, keeping the environment, release and assignees.

Closure report and sign-off

A completed run has a closure report: totals, pass rate against your target (entry criteria), the execution breakdown and the defects found. Once the run is completed, a team member can sign off. The sign-off is recorded under their account, and they or an admin can withdraw it. Reopening a run clears its sign-off, because its results can change again. Share a read-only link with stakeholders who don't have a sqale account.

Runs from CI

When CI results are uploaded, the matched test cases are recorded in a run marked CI (filter by Origin). These runs can't be reopened or edited, because their results come from your pipeline; deleting the CI run in Pipelines deletes them too. A CI run on a release's branch is linked to that release automatically.

Releases

A release groups the requirements you plan to ship. Pick them by hand, or (with Jira connected) from a Jira fix version or sprint: issues in it that are imported as requirements become the scope, and Sync from Jira keeps it up to date. Issues not imported yet are listed so you can import them. Requirements you add by hand are never removed by a sync. Its readiness counts only results from runs linked to the release: manual runs you assign to it, and CI runs on its branch. A run on another branch doesn't move the score. The release page shows that evidence: the linked runs, open critical and high bugs on its requirements, and the latest CI on its branch.

Mark as released is a sign-off by a project admin. sqale shows what isn't ready first; if anything isn't (a requirement not Ready, an open critical or high bug, a run still in progress), the admin records why it ships anyway. The release keeps who released it, when, its readiness at that moment and the note. Releasing locks the scope. Reopening, also admin only, unlocks it and clears the sign-off. A released release can't be deleted until it's reopened.