A new tester can sign in to Jira and still be unable to begin useful work. The assigned story may be missing from the board, its acceptance criteria may be ambiguous, or the test tool may allow reading cases but not recording results. Discovering those gaps after sprint work is assigned leaves both the tester and mentor improvising.
Treat QA onboarding in Jira as a set of observed readiness checks. The mentor should see the tester perform the relevant task, retain brief evidence, and give each blocker a named recovery owner. Passing these checks supports a bounded first assignment; it does not establish complete product knowledge or authorize production access.
Track the checks in one ordinary onboarding work item, using its description and comments. The following are suggested record contents, not built-in Jira fields or a separate native checklist feature.
Record Content | What to Capture |
|---|---|
Mentor and backup | Named people who review evidence and answer questions |
Check evidence | What the tester demonstrated, when, and in which context |
Open blocker | Missing prerequisite, recovery owner, next action and recheck condition |
First assignment | Agreed scope, safe environment and review responsibility |
Use subtasks or child work items only if your configuration supports them and separate ownership would help. Company-managed subtasks require administrator enablement and the appropriate work type configuration. A description-based record is enough to start.
Jira Cloud documentation now often uses “space” and “work item” where teams may still say “project” and “issue.” Identify whether the team's space is company-managed or team-managed before giving configuration advice. Labels, permission controls and available paths can differ.
The example below is fictional: mentor Maya is preparing new tester Leo to check a promotion change in an approved nonproduction environment. No customer implementation, tenant verification or actual test result is implied.
Start with the work Leo is expected to do, then ask the access administrator to confirm the minimum suitable access. Viewing a story, commenting, editing a work item, recording evidence and changing a status are different actions. Include only the actions required for his assignment. Do not request administrator access to make onboarding easier.
In company-managed spaces, permission schemes govern capabilities and may be shared across spaces. Being allowed to change the assignee is different from being eligible to receive an assignment. In team-managed spaces, access levels and roles control participation, including inherited access from the space's general access level. A familiar role name is insufficient evidence that the intended actions work. Some permission and role configuration is restricted on Free plans, so an administrator must check the actual plan and setup rather than copy a universal tester-role recipe.
Maya should observe Leo using his intended account, not her administrator session or a shared login. Verify that he can open the agreed story and perform the permitted, low-risk actions on an authorized practice item. If he needs to receive work, confirm assignability through the team's approved process.
Record the action, target scope and observed outcome. If access fails, retain the denied action and relevant error without exposing credentials. The access administrator owns the correction; Maya owns the recheck. An invitation sent or a group membership added is not a passed access check until the intended action is confirmed.
Ask Leo to find the selected story without relying on Maya's open browser tab. He should identify the team's board, locate the work in its relevant backlog or sprint view, open it directly, and explain who owns the next action. Use the views enabled for this team rather than assuming every Jira board has the same navigation.
Check whether he understands the underlying status as well as the visible column. The company-managed board documentation allows several statuses to map to one column. A column named QA might therefore contain work awaiting intake as well as work already being tested; the team's mapping determines the meaning.
A missing card needs diagnosis before anyone creates a duplicate. Compare the directly opened work item with the board view, check active filters, and ask the board owner to review configuration if necessary. Atlassian's company-managed guide identifies board filters and unmapped statuses as possible reasons work is absent from a board or backlog. Do not assume a missing card always means missing access, or change shared filters and columns as a practice exercise.
The pass evidence is Leo locating the agreed item and explaining its current place in the team's process. If he can open it directly but cannot locate it on the board, record that narrower observation. Maya coordinates with the board owner rather than treating the tester's navigation uncertainty as a request for broader permissions.
Knowing the status names does not establish that a tester understands when to move work. Maya should explain the team's intake, active-testing, return and completion decisions, including who may make each decision. Ready for QA, In Test and similar labels are team choices, not universal Jira statuses.
Use an explicitly authorized practice item with a known safe path. Before changing its status, the mentor should confirm whether the transition has notifications, assignments or other configured side effects. Do not move a live delivery card merely to see what happens. If no safe practice target exists, use a walkthrough and record hands-on practice as still pending instead of marking it complete.
Have Leo explain the evidence needed before a permitted forward transition and what he should do when a handover is incomplete. Then observe the agreed forward and return actions on the practice item. Do not assume every transition is reversible or that dragging a card is always the supported route.
Permissions and workflow restrictions can prevent transitions. Company-managed permission schemes and team-managed roles and rules are different configuration models; the relevant workflow owner must inspect the actual setup. A blocked transition is a reason to identify the missing prerequisite or intended restriction, not to remove controls. Retain the demonstrated path and any restriction in the onboarding record, with that owner responsible for resolving what prevents the first assignment.
Give Leo a selected story and ask him to explain what outcome the user needs, what is changing, and how he would judge the result. Acceptance criteria should supply testable expectations. The team's Definition of Done provides broader completion standards; it should not replace the story's specific behavior.
For the fictional promotion change, the agreed criterion says excluded products receive no discount. Leo should ask what happens when a cart contains both excluded and eligible products. If the requirement does not answer, Maya takes that question to the product owner before Leo treats the implementation's behavior as correct. The developer can explain what was built, but an ambiguous business rule needs an agreed product decision.
Next, ask Leo to identify the candidate build, intended environment, approved test data and any relevant configuration. “The latest build” is insufficient when another deployment can replace it. He should also know where to find developer checks and known limitations without assuming those checks substitute for his own evaluation. A developer-to-QA handover agreement gives mentors a fuller model for assembling that context.
Pass this check when Leo can explain a bounded expected outcome and locate the prerequisites for testing it. Maya reviews the explanation; the product owner resolves disputed behavior, and the developer or environment owner supplies missing candidate information. Keep unresolved questions visible. Reading the story aloud does not demonstrate that the tester knows what evidence would support a result.
Check the tool the team already uses, whether that is a Jira test-management app or an external system. Access to the Jira story does not prove access to the relevant case collection, execution record or result action. Tool-specific permissions and setup need their own check with the tool owner.
Ask Leo to locate an approved test definition, the execution context selected for his assignment, and the place where its result should be recorded. Explain what he may read, execute, edit or submit for review. Avoid granting case-approval or library-editing rights merely because he needs to record an execution result. Use an authorized training context for any practice write.
For a team already using Sherlock Test Management, its current product workflow distinguishes a human-approved, versioned baseline from a release-specific test run. It describes recording Pass, Fail or Blocked in Sherlock Runner or supported Jira panels. Maya can use that distinction to show Leo which definition he is following and which run would receive his observation. These are app capabilities, not native Jira testing objects, and the team must confirm their availability and access in its own configuration.
Sherlock is an example, not a prerequisite for onboarding. The same check applies to the configured tool's own model. AI-proposed cases or edits also remain different from approved definitions and from executing the application. Pass evidence identifies the intended case and result destination; a missing app screen, inaccessible run or denied result action stays with the tool owner until rechecked.
Choose a small check with a clear outcome and recoverable setup. In the fictional example, Maya selects the excluded-only cart after the promotion requirement and candidate are confirmed. The mixed-cart question remains outside Leo's assignment until product clarifies it. This avoids turning an onboarding exercise into an investigation with no agreed answer.
Before execution, Leo should describe the setup and expected outcome in his own words. Maya observes the authorized check in the approved nonproduction environment and reviews the resulting evidence. No particular outcome is assumed here: a reproducible failure can demonstrate good testing, while an unexplained pass can leave the work unverifiable.
The review should be able to recover:
Keep secrets and personal customer data out of comments, screenshots and logs. Use approved protected references where sensitive setup information is necessary.
The mentor signs off on the quality of the work, not the number of bugs found. Leo should be able to explain why the observation supports the recorded result. If an environment is unavailable, record the affected check as blocked according to the configured process. If behavior contradicts an agreed expectation, capture the mismatch for review. Do not mark a check passed to complete onboarding, or change a reusable expectation to match faulty behavior.
Maya owns feedback and decides whether Leo can repeat this type of bounded assignment with lighter supervision. Missing setup belongs to its recovery owner; unclear reporting becomes a coaching action with an explicit recheck.
Rehearse a problem before the first urgent blocker. Maya can describe an unavailable test environment and ask Leo to draft an escalation without sending a real incident message or modifying live work. The draft should identify the affected assignment, what cannot proceed, the observed symptom, what was already checked, and the person responsible for the next action.
Add a backup when the primary contact is unavailable. Agree where the team records blockers, when the mentor should be contacted, and how urgent security or data concerns follow the organization's established route. There is no universal response-time target for every QA team; use the team's actual working agreement.
A useful rehearsal ends with a resume condition. For the unavailable environment, that could be the environment owner confirming recovery and Leo rechecking the candidate and setup before continuing. Unrelated work may proceed only if its prerequisites remain valid. A blocked environment must not become a failed application result, and silence from a contact must not become approval to bypass controls.
Pass evidence is the reviewed draft escalation, named recovery contact and backup, and a clear explanation of when testing may resume. If nobody owns recovery, Maya assigns that coordination problem to a named team lead before relying on Leo to handle it alone.
Before sprint planning, review the onboarding work item together. Record which checks were demonstrated and which remain blocked, then choose a first assignment that fits the verified access, context and support. Hold affected work when an essential prerequisite is missing. A visible blocker with an owner is a safer starting point than a completed checklist that nobody has observed.
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.
