An address-change regression cycle can contain plausible address tests and still omit the locked-account check or the audit event required by release policy. A recommendation list helps locate candidates, but the release objective and mandatory obligations determine which cases belong.
QMetry Test Management for Jira Cloud provides Design Test Cycles with QI for this task. QMetry Intelligence analyzes an execution objective and recommends existing cases from the space library. The useful output is a reviewed collection that a person chooses to link to a test cycle. A recommendation is neither evidence that the application passed nor proof that the selected scope is complete.
This workflow belongs to the QMetry app, not native Jira or Rovo. It concerns selecting reusable cases for a cycle. Generating new tests, analyzing changed code and deciding execution order are separate activities; do not infer those capabilities from a relevant-looking list.
Start with an administrator check. The current Cloud guide says the feature is disabled by default. Its global configuration route is Settings, Marketplace Apps, Global Settings under QMetry, then AI Configuration. Jira Admin is the documented permission for that configuration. The default delegation option lets project administrators decide whether to enable it for their spaces.
For space-level configuration, the guide names Enable/Disable Design Test Cycle With QI under Space Settings, Apps, QMetry Space Settings, Space Permissions. That permission is automatically enabled for users or groups with Configuration Modify rights. Treat this as an enablement permission, not a complete statement of every permission needed to create or edit a cycle.
Automatic enablement covers existing QMetry-enabled spaces; newly created or enabled spaces still require explicit enablement. Activation can take time, so confirm its Completed state rather than assuming a setting change made the feature immediately usable. Have the administrator verify availability, applicable entitlement and organizational approval in your instance before real use. Historical release notes record the feature as Cloud beta in 4.13.1 and AI features as generally available in 4.14.2; neither entry verifies your current configuration.
Before entering a real execution objective, review the organization's approved AI-use and data-handling requirements with the administrator. Do not paste private requirements merely because a prompt box is available. This tutorial describes the documented route; it does not require changing configuration or submitting production data to try the example.
Assign a QA reviewer to approve membership, case owners to resolve missing or obsolete coverage, and a cycle owner to apply approved changes. These are recommended team responsibilities, not additional QMetry roles or a documented approval workflow.
Write down the release behavior before writing the prompt. Identify the requirements, mandatory regression policy, exclusions and intended library space. This gives the reviewer an independent reference for omissions. Starting with the recommendations and declaring their contents to be the scope would hide the cases the search failed to surface.
The guide specifies an execution objective between 20 and 500 characters. It recommends separate sentences for semantic intent and field-based filters, exact field names, and valid values enclosed in single or double quotes. Its supported-field table includes Labels, Component, Priority, Status and Test Case Key, among other case and execution fields.
A filter narrows the population under consideration. If a mandatory audit case has the Compliance label rather than Regression, a Regression filter can exclude it even when its business behavior is relevant. Check the actual metadata before deciding that a missing case is irrelevant.
For combined conditions, the guide describes “and” as intersection and “or” as union. Review whether you meant both values or either value, and inspect the retrieved cases to confirm that the result matches that intent. Natural-language instructions are not a substitute for checking the population they produced.
QI searches existing case text for the objective. The guide discusses summaries, descriptions and step text; it does not establish a changed-code dependency map. A terse or outdated library case may therefore need investigation when it is absent. Its absence alone does not prove that the underlying behavior is unaffected by a release.
For a new cycle, the documented route starts in the Test Cycle module:
Read case content, not only its summary. Confirm the preconditions, steps and expected outcome match the current requirement. A similar title can describe an old screen, a different account type or a related operation outside the release boundary.
The guide documents limits of 1,000 retrieved cases on screen and 1,000 cases in the collection. Treat those as workflow bounds, not evidence that a returned set exhausts every relevant case. Reconcile the collection against your scope record even when the list is short.
The following packet, ADDRESS-CYCLE-1.0, is fictional and unexecuted. Its cases are an invented existing library catalogue, not newly generated tests. No objective was submitted to QI, and no recommendation quality, model response or application result was observed.
The fictional requirements document ADDRESS-REQ-1.0 defines R1 as persistence of a saved domestic address after a new login, R2 as rejection of an invalid domestic postcode, and R3 as preventing a locked account from changing its address. Policy P1 requires audit-event evidence for this change. Exclusion X1 removes marketing address export from the release scope; X2 removes the retired address form.
Assume the reviewer selects the Customer Accounts space and prepares this objective:
Show all test cases related to customer address changes and domestic postcode validation. Filter test cases where Labels are "Regression".
For the review exercise, suppose the candidate subset is ADR-101, ADR-102 and ADR-105. This subset is authored for explanation, not actual QI output or a prediction of its ranking. The table records the decisions the fictional requirements and policy imply, independently of that subset.
Existing Case | Library Metadata | Scope Evidence | Reviewer Decision |
|---|---|---|---|
ADR-101: Save a domestic address | Active; Regression | R1: Persist the saved address after a new login | Include for R1 |
ADR-102: Reject an invalid postcode | Active; Regression | R2: Reject an invalid domestic postcode | Include for R2 |
ADR-103: Deny a locked account | Active; Regression | R3: Prevent a locked account from changing its address | Retrieve explicitly and include for R3 |
ADR-104: Record an address-change audit event | Active; Compliance | P1: Audit evidence is mandatory for this change | Retrieve without the Regression filter and include |
ADR-105: Export marketing addresses | Active; Regression | X1: Marketing export is outside this release scope | Exclude despite address-related wording |
ADR-106: Validate the retired address form | Archived; Regression | X2: The retired form is outside this release scope | Exclude; do not revive an obsolete case |
ADR-103 and ADR-104 require different investigations. ADR-103 is inside the assumed Regression-labelled population but absent from the teaching subset. Look it up explicitly and read its contents against R3. ADR-104 is excluded by the proposed label filter, so remove that restriction for its retrieval and verify its audit expectations against P1. Neither omission authorizes dropping the obligation.
The guide supports modifying the objective to add more cases to the collection and lists Test Case Key as a supported filter field. Use the known case identity to investigate a mandatory case rather than repeatedly broadening the semantic wording. Confirm the retrieved identity and content before adding it; do not assume a specific natural-language phrasing is guaranteed to return it.
Under this fictional packet, the reviewer-approved membership would be ADR-101, ADR-102, ADR-103 and ADR-104. ADR-105 remains out of scope despite its address terminology. ADR-106 is an obsolete, out-of-scope case, not a convenient replacement for missing current coverage. This is a scope decision, not an execution-order ranking or a measured recall result.
If a required behavior has no usable existing case, record a coverage gap and assign a case owner to resolve it. Retrieving existing cases cannot establish coverage for a missing test. Keep membership approval pending until the obligation is covered or an authorized scope exception is recorded.
After selecting candidates, choose Next to enter Review Collection. The documented stage allows manual reordering, auto-sort and removal, including individual and bulk unlink controls within the collection. The presence of sorting controls does not establish that the displayed sequence is the best execution order for your release.
Perform a membership review before using those ordering options. Check that each included case has a requirement or policy reason, each mandatory obligation has a usable case, and exclusions have a recorded rationale. Read the selected case contents for obsolete assumptions and duplicates. A missing mandatory case is a reason to continue investigation, not to approve the list because most entries look sensible.
Removing a proposed item from a collection should not be treated as interchangeable with unlinking a previously executed case from an existing cycle. The latter has execution-history consequences. Keep proposed membership review and changes to historical cycle records distinct.
For the new-cycle route, choose Next after reviewing the collection, enter the cycle Summary, Description and other required fields, then choose Create. The guide describes a success message with the cycle key. Verify the actual linked cases afterward rather than treating the collection view or the button click as the final membership record.
For an existing cycle, start on its Test Cases tab and choose Recommend Test Cases. The Identify Test Cases screen accepts the objective. Select recommendations, choose Add to Collection, proceed with Next, review, and choose Update to link that collection. Cases already linked to the cycle are excluded from the recommendation list, so inspect existing membership before declaring one missing.
If an existing mandatory case still cannot be obtained through recommendations, the separately documented manual route is Test Cases, Link Test Cases, select the case, then Link or Link & Close. Verify its folder, filters and identity there. Do not label the cycle complete while required cases remain absent; the normal linking route is a fallback for an authorized cycle owner, not evidence that QI retrieved the case.
Keep a review record containing the objective, selected space, filters, requirement references, included case identities, exclusions, unresolved gaps and reviewer decision. Record the actual cycle key after linking. This record is a recommended team convention, not a claim that QMetry creates these approval fields automatically.
Choosing a case identity, linking its version and executing it are separate decisions. The manual-link guide describes an indicator when a newer case version is available and a separate synchronization action. Check whether the linked version contains the behavior the reviewer approved; do not assume that selecting the right key answers the version question.
Avoid synchronizing a previously executed cycle merely to tidy up its scope. The guide says version synchronization cannot be reverted and requires Test Cycle Edit permission. It also warns that synchronization resets the case and step execution statuses to Not Run on current and previous executions in that cycle, removes associated bug links, and erases execution fields such as actual outcomes and comments.
Unlinking also needs care: the guide warns that it permanently deletes that case's execution history with the associated cycle. Have the cycle owner assess those effects before changing historical membership. Collection approval is not permission to discard execution evidence, and a newly linked case is not a completed test.
When the feature is absent, ask the administrator to check instance and space enablement, activation completion and the relevant permissions. Do not change privacy settings or borrow broader access as a troubleshooting shortcut. Availability in documentation does not prove access in your instance.
When recommendations seem too broad, compare the objective with the release exclusions and check the field values used in filters. A case can be semantically related but out of scope, as ADR-105 is in the fictional packet. The reviewer, rather than the similarity of its wording, owns that exclusion decision.
When a mandatory case is absent, check the selected space, restrictive filters, library content and whether it is already linked to an existing cycle. Use its known identity where available. If investigation finds no current case with the required expected outcome, assign the gap instead of substituting a vaguely related test.
Approve a cycle's membership only when the actual linked set can be reconciled to the requirements, mandatory policy and reviewed exclusions. Preserve that decision with the relevant case versions and cycle identity. Execution planning and results can follow, but neither a recommendation list nor a completed collection review establishes release readiness.
Two reports can describe the same symptom while disagreeing about where the failure occurs. If a reviewer accepts a duplicate suggestion because the titles…
A checkout test times out while waiting for an order confirmation. The runner reports an assertion failure, the application records a failed request, and…
A recipient-preview rule changes, but the regression suite still checks the earlier behavior. An AI agent may choose a different route through the editor…
Create traceable test cases, prepare release-specific test runs, and keep approved coverage current as the product changes.
