A Jira story now requires verification before a shopper can save a delivery address. Its linked test case still expects the address to change immediately. The case key, requirement link, and earlier passing result can all remain intact while the instructions have become wrong for the next release.
AI test case maintenance in Jira should begin with QA identifying that requirement change and selecting the existing cases that need review. An approved AI assistant can propose edits, but a reviewer must compare the proposed actions and expected results with the current source and previously reviewed specification. Save only the accepted changes. AI-assisted editing does not establish automatic story-change detection, complete impact analysis, or autonomous approval.
Open the changed Jira Cloud story and identify the authoritative acceptance criteria. They may be in the description, a configured field, or a linked specification. Check which source the product owner intends the team to follow, particularly when a comment contradicts the description. Do not turn an unresolved conversation into an expected result.
Jira's Activity section includes a History filter for updates such as field edits and workflow changes. Use it to investigate the change, then retain the relevant old and current requirement text or controlled references. History helps explain an edit; it does not prove that a test specification was approved or preserve everything an app stores separately.
Prepare a small change record containing the story key, source reference and revision or retrieval time, previous rule, current rule, and person responsible for clarifying uncertainty. Labels such as AC-1 are useful local references, not universal Jira fields. Separate a behavioral change from a spelling correction: adding a verification condition changes the expected outcome even if the story edit is short.
Before sharing context with AI, confirm that the assistant is approved for this material. Check organizational data-handling rules and the installed app's permissions and enabled features. Use synthetic data, remove credentials and personal information, and provide only the source excerpts needed for this review. Approval to read a Jira story is not permission to paste its attachments into any public assistant.
Start with the cases already linked to the story, rather than generating a replacement suite. In an AIO Tests installation, the app's Jira panel documents a Cases tab listing linked cases for traceability. That is app functionality, not a native Jira test-maintenance feature. Access restrictions can also limit what a reviewer sees.
Read each candidate's current steps, preconditions, expected outcomes, data references, and reviewed revision. A link tells you where to investigate; it does not prove that a particular case version covers the changed criterion. A case can be linked but irrelevant to this change, while an affected shared flow can lack the link entirely.
For address verification, inspect the successful update, invalid-code and expired-code paths, and related account or checkout flows that reuse the address. Search adjacent coverage where a dependency warrants it. Keep the review scope explicit rather than claiming that the linked list contains every affected case.
Classify the findings before requesting edits:
Protect unaffected checks during this classification. A new email-code step does not remove the need for authentication, address-field validation, or the existing fixture setup. Likewise, an unchanged negative case should not disappear because the AI proposes a shorter happy path.
Provide the selected case and the actual requirement delta together. Supplying only the latest story encourages a fresh rewrite that can discard established checks. Supplying only the old case gives the assistant no reliable basis for deciding which behavior changed.
A useful review packet contains the current criterion, the superseded text, the existing case revision, relevant preconditions and synthetic data references, and explicit exclusions. Include companion-case references where they explain why a negative path belongs elsewhere. Do not upload the whole repository when a few approved excerpts suffice.
Use a request like this in the organization-approved assistant:
Propose edits only for the supplied existing case. Treat the current acceptance criteria as authoritative. Return the original action and expected result, the proposed replacement, the criterion supporting it, and any uncertainty. Preserve unaffected steps, negative checks, and dataset references. Do not invent business rules. Identify new coverage separately. Do not save changes or mark anything approved.
This is a suggested manual request, not a documented AIO input field or an integration recipe. AIO's existing-step editing guide establishes suggestion and comparison controls; it does not establish that this editor automatically reads a changed story or accepts an arbitrary acceptance-criteria packet. If the installed editor lacks a verified way to use the required context, prepare the reviewed change separately and apply it through the supported editing workflow. Do not substitute generic wording improvements for a requirement-based review.
The following story, case identifiers, criteria, and proposals are fictional teaching examples. They do not describe a customer implementation, an AI upload, or changes performed in Jira or an app.
In story SHOP-218, the previous rule allowed a signed-in shopper to save a valid delivery address immediately. Existing case ADDR-12 checks sign-in, valid address entry, saving, and the address displayed afterward. Its reviewed baseline also references an invalid-address dataset and a companion case for unauthenticated access.
The fictional replacement criteria state:
The expiry boundary is specified here so the example has a reviewable expected outcome. Attempt limits, resend behavior, and the exact error-message text are deliberately unspecified. A reviewer must not infer them from familiar products.
For the old final step, the action is “Select Save after entering the valid address,” and the expected result is “The new address is stored and displayed.” That outcome must change because saving now depends on verification. The earlier sign-in requirement and address-validity checks still apply.
Compare actions and outcomes separately. A proposal can add the right action while keeping an obsolete expected result, or describe a plausible error state that contradicts the source. The table shows illustrative proposals and review decisions, not output observed from a particular model.
Existing Check | Illustrative AI Proposal | Reviewer Decision | Reviewed Update or Follow-Up |
|---|---|---|---|
Valid address saves immediately | Add email-code entry, then save after a valid code | Accept with source-based detail | Verify a correct code before expiry; expect the new address stored and displayed under AC-1 and AC-2 |
Expired-code path is absent | Save the address automatically when the code expires | Reject | Under AC-3, expect no saved change and the previous address retained |
Sign-in and invalid-address checks exist | Remove them to shorten the case | Reject | Preserve these unaffected checks and their dataset references |
Resend behavior is unspecified | Resending always extends the validity period | Hold for clarification | Ask the product owner; do not approve an expected result without a source |
Keep rejected proposals visible in the review record with their reasons. The expiry proposal is unsupported and contradicts the stated requirement. Accepting it would weaken the test by redefining a failure as success.
The happy-path edit also does not complete negative coverage. Maintain or add identifiable checks for invalid and expired codes, including the specified expiry boundary, with expected retention of the previous address. Keep synthetic data capable of distinguishing the old and new address; otherwise a check that merely says “address displayed” may miss an unintended save.
Resolve resend behavior through product clarification and an updated source before approving coverage that depends on it. A separately reviewable, supported change may proceed under the team's policy, but the unresolved gap must remain visible to the test owner. Do not label the whole story fully covered while that question remains open.
The exact save path depends on the test-management app and enabled edition. AIO Tests provides a documented example for improving existing steps. Confirm that the app is installed in Jira Cloud, the feature is available, and the maintainer has permission to edit the selected case. The Marketplace listing verifies an app offering, not the configuration or entitlement of your site.
AIO's guide describes this sequence:
The guide also documents Select all original and Select all AI. Select all AI is not an approval decision. Do not use it as a shortcut around checking individual changes. The separate Fix grammar for steps option addresses wording; it does not establish that a case matches changed acceptance criteria.
Apply the requirement-based corrections through the supported editor when they are absent from the suggestion. Verify the expected outcomes as well as the step actions, without assuming a particular field layout or automatic outcome update. If content is edited after review, inspect the resulting revision again before treating it as approved.
Saving content and recording organizational approval may be separate operations. The editing guide does not establish an independent reviewer gate or prove that Save enforces your approval policy. Record the reviewer and accepted scope using the team's controlled process, and keep draft or unresolved content distinguishable from the approved specification.
After saving, reopen the case and compare the actual stored content with the reviewed update. Confirm that unaffected steps, negative cases, dataset references, requirement links, and preconditions remain intact. A successful save response alone does not prove that the selected text is correct.
Retain the earlier reviewed revision or controlled specification, the source change, the new revision, and the decision connecting them. Check how the installed edition preserves case versions and execution history before relying on it. Do not promise that every app or package retains the same fields, or use a destructive synchronization operation to make old executions appear current.
A previous pass for immediate address saving cannot establish the new verification behavior. Keep that result associated with the instructions, build, environment, and data used at the time. Plan a new execution for the reviewed specification and intended candidate, checking which version the run actually selects. The guidance on test case versioning and run snapshots explains why today's reusable case and an earlier run's evidence need separate references.
Sherlock Test Management offers a relevant reviewed-baseline model. Its current product description says AI edits remain proposals for human acceptance or rejection, approvals create baseline versions, and finished runs stay attached to the version they executed. For the address change, that model separates review of the revised expected behavior from the earlier executed specification. The Sherlock baseline and test-run workflow describes this approach; it is not the AIO editing interface or a claim of integration between the products.
A maintainer should be able to hand the case to another tester with the source delta, selected case identities, reviewed revision, accepted and rejected edits, reviewer decision, and unresolved questions all recoverable. Keep a no-change decision for candidates that were checked but did not need editing. This prevents the next reviewer from mistaking an untouched case for one nobody inspected.
Content review does not execute the test or prove the application meets the requirement. The run owner still needs to select the reviewed specification, execute it against the intended candidate, and retain the observed outcome. Keep any blocked coverage explicit in that decision.
Start with one changed story and one linked existing case. If another teammate cannot explain why each changed expected result follows from the current requirement, return the proposal for correction before extending the process to more cases.
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.
