An obsolete checkout test can disappear from the active library while its failed execution still explains an earlier release decision. Archiving is useful when you need both outcomes. It becomes risky when the team assumes that folders, reporting and automated imports will behave exactly as they did before retirement.
This workflow applies to QMetry Test Management for Jira Cloud. The test-case archive operation belongs to that app, not to Jira's native work-item archive. Other test management apps and QMetry deployment editions need their own procedures. The steps below follow current vendor documentation; they are not results from an archive or import performed in a live tenant.
Retire a case because its behavior is obsolete or its coverage has been deliberately replaced. A case that is unnecessary for one release may still belong in the reusable library. Keeping it out of a release's scope is a different decision from making it inactive throughout the app.
Ask the coverage owner what changed and which current test, if any, covers the remaining risk. Record the exact case key and relevant version, retirement reason and owner. If the case was produced by automation, identify the job or result file that can emit it again. Archiving the library record does not remove that automated scenario from the test code.
The archive guide states that users need Test Case Edit permission. Confirm the app-level permission with the administrator rather than assuming that a Jira administrative role supplies it. Agree who will approve the retirement and who can restore the case if the product change is reversed.
QMetry archives all versions of a test case, and all existing folder associations are lost. You cannot use this operation to retire an old version while keeping another version of the same case active. Capture the original folder memberships before proceeding, especially when folders carry team or release context.
Keep a small retirement register with enough information for someone else to check the decision:
This is a proposed team record, not a QMetry feature or a guaranteed export format. Folder names describe placement; execution references explain what happened. Retaining both prevents a later reviewer from having to reconstruct the retirement decision from a case summary alone.
Archiving preserves some evidence while changing how the case can be found and used. Separate the effects before deciding that an archived case is safely out of the workflow.
Item | Documented Effect | Practical Response |
|---|---|---|
Case versions | All versions are archived | Check whether any version is still needed for active testing |
Folder memberships | Existing associations are lost | Record placement before the change |
Existing executions and attachments | Preserved by archiving | Inspect representative history afterward |
Execution screen | Archived cases are read-only | Do not expect to execute or add bugs and attachments |
Report visibility | Archived-case inclusion is configurable | Review the report's filters |
Read-only execution is not an immutable retention guarantee. QMetry still permits archived cases to be unlinked from a test cycle, and its archived-case view offers permanent deletion. Keep deletion outside a routine retirement task unless it has separate authorization. An archive operation alone does not establish a retention period or satisfy a legal preservation requirement.
Start with a limited, explicitly approved selection rather than treating a folder name as proof that every case inside it is obsolete. Folder contents and selection settings determine the actual scope.
For a single approved case, hover over it and use the Archive icon, or use the Archive icon on its details page. Confirm the exact key before acting.
For a bulk selection, follow the documented folder-based path:
These are app operations that change the test library. An administrator should first check a small authorized sample if the team's process or current UI is unfamiliar. That recommendation does not imply that a sample archive has already been executed.
To find archived cases, open the more icon above the folder tree and choose Show Archived Test Cases. Confirm that the intended keys appear there. Their absence from the active list is expected, but it is not sufficient evidence that their historical records remain usable.
Open a representative case and inspect the execution and attachment references recorded before retirement. On the execution screen, archived cases are read-only: they cannot be edited or executed, and bugs or attachments cannot be linked to them. The separate new-execution guide also says that archived cases cannot start new executions and are skipped in a bulk start operation. A skipped case should therefore not be treated as successful new testing.
For historical reporting, check Include Archived Test Cases in the report configuration. That setting differs from Include Archived Test Cycles/Executions, which controls archived-cycle executions. Also review whether the report uses the latest case version or all versions, and the last execution or all executions. Report View permission is required to generate reports for the relevant space.
Use the same intended report scope when checking before and after retirement. A missing row may reflect filters or permissions rather than deleted data. Investigate that difference before declaring the retirement complete.
An import can mean loading test-case definitions or loading execution results from automation. Those paths do not have interchangeable archive behavior. Identify which one your team is using before troubleshooting a missing case or a newly created record.
The archive guide says that a test-case import mapping the Key does not map archived keys. Those archived cases are skipped during import. Supplying the old key is therefore not a documented way to update or restore the archived record.
If an import appears to have omitted retired coverage, first check whether the supplied key belongs to an archived case. Decide whether that case should remain retired or be restored before attempting another import. Repeating a file without resolving its intended target leaves the same ambiguity in place.
The archive guide warns that importing a result file containing an automation-created case after it has been archived creates a new case. That can bring retired behavior back into the active library while leaving its earlier history on the archived record.
Current official guidance is not fully consistent. The Cloud Cucumber guide says that an invalid or archived test-case entity in result JSON can reuse an existing version when the executed steps and summary match, and otherwise create a new case. Its general matching rules also distinguish creating a case from creating a version. Do not assume every archived key produces a new ID, or that retaining the key guarantees reuse.
Review the framework, actual result-file identity, summary and steps with the automation owner. The REST import reference documents matchTestSteps and testCycleToReuse, so matching can depend on both step matching and cycle reuse. Changing a flag is not a documented archive protection switch.
If exact behavior is needed before retirement, ask an administrator to plan a controlled check in an authorized disposable context. Use a representative result payload and the actual importer settings, then inspect the affected case keys and versions. The import tracking reference distinguishes testCasesCreated, testCaseVersionsCreated and testCaseVersionsReused. Review those outcomes alongside the resulting records; an accepted upload alone does not establish that the intended identity was reused.
Do not use a production re-import as the experiment. If retired coverage should stay retired, agree with the automation owner how its results will be removed from the relevant input or redirected through an approved coverage change before routine uploads resume. If the behavior is still needed, reconsider retirement instead. Neither path requires guessing which matching rule will win or deleting apparent duplicates because their summaries match.
When the behavior becomes relevant again, locate the case with Show Archived Test Cases and use Unarchive. QMetry makes it active and allows you to select destination folders. Without a folder selection, the case moves to All Test Cases, the root folder.
Unarchive does not promise to rebuild the former folder structure. Consult the retirement register and the case's Audit Logs, where the archive guide says folder association details are displayed. Select the appropriate current folders rather than assuming that restoring the case also restores all of its old placement.
Before the case enters a new test run, review its steps and expected results against current requirements. Check whether automation or another import has already created an active record for the same behavior. A shared summary is not sufficient evidence that two records have the same versions, executions or purpose.
If there are multiple plausible targets, agree which identity future imports should use and retain the historical references while resolving the ambiguity. Restoration should not silently replace an earlier release's execution evidence with a current definition.
Consider a fictional team removing a legacy payment method. Its reusable checkout case has a failed execution with a diagnostic attachment from an earlier release. The team wants that evidence available but no longer wants testers selecting the obsolete path for current work.
The owner records the case key, folder memberships, retirement reason and representative historical execution. Before archiving, the automation owner checks whether a scheduled job still emits that payment scenario. If it does, the team resolves the job's intended coverage first; otherwise a later result import could create or reuse coverage according to importer-specific behavior.
After an approved archive, the reviewer locates the archived key, checks the old failure and attachment, and confirms that the historical report includes the intended archived records. If the payment method returns, the owner can unarchive the case, choose its folders and review whether the old steps remain valid. Any active lookalike is investigated before a new import is attempted.
Treat retirement as complete when the team can explain what was made inactive, where its history remains and what will happen to its automation inputs. If those answers are missing, a cleaner active list is not yet a controlled archive lifecycle.
A green automated test history can help a developer identify a safe-looking change while leaving a QA lead unable to answer a different question:…
A checkout test appears under Payments, again in a Smoke folder, and once more under the latest release. When the payment rules change, someone…
A Jira story is Done, a test case is linked, and the related bug is Closed. Can the release owner conclude that the story's…
Create traceable test cases, prepare release-specific test runs, and keep approved coverage current as the product changes.
