A story moves to Ready for QA, but the tester cannot tell which build contains the change. The acceptance criteria describe yesterday's behavior, and the developer who knows the setup has started another task. The card has moved; the work needed to begin meaningful testing has not.
A developer-to-QA handover in Jira should establish a testable candidate, an agreed scope, and people who can resolve the next question. Treat it as a working agreement between development, QA, and product. Jira can make that agreement visible and enforce selected prerequisites, but a status change cannot establish that the software works.
Define Ready for QA as permission to begin a specified testing activity because its prerequisites are available. For a deployed feature, that might require an identifiable build in an accessible environment, current acceptance criteria, usable test data, and developer verification evidence. A different activity, such as reviewing an API contract before implementation, needs different prerequisites.
The ISTQB Foundation Level syllabus describes entry criteria as preconditions for an activity and exit criteria as conditions for declaring it complete. Use that separation when writing the handover agreement. Entering QA does not mean QA has passed, and completing functional testing does not automatically grant business acceptance or release approval.
Keep three decisions explicit. The developer states what was implemented and checked. The tester evaluates the agreed behavior independently and investigates risks beyond the developer's chosen examples. The designated product or business representative resolves intended behavior and grants any required business acceptance. One person may carry more than one responsibility in a small team, but the evidence and decisions should remain distinguishable.
Involve QA during refinement and implementation. A handover gate should prevent avoidable setup failures at execution time, not postpone all test design and clarification until coding ends.
Start with a short, maintained handover record on the work item. Put stable facts in fields when the team needs to filter or validate them, and use a structured description or comment for explanation. Build, QA Owner, and Handover Notes are proposed labels here, not universal Jira fields. An administrator must configure any custom fields and make them available in the relevant project and work type.
Record the candidate's build or artifact identifier, the target environment, and the configuration that affects the change. Include relevant feature flags, migrations, dependency versions, or service endpoints through approved references. “Latest on staging” is weak evidence when another deployment can replace it before testing starts.
Distinguish a successful code check from a successful deployment. A merged pull request or green pipeline result does not, by itself, establish which application version is running in QA. Supply an accessible deployment record or another agreed way to verify the deployed version. This can be a manually maintained reference; Jira does not create a deployment integration merely because a team adds a field.
Summarize developer checks with their scope and outcome. “Promotion exclusion checked with an excluded-only cart on candidate checkout-b184” is more useful than “tested.” Record relevant failures and checks that could not run. If a basic smoke check is part of the agreement, identify the build and environment it exercised rather than carrying forward a result from another candidate.
Compare the implemented scope with the current acceptance criteria before requesting QA intake. Identify changed rules, removed behavior, unresolved questions, and effects on neighboring flows. Attach or reference the agreed source of expected behavior, not only the implementation discussion.
For a promotion change, “excluded products receive no promotion” may leave mixed carts ambiguous. Does the promotion still apply to eligible items in that cart? Resolve the expected outcome with the product owner before treating a developer's interpretation as the test oracle. If part of the feature is deliberately deferred, record the boundary and who agreed to it.
Existing tests need review when their source changes. Sherlock Test Management's current product description provides a useful app-level workflow: source-referenced cases belong to a human-approved, versioned baseline, and requirement changes can flag cases and prompt proposed edits. A reviewer can reconcile the mixed-cart expectation before accepting an update. The reviewed baseline workflow supports test-definition maintenance; it does not verify deployment, execute the application autonomously, or grant business approval.
State which accounts, roles, starting records, and dependency conditions are needed. A tester with administrator access may be unable to reproduce a failure affecting a restricted user. A cart already modified by another test may no longer satisfy the scenario's preconditions.
Provide an approved fixture or dataset reference, explain how to restore the starting state, and identify the environment or data owner. Link to secure access instructions rather than placing passwords, tokens, or personal customer data in the issue. For a deeper treatment of reusable starting states, use this guidance on safe, repeatable QA data.
List known limitations beside the affected scope. If a payment sandbox is unavailable, specify which checks are blocked and who will restore it. QA may still accept an independently testable part of the change, but the untested dependency must remain visible. Do not convert “cannot run” into “passed” to keep the card moving.
A handover needs an accountable receiver, not a comment addressed to “QA.” Agree who reviews incoming work, who performs the testing, and who answers implementation questions after assignment changes. The intake reviewer and tester may be the same person; a backup is useful when that person is unavailable.
The following responsibilities form a proposed agreement. They do not imply that Jira supplies a separate built-in field for every role.
Responsibility | Named Owner Should Provide | Decision or Next Action |
|---|---|---|
Implementation responder | Candidate identity, changed scope, developer checks, answers about the change | Complete missing context or investigate a reported mismatch |
QA intake reviewer and tester | Readiness review, test scope, independent results and remaining risks | Accept testing work, return an incomplete handover, or record a blocker |
Product or business approver | Intended behavior and decisions on disputed or deferred scope | Clarify expectations and provide required business acceptance |
Environment or dependency owner | Access, configuration, dataset or service recovery information | Restore a prerequisite and confirm when affected testing can resume |
Choose one meaning for the work item's current assignee. A team might keep the developer assigned until QA accepts intake, then assign the tester while retaining the implementation responder in the handover record. Another team may use a stable delivery owner and track testing assignments separately. Either arrangement needs an explicit acceptance signal; assigning someone does not prove they reviewed the handover.
Keep the original story as the common context when development and QA are working toward the same outcome. A linked testing task or subtask can be useful when testing has separately planned capacity, parallel assignees, or a distinct scope. It also introduces synchronization work: owners must keep the test task's build and criteria aligned with the story. A separate QA project is not necessary merely to show that development finished its part.
Ready for QA is a team-selected workflow status, not a universal native button. Decide the forward path, the return path, and the meaning of completion before adding configuration. A possible sequence is In Development, Ready for QA, In Test, and Done, with an explicit route back for incomplete handovers or changes needing rework. Use the statuses your team can maintain rather than copying this sequence automatically.
Workflow statuses and board columns serve different purposes. Jira boards can map several statuses to one column, so a column named QA may contain both waiting and actively tested work. Inspect the underlying status when distinguishing those states. For the documented Scrum board completion behavior, work items in the rightmost column count as complete; placing Ready for QA there can make unfinished testing appear complete for sprint handling. Review the actual mapping with the board administrator.
For the documented screen-based Jira Cloud approach, a Jira administrator can add the required field to a transition screen, add a Field Required Validator to the relevant workflow transition, associate that screen, and publish the workflow draft. Use this when an essential handover value must be present before the work enters the next status. Confirm the field is available in the intended context and that the screen exposes it to the person making the transition.
Treat this as a configuration pattern, not a claim that every workflow editor has identical controls. Atlassian's Cloud knowledge base documents the screen-and-validator method; it explicitly does not establish the same out-of-the-box capability for Server or Data Center. Check the actual editor and deployment before following a click path.
Require only fields that support a real decision. A nonempty Build field can still contain an obsolete identifier. A validator that checks presence cannot establish that the build is deployed, the data is usable, or the acceptance criteria are correct. Keep a human intake review for those questions.
Team-managed Jira Cloud projects have their own workflow rules. Atlassian documents rules for restricting who can move a work item, checking field values, and assigning work to someone after a transition. Select the rules available in that project's editor instead of copying a company-managed transition-screen recipe.
Check the intended users as well as the administrator. In company-managed permission schemes, changing Assignee, being an assignable user, and transitioning work items involve distinct permissions. Workflow restrictions can further limit transitions. In team-managed projects, inspect the configured roles and workflow rules. Test both forward and return transitions with representative users before rollout.
An automatic assignment rule can route work to the intake reviewer. It cannot establish that the reviewer accepted it. Likewise, a notification is a request for attention, not evidence that testing has started.
Consider this illustrative handover for SHOP-418, which changes promotion exclusions. The issue and build identifiers, people, and configuration below are examples, not a customer case or evidence of a tested Jira tenant.
Leo first verifies that the candidate and prerequisites match the record. He can then accept the handover and select independent checks, including changes to cart contents, recalculation, and relevant neighboring behavior. He should challenge assumptions rather than reproduce only Maya's successful examples.
The refund limitation requires a scope decision. If the changed calculation affects refunds, the team needs suitable coverage and prerequisites, or an explicit unresolved risk for the authorized release decision. Accepting the feature into QA does not approve that exclusion or authorize release.
Agree on the return path before the first disputed handover. Distinguish missing handover information, an unavailable prerequisite, and an observed mismatch with expected behavior. Those situations need different recovery actions, even if the team uses a shared blocked status.
If SHOP-418 lacks a deployment reference and Leo cannot identify the running build, return it for completion under the agreed workflow. Record the missing evidence, assign the next action to Maya, and state the condition for resubmission. Avoid an unexplained “rejected” comment that leaves everyone guessing what to repair.
If the build is identifiable but the sandbox is unavailable, record affected checks as blocked and give Sam the recovery action. Continue unrelated checks only where their results remain valid. If an excluded product receives the promotion on the agreed candidate, capture the expected and actual result, setup, and reproduction evidence so the team can triage a product defect rather than treating it as incomplete paperwork.
Retain the history when a new build arrives or criteria change. Recheck candidate identity and affected prerequisites, and review which earlier results still apply. Confirmation testing checks the correction of the original defect; regression testing looks for adverse consequences of the change. Neither a resubmitted card nor a repeated happy-path check substitutes for that scope decision.
Use one recurring change type to test the agreement. A small pilot exposes unclear ownership and configuration problems before the gate affects every item.
For the next story, ask the receiving tester to make one explicit decision: accept a testable scope, return specified missing context, or record a blocker with a recovery owner. If they cannot make that decision from the handover, improve the agreement before adding another status.
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.
