Zephyr Scale
How we manage tests: the standard and the practice
The test case lifecycle, automation tracking, traceability, cycles and plans, followed by ten step-by-step how-tos with screenshots.
What this standard is about
One set of rules for managing test assets in Zephyr Scale across all projects.
What it covers
- the test case lifecycle;
- automation status tracking;
- traceability: Jira linking;
- test cycles;
- test plans.
Project Profile
Project-specific details live on each project's Project Profile page: naming conventions, folder structure, environments, dashboards.
They must comply with this standard.
Who it is for
QA engineers, QA leads, and anyone creating, reviewing, or executing tests in Zephyr Scale.
Presentation map
The standard first, chapter by chapter, then the practice. Click any item to jump to it.
One chain behind full visibility
Traceability is the core reason this standard exists. Every link connects to the next one.
Requirement
A Jira issue: Story, Task or RequirementTest
A test case in Approved statusCycle
Story, Smoke, Regression or HotfixExecution
Pass, Fail or Blocked, with evidenceDefect
A bug raised from the executionCoverage reporting
Which requirements have no tests.
Progress on the issue
Testing progress shows directly on the Jira issue.
Release readiness
Which requirements have failing tests.
Audit
Answers to audit questions without manual archaeology.
Seven test case statuses
The case is being written. Not ready for review; must not be executed in formal cycles.
The author considers the case complete and submits it for review.
The case has been reviewed and accepted. Eligible for inclusion in test cycles.
Review or authoring is blocked by an open question about requirements. A comment must state the question and who it is addressed to (BA, PO, dev).
Origin or relevance is unclear: migrated from a legacy suite, inherited from another team, or simply old enough that it must be verified. A decision is pending: update, approve, or deprecate.
Valid in principle but outdated due to functionality changes. Must not be executed until updated and re-approved.
No longer relevant. Kept for history; must never be executed. Do not delete test cases: deprecate them to preserve execution history.
How a case moves between statuses
When each transition is allowed
Draft
- Pending ReviewThe author considers the case complete and submits it for review.
- Requirement ClarificationWhile writing, the author is blocked by unclear or ambiguous requirements.
- DeprecatedThe case turned out to be unnecessary before it was ever approved.
Pending Review
- ApprovedThe reviewer accepts the case.
- DraftThe reviewer requests changes. A comment describing them is mandatory.
- Requirement ClarificationThe reviewer finds an ambiguity or inaccuracy in the requirements.
Requirement Clarification
- DraftThe question is answered; the case needs rework.
- Pending ReviewThe question is answered and the case needs no changes: it goes straight back to review.
- DeprecatedThe clarification shows the case is not needed.
Approved
- To Be UpdatedFunctionality changed; the case is outdated and must not be executed until reworked.
- DeprecatedThe functionality is removed or the case is no longer relevant.
To Be Updated
- DraftThe author starts reworking the case; it then follows the normal flow: Draft, Pending Review, Approved.
- DeprecatedThe rework is pointless: the case is no longer needed.
To Triage
- From any status to To TriageA case needs re-evaluation: unclear origin, possibly outdated, or inherited from another team.
- From To Triage to Draft, Pending Review, Approved, To Be Updated or DeprecatedTriage decision: rework it, send it to review, confirm it as still valid, mark it as needing an update, or retire it.
Test case versioning
Version control is enabled by default in Zephyr Scale. A new version is created manually: editing a test case changes the current version and does not spawn a new one. You create a new version deliberately, when you want to preserve the current one before making changes.
- How to create a new version
- Open the test case and click the + icon in the top-right corner, next to the version number.
- Confirm. A new version (e.g. 2.0) is created as a copy of the current one.
- Edit the fields or steps; changes autosave.
- Use the version dropdown next to the version number to switch between versions. The History tab shows and compares versions side by side.
By default, all lists, searches and cycles use the latest version.
When to version, and what happens to executions
When to create one
Before a behavioural change to an Approved case (steps, expected results, test data) that you want tracked as a distinct version, typically when the functionality changed and the old version should stay on record.
The new version goes back through review: Draft, Pending Review, Approved.
For a minor non-behavioural fix (typo, label) just edit the current version. Versioning is a deliberate choice, not automatic bookkeeping.
Versions and executions
- An execution is tied to the specific version that was run. Editing the case later does not change past executions, so the results history is preserved.
- If a case is changed after an execution used it, the Test Player shows a notice that the script is outdated, with the option to sync to the updated steps. Syncing is a deliberate action, not automatic.
- You can still edit older versions, but you cannot create a new version from an older one: new versions always branch from the current.
Rules
- Do not delete and recreate a case to "reset" it: that destroys history. Edit it, and create a new version when you need to keep the old one.
- When an automated script targets a specific version, reflect a later behavioural edit with Automation Status To Be Updated, so the drift is visible.
- The latest Approved version is the one added to new cycles.
Execution time estimate
Each test case has an Estimated Time field: how long one execution of the case is expected to take.
How to set it
- Enter a realistic, approximate value based on how long the case actually takes to run manually. Not an ideal or a padded number.
- Approximate is fine: the goal is planning, not precision. A case that takes about 5 minutes is recorded as 5 minutes; do not agonise over seconds.
- Set it when the case is written and adjust it if execution consistently takes noticeably longer or shorter.
Why it exists
The estimates of the cases in a cycle add up to an expected duration for that cycle. This makes planning possible: how long a regression will take, how many testers are needed to finish by a date, whether the scope fits the time available.
Illustration of the summing; the numbers are made up.
Why honesty matters
A number that is too optimistic makes every plan built on it wrong. A padded number wastes capacity.
Approximate but real is exactly the right target.
Review rules
Who reviews
A test case must be reviewed and approved by any reviewer other than its author. Self-approval is not allowed.
What is checked
- presence of a requirement link;
- mandatory fields;
- clarity of steps;
- specificity of expected results.
Review outcome
- A transition to Approved.
- Or a comment with requested changes and a transition back to Draft.
- If the blocker is on the requirements side: Requirement Clarification.
The full reviewer checklist is in the practice part, on the slide "Review: blocking checks".
Automation is tracked with two independent fields
Automation Status is the lifecycle of the automated script: does it exist, and in what state of development is it? Flaky is a checkbox marking an existing script as unstable. They are separate because flakiness is a property of a script that already exists. A flaky test is still counted as automated, so automation coverage metrics stay accurate.
Selected for automation but work has not started. Prioritized by the QA Lead together with the automation engineer(s).
An automated script is being developed for this case.
An automated script exists, runs in the pipeline, and reports results. Manual execution is not required in regression unless explicitly stated in the test plan.
The test case has changed (updated requirements, reworked steps) and the automated script has not been updated yet. The case is executed manually until the script catches up.
The case will not be automated: exploratory, one-off, requires physical interaction, cost outweighs value. A short justification in the case is recommended.
The automated script has been retired, usually together with the test case deprecation.
The Flaky flag: an unstable script
The flag is set when an existing automated script produces unstable results: passing and failing on the same build without a change in the product.
- Someone observes unstable results and sets the Flaky checkbox.
- A task for stabilizing the script is linked to the test case.
- The script is stabilized and confirmed stable across runs.
- The automation engineer clears the flag.
Limits
- Applies only to cases with Automation Status Automated or To Be Updated.
- A flaky script's automated result is not trusted: the case is executed manually in regression until the flag is cleared.
Who sets what
Ownership follows the meaning of the value, not the role of the person.
| Value or field | Set by |
|---|---|
| Candidate | Manual QA or QA Lead: whoever identifies the case as worth automating. Prioritization is agreed with the automation engineer. |
| To Be Updated | Anyone who changes the test case, typically the manual QA who reworked it, signalling that the script is now out of sync. |
| In Progress Automated Deprecated | The automation engineer: these reflect the state of the script itself. |
| Not Applicable | Manual QA or QA Lead, with a short justification. |
| Flaky | Anyone who observes unstable results: manual QA, automation engineer, or QA Lead. Cleared by the automation engineer after stabilization. |
Other rules
- Fields are updated at the moment the state changes: when a script is merged, when a test case is reworked, when instability is observed. Not in periodic batches.
- When a test case moves to lifecycle status To Be Updated or Deprecated, its Automation Status must be reviewed in the same change.
Regression: who executes what
A regression cycle contains the full scope defined in the test plan, automated and manual cases alike, so the cycle reflects everything the regression covered. Execution is split by responsibility.
Automation engineer
Automation Status Automated and the Flaky flag is not set.
Runs the suite and records the results in the cycle.
Manually
Candidate In Progress Not Applicable To Be Updated and any case with the Flaky flag.
An outdated script verifies the wrong behaviour and a flaky one produces results that cannot be trusted, so their automated results are not used.
Required fields
A test case cannot be moved to Approved until all of them are filled in correctly.
| Field | Rule |
|---|---|
| Name | Follows the naming convention defined in the Project Profile. States the verified behavior, not the feature name: "User cannot submit the form with an empty email", not "Email field". |
| Objective | One or two sentences: what this test verifies and why it exists. |
| Precondition | Required state before step 1: test data, environment, user role. Write None explicitly if there is none. Do not leave it blank. |
| Priority | High core business flow or a check whose failure blocks the release; always included in regression. Normal standard functional coverage; included in full regression, may be skipped in a reduced scope. Low edge cases and cosmetic checks; executed when time allows. |
| Folder | The case is placed in the correct folder per the project's folder structure (Project Profile). |
| Steps | Each step has an action and an expected result. Test data goes into the Test Data column, not into the action text. |
| Requirement link | Mandatory for Approved status (see the traceability chapter). |
Optional but recommended: Labels (per the project's label taxonomy) and Component.
How completion is enforced
Zephyr Scale allows the Required flag only on custom fields. System fields such as Objective, Precondition, Priority and Folder cannot be made technically mandatory, so enforcement happens at review.
Today: review
- The reviewer verifies all mandatory fields before approving.
- A case with missing fields is returned to Draft with a comment.
- A case is never approved "on the understanding that it will be filled in later".
- The review checklist is the operational form of this rule.
Until an automated check exists, review is the only control.
Planned
A scheduled API check that reports Approved test cases with empty mandatory fields, so gaps that slip through review are caught automatically.
Three mandatory links
Rule 1. Test case → requirement
Every test case must be linked to at least one Jira issue representing the requirement it covers: Story, Task, or Requirement issue type (per Project Profile).
The link is created via Traceability → Coverage (Issues) in the test case.
A test case without a requirement link must not be Approved. This is a review gate.
Exception: purely technical or infrastructure checks may be linked to a standing "umbrella" task defined in the Project Profile instead of a specific story.
Rule 2. Failed execution → bug
Every execution with status Failed must have one of two things:
- a linked defect, created directly from the execution screen so the link is established automatically;
- a comment explaining why no defect was raised: a duplicate of an existing bug (link it) or an environment issue (mark it Blocked instead).
A Failed execution with no linked bug and no comment is considered an incomplete execution.
Rule 3. Test cycle → Jira issue
Every test cycle is linked to the Jira issue that the testing effort belongs to.
Details on the next slide.
Rule 3: what to link a cycle to
| Cycle type | Linked issue |
|---|---|
| Story | The story being tested. |
| Regression | The regression task or ticket for that release. |
| Smoke | The deployment or release ticket, or the regression task it precedes. |
| Hotfix | The hotfix issue. |
Where the link is created
On the test cycle, in the Jira issues field, or from the issue's Traceability section.
The effect
The Zephyr panel on the issue shows the execution progress of the linked cycle: how many cases are executed, passed, and failed. Testing status is visible to PM, BA, and developers without opening Zephyr.
Together the three links produce the chain Requirement → Test → Cycle → Execution → Defect. It enables coverage reporting, testing progress on the issue, release readiness assessment, and audit answers without manual archaeology.
A test cycle is a container for execution
A cycle is a container for executing a defined set of test cases with a specific purpose. All formal test execution happens inside cycles: ad-hoc execution outside a cycle leaves no trackable result.
| Type | Created when | Content |
|---|---|---|
| Story | A story reaches testing. | Test cases covering the story (linked via Coverage). One cycle per story. |
| Smoke | After a deployment to a test or stage environment. | The smoke suite: High-priority core checks. |
| Regression | Before a release. | The full regression scope per the test plan: High priority always, Normal for full regression. Automated and manual cases are both included; execution is split by ownership. |
| Hotfix | A hotfix is deployed. | Smoke suite plus test cases covering the fixed area. Structurally the same as Smoke, but named Hotfix for traceability to the fix. |
Every cycle is linked to its corresponding Jira issue at creation time, so execution progress is visible on the issue itself.
How to name cycles
Rule of thumb: the name alone should answer what was tested, where and against what, and when.
| Cycle | Example | Meaning |
|---|---|---|
| Story | Story_ABC-1234 | The Jira issue key is the scope; no date needed. |
| Smoke | Smoke_stage_TT-v1-1-0 | Smoke on stage for version TT-v1-1-0. |
| Regression | Regression_TT-v1-1-0 | Regression of release TT-v1-1-0. |
| Hotfix | Hotfix_SDACD-129_TT-v1-1-0 | Hotfix for issue SDACD-129 in version TT-v1-1-0. |
Cycle statuses
The cycle is created and populated; execution has not started.
At least one execution has started.
Every execution has reached a final result (Pass, Fail or Blocked).
When a cycle can be closed
- every execution has a final result: Pass, Fail or Blocked;
- failed executions have linked defects;
- the results have been reviewed by the QA Lead.
A cycle is not Done while any execution remains Not Executed or In Progress.
Execution statuses
| Status | Use when | Required with it |
|---|---|---|
| Not Executed | Default: the case has not been started. | — |
| In Progress | Execution started but not finished (e.g., a multi-step scenario paused). | — |
| Pass | All steps produced the expected results. | Evidence at key checkpoints. |
| Fail | An actual result differs from the expected result. | Evidence and a linked defect (or a comment explaining why none was raised). |
| Blocked | The case cannot be executed for a reason external to the case itself: environment down, blocking defect in a preceding flow, missing test data. | A comment naming the blocker plus a link to the blocking issue where one exists. |
Fail
The test ran and the product behaved incorrectly.
Blocked
The test could not run. A case that fails on step 1 because the application does not open is Blocked by an environment or deployment issue, not Failed, unless opening the application is itself what the case verifies.
Execution evidence
Screenshots, response payloads and log fragments are attached directly to the execution.
Fail and Blocked
Evidence is attached in all cases: the state at the failure point, plus relevant logs or API responses where applicable.
Pass
Evidence is attached at the key checkpoints of the scenario, e.g. the final state of the created entity or the confirmation screen.
This demonstrates the test was genuinely executed and gives reviewers and auditors something to verify against.
Where it lives
Evidence stays on the execution, not in the linked bug alone. The execution record is the primary trace.
A test plan groups the cycles of a release
Plans answer the question "what does 'tested' mean for this release?"; cycles answer "what was executed". One test plan per release. Hotfix testing may be covered by a lightweight plan or attached to the release plan it patches.
Objective
The release or version under test.
Scope
What is included (features, regression depth: full or reduced) and what is explicitly out of scope.
Linked cycles
The Story, Smoke and Regression cycles. Linked as they are created.
Entry criteria
E.g. build deployed to the test environment, smoke passed.
Exit criteria
E.g. all cycles Done, no open High-priority defects, all Failed executions have linked defects with a triage decision.
Plan statuses, name and completion
Test plans use the default Zephyr Scale statuses. A plan's status reflects where the whole testing effort for a release stands, not the result of any single cycle.
| Status | Meaning |
|---|---|
| Draft | The plan is being prepared: scope, criteria and cycles are still being defined. Testing has not formally started under this plan. |
| In Progress | Testing is underway. Linked cycles are being executed. |
| Done | All linked cycles are complete, exit criteria have been checked, and the release-readiness decision has been recorded. |
Plan name
TestPlan_<JIRA_Fix_Version>
For example: TestPlan_TT-v1-1-0
Completion
A plan is complete when all linked cycles are Done and the exit criteria are met. The QA Lead records the outcome (met, or met with deviations) in the plan description or a linked Confluence page.
A plan moves to Done only after every linked cycle is Done and the exit criteria have been verified, not when the last test happens to pass.
Built-in Zephyr Scale reports
Reporting is built on two layers: built-in Zephyr Scale reports (on-demand analysis) and Jira dashboards (always-on visibility). Reports are found in the project under Zephyr Scale (Tests) → Reports.
| Report | What it answers | When to use |
|---|---|---|
| Coverage report (Issues) | Which requirements have test cases linked, and what their execution status is. Uncovered issues are visible immediately. | Before regression or release: verify nothing in scope is uncovered. |
| Traceability report (Issues) | The full chain per requirement: requirement → test cases → executions → defects. | Release readiness review; audit requests. |
| Traceability report (Test Cases) | The same chain viewed from the test case side. | Test case reviews, cleanup, triage of legacy suites. |
| Test Execution Results | Execution outcomes aggregated by cycle. | Daily progress tracking during a test run. |
These reports rely entirely on the links defined in the traceability chapter: coverage and traceability are only as accurate as the linking discipline.
Jira dashboards and audience
Regression dashboard Exists
A Test Execution Results table by regression cycle, plus per-run charts. One row per cycle within the release regression.
Sprint dashboard Planned
The same structure filtered to the sprint's Story cycles, so story-testing progress is visible during the sprint, not only at regression time.
Dashboard naming and links are recorded in the Project Profile.
QA
Daily during active test runs: progress and failures needing triage.
PM
Regression and sprint dashboards. Release readiness is discussed against the exit criteria of the test plan.
Client (future)
A curated read-only dashboard can be shared once the process is stable. The same data, no additional reporting work.
Common mistakes
| Mistake | Why it hurts | Correct approach |
|---|---|---|
| Approving a test case without a requirement link | Coverage and traceability reports show false gaps; audit questions have no fast answer. | The link is a review gate: no link, no Approved. |
| Marking a case Fail when the environment is down | Fail statistics get polluted; real product defects are diluted. | That is Blocked, with a comment and a link to the blocker. |
| A Failed execution with no bug and no comment | The failure is untraceable and will be re-discovered from scratch. | Raise the defect from the execution, or comment why not. |
| Executing tests outside a cycle | No record, no metrics, no evidence trail. | All formal execution happens in cycles. |
Common mistakes, continued
| Mistake | Why it hurts | Correct approach |
|---|---|---|
| Creating a cycle without linking it to a Jira issue | Testing progress is invisible on the story or task; PM and devs have to ask for status. | Link the cycle at creation time. |
| Deleting outdated test cases | Execution history is lost. | Deprecate, never delete. |
| Trusting automated results for outdated or flaky scripts | An outdated script verifies the wrong behaviour; a flaky one gives results that mean nothing. | To Be Updated and flagged-flaky cases are executed manually, even though a script exists. |
| Marking a cycle Done with Not Executed items inside | "Done" stops meaning anything. | Done = every execution final, fails have defects, and results reviewed. |
In practice: ten how-tos
Each guide follows the way you actually work in Zephyr: steps on the left, screenshots on the right. Click a step to see its screenshot. The ↑ ↓ keys move between steps, and clicking a screenshot enlarges it.
Create a test case and submit it for review
- Open the project → Zephyr Scale (Tests) → Test Cases.
- Navigate to the correct folder (see the folder structure in the Project Profile) and click New Test Case.
- Fill in the required fields: Name per the naming convention, Objective, Precondition (write
Noneif there is none), Priority. - On the Test Script tab, add steps: one action per step, an expected result for every step, and test data in the Test Data column.
- On the Traceability tab, link the requirement: Issues → Add existing issue. Enter the Story or Task key in the search field, click the search button, tick the checkbox next to the right issue, and click Add.
- Set the Automation Status field: usually Candidate or Not Applicable for a new case.
- Change Status from Draft to Pending Review and notify the reviewer, per the project's review routine.
The original how-to calls the last status "Ready", while the Standard's text calls it "Pending Review". This deck uses the Standard's name.
Review: blocking checks
Open the test case in Pending Review status and work through the checklist in order. The order matters: the first two blocks are blocking issues that make the case unusable, the rest are quality improvements. Click an item to tick it off.
1. Traceability
- A requirement link exists on the Traceability tab. No link, no approval.
- The linked issue is the right one: it actually describes the behaviour this case verifies.
2. Mandatory fields
- Name, Objective, Precondition, Priority, Folder and Steps are all filled.
- Precondition says
Noneexplicitly rather than being left empty. - Priority matches the criteria in the Standard, not "High" by default.
Review: quality of the case
3. Correctness of the test
- Every step has an expected result, and it is specific: "the order appears in the list with status Paid", not "everything works".
- The steps actually verify what the Objective claims.
- Preconditions are sufficient: a tester who has never seen this feature could reach step 1 from them.
4. Reproducibility
- Test data is in the Test Data column, not buried in the step text.
- No dependency on a specific person's account, machine, or leftover data from another test, unless stated in the precondition.
- The case can be run independently of other cases.
5. Maintainability
- One case verifies one thing. If it covers several unrelated checks, suggest splitting it.
- No duplication of an existing case: search the folder before approving.
- Repeated step sequences use shared steps (Call to Test) rather than being copy-pasted.
How a review ends
Everything checks out
Set Status to Approved.
The author cannot approve their own case.
Changes needed
Leave a comment listing them concretely and move the case to Draft.
Blocked by unclear requirements
Move the case to Requirement Clarification and address the question to the BA or PO in a comment.
Reuse steps from another test case
Instead of copy-pasting the same sequence of steps into many test cases, insert one test case as a step into another. The inserted case is executed as part of the calling one, and a change in the shared steps propagates everywhere it is used. Typical uses: logging in, creating a test account, seeding an order.
- Open the test case and go to the Test Script tab.
- Hover over the step after which the reused sequence should appear. A toolbar of icons appears on the right of the step.
- Click the curved-arrow icon (Add "Call to test" step below). A new step of type Call to test is added underneath.
- In the new step, search for the test case you want to reuse and select it.
- Save. The step now shows a reference to the selected test case instead of duplicated step text.
- During execution, the steps of the inserted case appear inline and are marked Pass or Fail like any other step.
Shared steps: when, and how carefully
When to use it
- The same sequence appears in three or more test cases.
- The sequence is a prerequisite rather than the thing being verified, for example logging in before testing the cart.
When not to use it
- The reused sequence is what the case verifies: a login test must contain its own steps, not insert them from elsewhere.
- The repetition occurs in only two cases: the indirection costs more than the duplication saves.
- Deep nesting (a case inserting a case that inserts another) is hard to read and to debug. Keep nesting to one level.
Rules
- An inserted case must be in Approved status. Depending on unreviewed steps makes the calling case unreliable.
- Before editing a shared case, check where it is used: the Traceability tab of that case shows which cases insert it. A careless edit affects every one of them.
- A shared case that is no longer used anywhere is deprecated like any other case.
Use a dataset for data-driven testing
Instead of hardcoding input values into each test step, create a reusable list of values (a Dataset) once and reference it from multiple test cases. This supports Data-Driven Testing: the same script runs once per row of data instead of being copied for every input variant. Typical uses: a set of test user accounts, a list of page names, supported currency codes.
- How to create a dataset
- Open Configuration → General → Datasets.
- Enter a name and click Add. The dataset appears in the list.
- Open the dataset and click Add an option to add a value; repeat for every value you need.
- How to attach a dataset to a test case
- Open the test case → Test Script tab.
- Enable the Test Data toggle at the top of the test data table.
- Click Add column and select the dataset as the column's source. Its options populate the table.
- In each step, reference the column: type
{and pick the variable from the dropdown. - On execution, Zephyr runs the steps once per row of the test data table, substituting the row's values into every placeholder.
Datasets: when, and what the limits are
When to use it
- The same list of values is reused across three or more test cases, e.g. the same set of test users.
- The values need central maintenance: update the dataset once instead of editing test data in every case that uses it.
When not to use it
- Only one or two rows of data are needed: plain Test Data or Custom Input entered directly in the case is simpler.
- The data has several related columns (username, password and role that belong together). A dataset is a single list of values, not a multi-column table. Either create one dataset per column, or use Custom Input.
Rules
- A dataset is scoped to its space. A test case in another space cannot reference it; recreate the dataset there if needed.
- There is no bulk import from Excel or CSV. Options are added one at a time (Add an option).
- Before editing a shared dataset, consider which test cases reference it: a change to its options affects every case that uses that column.
Execute a test case and raise a bug
- Open the execution, in any of three ways
- Open the Test Cycle → Test cases tab → click the test case → Execution tab.
- Or: Test Cases → click the test case → Execution tab.
- Or use the test player: open the Test Cycle and click the ▶ button on the row of the test case you want to execute.
- Execute and record the result
- Go through the steps, marking each step Pass or Fail as you verify it.
- Attach evidence at key checkpoints (screenshots, API responses) directly to the execution, even for a passing run.
- If a step fails: set the step and the execution to Fail, attach evidence of the failure, then click Create new issue (bug) directly from the execution. The defect link is created automatically. Or create a bug separately in Jira and use Add existing issue.
- If the case cannot be run at all (environment down, blocking defect, missing data): set Blocked and add a comment naming the blocker with a link to the blocking issue.
- Finish with a final status. Add an execution comment if anything needs context for the reviewer.
Build a regression cycle
- Open Test Cycles → New Test Cycle.
- Name it per the convention:
Regression_<JIRA_Fix_Version>, e.g.Regression_TT-v1-1-0. - Fill in Version (the release under test) and Environment, and link the cycle to the regression task for this release in the Jira issues field.
- Add test cases: Add Test Cases → filter by folder and/or Priority = High (plus Normal for full regression).
- Assign executions by ownership: cases with Automation Status Automated and no Flaky flag go to the automation engineer, who runs the suite and records results in the cycle. Everything else, including To Be Updated and flaky cases, is assigned to manual testers.
- Link the cycle to the release test plan (the next guide).
Create a test plan and link cycles
- Go to Test Plans → New Test Plan and name it
TestPlan_<JIRA_Fix_Version>. - In the description, state the objective (release or version), scope (in and out), entry criteria and exit criteria.
- Link cycles as they are created: open the plan → Test Cycles → add the Story, Smoke and Regression cycles of this release.
- On release completion, the QA Lead verifies the exit criteria and records the outcome in the plan.
A starter for the plan description. Copy it and fill it in.
Find uncovered requirements
- Go to Zephyr Scale (Tests) → Reports → Coverage report.
- Set the filter to the scope you care about, e.g. a JQL for the release's stories, or Fix Version.
- Issues with no linked test cases appear as uncovered. These are gaps to close before regression.
Update Automation Status
- Open the test case → the Automation Status custom field.
- Set the value that reflects reality now: script merged and running → Automated; test case changed and the script has not caught up → To Be Updated.
- If the script is unstable, tick the Flaky checkbox and link a stabilization task. Clear it once the script runs reliably again.
- Update at the moment the state changes, not in periodic batches.
Ownership
Manual QA: Candidate To Be Updated Not Applicable
Automation engineer: In Progress Automated Deprecated
Either can raise the Flaky flag.
Copy a link to a folder
You can copy a direct link to a folder (of test cases or of cycles) to share it or to reference it from Confluence, a Jira ticket, or a message.
- In the Test Cases (or Test Cycles) view, find the folder in the folder tree on the left.
- Open the folder's action menu: right-click the folder, or use the "⋯" / context menu next to its name, depending on your version.
- Choose the option to copy the link (e.g. Copy folder link), or open the folder and copy the URL from the browser address bar. It points to that folder's contents.
- Paste the link where needed. Anyone with access to the project opens the same folder directly.
Use folder links in the Project Profile and in How-To pages so readers land on the exact folder rather than searching the tree. A link to a filtered view (e.g. by label or component) can be shared the same way: copy the URL after applying the filter.
Cheat sheet
- Only Approved cases go into cycles.
- No requirement link, no Approved.
- The author never approves their own case.
- Never delete: move to Deprecated.
- Fail: the test ran and the product misbehaved. Blocked: the test could not run.
- A Failed execution with no bug and no comment is incomplete.
- Name cycles by the pattern and link them to a Jira issue at creation.
- Done only when every execution is final, fails have defects, and the QA Lead has reviewed.
- Update Automation Status at the moment of change. To Be Updated and Flaky cases run manually.
- Close a plan only after the exit criteria are verified.
| Naming | |
|---|---|
| Story | Story_<KEY> |
| Smoke | Smoke_<env>_<JIRA_Fix_Version> |
| Regression | Regression_<JIRA_Fix_Version> |
| Hotfix | Hotfix_<KEY>_<JIRA_Fix_Version> |
| Test plan | TestPlan_<JIRA_Fix_Version> |
Requirement → Test → Cycle → Execution → Defect
The chain that all testing visibility rests on. Project-specific details live in the Project Profile.