82 Jira interview questions with answers

What they are assessing

Basic orientation.

Model answer

Jira is an issue and project tracking tool from Atlassian, used to plan, track and report work. In software teams it holds the backlog, the sprint, the defects and the release scope, and it is usually the system of record for what was agreed and what shipped. For a tester it is where defects are raised and tracked, where test coverage is often linked back to requirements, and where the evidence lives when someone asks later why a release went out with a known issue.

What they are assessing

Whether the candidate knows which product they used.

Model answer

Jira Software is for development teams and carries the agile features: boards, sprints, backlogs and releases. Jira Service Management is for service desks, adding queues, SLAs, a customer portal and request types, and it is where production incidents often originate. Jira Work Management is for business teams doing non-technical work. They share the same underlying issue engine, which is why an escalation can move from a service desk ticket to a development defect while keeping the link.

Likely follow-up

Why does the link between a service desk ticket and a bug matter to QA?

What they are assessing

Basic structure.

Model answer

A project is a container for issues that share a configuration: workflows, issue types, permissions and screens. The project key is the short prefix on every issue in it, so a key of PAY produces PAY-101 and so on. The key is effectively permanent in practice, because it appears in every issue reference, in commit messages and in links across other systems, so renaming it breaks a great deal of history.

What they are assessing

Current terminology and the practical consequence.

Model answer

Company managed projects, formerly called classic, use shared schemes administered centrally, so workflows, fields and permissions are consistent across projects and changed by a Jira administrator. Team managed projects, formerly next-gen, let the project team configure their own workflow and fields without administrator access. The trade is autonomy against consistency: team managed is faster to set up and fine for an independent team, but reporting across many team managed projects is painful because their fields and statuses do not line up.

Trap to avoid

Not knowing that custom fields in team managed projects are scoped to that project. It is the usual reason a cross-project filter or dashboard silently returns nothing.

What they are assessing

Two fields QA relies on and many teams neglect.

Model answer

A component is a sub-section of a project, such as a module or service, used to group issues and optionally to assign a default owner. A version represents a release, and issues carry two version fields: Affects Version, meaning where the problem was found, and Fix Version, meaning where it will be or was resolved. For QA these two fields do most of the heavy lifting in release reporting, because they answer what is in this release and what is still open against it.

Likely follow-up

How would you use Affects Version to spot a regression?

What they are assessing

Hierarchy, which candidates often describe loosely.

Model answer

An epic is a large body of work spanning sprints, containing stories. A story is a user-facing increment that can be completed within a sprint. A task is work that is not user-facing, such as a technical change. A sub-task is a breakdown of any of those, and it is the only true parent-child relationship in the standard hierarchy, which matters because sub-tasks cannot exist independently and behave differently on boards and in reports. Above epics, Jira Premium adds initiatives through Advanced Roadmaps.

Trap to avoid

Using sub-tasks for testing work on every story. It feels tidy and then makes sprint reporting misleading, because sub-task estimates and transitions are treated differently from their parents.

What they are assessing

Practical familiarity.

Model answer

Beyond the standard epic, story, task and sub-task, a QA-heavy project usually adds Bug, and often Test and Test Execution if a test management add-on is installed. Some teams add Improvement to separate a genuine defect from a change request, which is worth doing because the two have different conversations attached: a defect is a failure against expected behaviour, while an improvement is a request to change what the expected behaviour is.

What they are assessing

A judgement that causes more friction than any other in QA.

Model answer

The test is whether the behaviour contradicts an agreed specification, an accepted criterion or a reasonable user expectation. If it does, it is a defect. If the software does exactly what was specified and the specification was wrong, it is a change request, no matter how bad the behaviour is. The classification matters because it decides who absorbs the cost and whether it blocks a release. Where a specification is silent, which is most of the time in practice, I raise it as a defect with the ambiguity stated plainly and let the product owner decide, rather than arguing the category in comments.

Likely follow-up

What do you do when the product owner reclassifies a serious defect as an improvement?

What they are assessing

Relationship modelling.

Model answer

A link is a labelled relationship between two independent issues: blocks, is blocked by, relates to, duplicates, causes. Both can live in different projects and have separate lifecycles. A sub-task is a child that belongs to its parent, cannot be moved out independently in the normal way, and is bound to the parent on boards. Use links for dependencies and for connecting a defect to the story that introduced it. Use sub-tasks only for genuine decomposition of a single piece of work.

What they are assessing

Traceability thinking.

Model answer

As a new Bug, not by reopening the original story, because the story is a record of delivered work and reopening it corrupts the sprint history. I would set Affects Version to the release where it was found, link it to the original story with a causes or relates to link so the lineage is visible, and set Fix Version once it is scheduled. If it came from a service desk ticket I would keep that link too, so the support conversation and the engineering fix stay connected. The linking is what lets you answer later whether a particular feature has been a persistent source of defects.

Trap to avoid

Reopening closed stories for production defects. It makes velocity and sprint reports meaningless and hides the real defect trend.

What they are assessing

Basic definition.

Model answer

A workflow is the set of statuses an issue can be in and the transitions allowed between them. A simple one runs To Do, In Progress, Done. A defect workflow usually adds more: Open, In Progress, Ready for Test, In Test, Reopened, Closed, with a Rejected or Cannot Reproduce route. The workflow encodes the team process, which is why changing it is a process conversation rather than a configuration task.

What they are assessing

Whether the candidate has lived a real process.

Model answer

New when raised by a tester, then Triaged or Assigned once severity and priority are agreed and an owner is set. In Progress while the developer works. Ready for Test when the fix is merged and deployed to the test environment, which is the transition teams most often get wrong by moving it on merge rather than on deployment. In Test while the tester verifies. Then Closed if it passes, or Reopened if it does not, which should return it to the same developer. Alongside that are the terminal routes: Rejected when it is not a defect, Duplicate, Cannot Reproduce, and Deferred when it is accepted but not being fixed now.

Likely follow-up

Why does Ready for Test on merge rather than on deploy cause problems?

What they are assessing

A principle question with a clear expected answer.

Model answer

The tester, or whoever raised it. The developer marks it fixed or resolved, and the person who reported it verifies and closes. The reasoning is simply that the reporter is the only one who knows what they observed and in what conditions, and a fix that works on the developer machine is not a verified fix. Letting developers close their own defects consistently produces a backlog of closed issues that are still broken, and it removes the only independent check in the loop.

Trap to avoid

Saying it does not matter as long as it is fixed. Interviewers ask this specifically to see whether you understand verification as a separate step from resolution.

What they are assessing

Configuration depth beyond daily use.

Model answer

A condition controls whether the transition is available at all, typically by role, so only a tester sees the Close button. A validator runs when the transition is attempted and blocks it if a requirement is unmet, for example demanding a resolution or a fix version before closing. A post function runs after the transition succeeds, setting fields, adding a comment, firing an event or updating a linked issue. They execute in that order, and most QA process enforcement that actually works is built from validators, because a condition can be worked around and a convention is routinely ignored.

Likely follow-up

Give an example of a validator you would add to a defect workflow.

What they are assessing

A distinction that causes real reporting damage when misunderstood.

Model answer

Status is where the issue sits in the workflow. Resolution is why it left the workflow: Done, Won’t Fix, Duplicate, Cannot Reproduce. The critical rule is that an issue is considered open by Jira if its resolution field is empty, regardless of status. So a workflow that moves an issue to Closed without setting a resolution produces issues that are visibly closed on the board and still counted as open in every filter, report and burndown. The reverse is as bad: setting a resolution on an in-progress transition makes live work disappear from the backlog.

Trap to avoid

Treating Closed and Resolved as interchangeable statuses. The question is really about whether you understand that the resolution field, not the status name, drives Jira reporting.

What they are assessing

Process judgement rather than configuration skill.

Model answer

I would find out which statuses carry real information before removing anything. Usually a handful are genuinely load-bearing, several exist because one person once wanted a report, and a few were added for a team that no longer exists. I would look at transition data to see what is actually used, talk to the people filling them in, then propose the smallest workflow that still answers the questions the business asks, which is typically who owns it now, is it waiting on us or them, and is it verified. The argument I would make is that unused statuses are worse than no statuses, because a field half the team fills in produces reports that look authoritative and are wrong.

What they are assessing

Basic awareness of the query language.

Model answer

Jira Query Language, the structured syntax for searching issues. A query is made of fields, operators and values joined by AND and OR, optionally with an ORDER BY. It is what underlies saved filters, board configurations, dashboards and most reporting, so it is the single most useful Jira skill for a tester beyond raising a good defect.

What they are assessing

Whether they can actually write it rather than describe it.

Model answer

project = PAY AND issuetype = Bug AND assignee = currentUser() AND resolution IS EMPTY ORDER BY priority DESC. The important part is resolution IS EMPTY rather than listing statuses, because it is robust to workflow changes and correctly captures everything genuinely unresolved. Using currentUser() rather than a name makes the filter shareable.

Likely follow-up

Why is resolution IS EMPTY better than status != Closed?

What they are assessing

Practical release reporting.

Model answer

project = PAY AND issuetype = Bug AND affectedVersion = "2.4.0" AND resolution IS EMPTY ORDER BY priority DESC. If the question is what is still outstanding for an upcoming release rather than found in a past one, the field is fixVersion instead. Knowing which of the two to use is the actual content of this question, and mixing them up is the most common error in release reports.

What they are assessing

Breadth.

Model answer

currentUser() for personal filters. startOfDay, endOfWeek and similar for relative date ranges that keep working without editing. openSprints() and closedSprints() for sprint scoped queries. membersOf() for team queries. linkedIssues() to find everything related to a given issue. And was, changed and during for historical queries, so you can ask which issues were ever reopened or which moved out of a sprint, which raw field comparison cannot answer.

Likely follow-up

How would you find every issue that has been reopened at least once?

What they are assessing

Knowledge of the limits of JQL and how to work within them.

Model answer

JQL can find issues that were ever in a given status using status CHANGED TO "Reopened", and can scope it by date with AFTER and BEFORE. What JQL cannot do natively is count the number of times a transition occurred, so more than once is not directly expressible. In practice I would either use a count-of-transitions field provided by an add-on such as Scriptrunner, or export the result of the CHANGED TO query with its changelog through the API and count there. Saying the plain query returns everything reopened at least once, and explaining why counting needs something else, is the honest answer.

Trap to avoid

Claiming a plain JQL query can count transitions. It cannot, and the interviewer asking at this level usually knows that.

What they are assessing

Reporting workflow.

Model answer

A filter is a saved JQL query. A dashboard is a page of gadgets, most of which are driven by filters. Both have their own sharing permissions, and the standard failure is sharing a dashboard while leaving its underlying filters private, so colleagues see an empty or broken gadget rather than the data. Filters can be shared with a project, a group or everyone, and the permission should match the audience of the dashboard rather than being set to everyone by habit.

What they are assessing

Agile basics as Jira implements them.

Model answer

A Scrum board works in sprints: you plan a fixed scope into a time-boxed iteration, and the board shows that sprint with a backlog behind it. A Kanban board is continuous, with no sprints, and focuses on flow and work-in-progress limits, usually with a visible backlog column. The Jira-specific detail is that Scrum boards give you sprint reports, burndown and velocity, while Kanban boards give you the cumulative flow diagram and control chart, so the choice determines which metrics are available.

What they are assessing

A surprisingly common source of confusion.

Model answer

By a filter. Every board is backed by a JQL query, and anything matching it appears. This is why issues sometimes vanish from a board for no apparent reason: somebody changed a field the board filter depends on, such as moving the issue to another project or clearing a component. It is also why a board can legitimately span several projects. When someone reports a missing issue, the board filter is the first place to look rather than the issue itself.

Likely follow-up

How do columns on a board relate to statuses?

What they are assessing

Sprint mechanics.

Model answer

Jira prompts you to move them to the next sprint, to the backlog, or to another named sprint. The issues keep their history, and the sprint report records that they were not completed, which is what makes velocity meaningful. The practice worth defending is not silently rolling everything forward every sprint, because an issue that has moved four times is telling you something, either that it is too large or that it was never really a priority.

What they are assessing

A genuine debate with no single right answer.

Model answer

A separate In Test column makes testing visible and is honest about the fact that it takes time, which is useful when the team is pretending it does not. The objection is that it encourages a mini-waterfall inside the sprint, where everything arrives for testing on day eight and the column becomes a queue. My preference is a testing column with a work-in-progress limit, so the bottleneck is visible and the team has to respond to it, combined with a definition of done that includes testing so nothing is called complete before it is verified. What I would avoid is treating testing as a sub-task that silently extends a story nobody can see the real state of.

Likely follow-up

What would you do if the testing column is full every sprint from day eight?

What they are assessing

Day to day board fluency.

Model answer

A quick filter is a saved JQL fragment that appears as a toggle above the board, narrowing what is shown without changing the board filter. For QA the useful ones are my issues, bugs only, blocked, and ready for test. The practical value is during stand-up and triage, where toggling to only the defects or only the blocked items changes a cluttered board into a conversation about a specific set of work in one click.

What they are assessing

The core competence the role exists for.

Model answer

A summary that states the problem specifically enough to be recognised in a list. Clear steps to reproduce, numbered, starting from a known state. Expected result and actual result as separate statements. The environment: build or version, browser or device, and the account or data used. Evidence, meaning a screenshot, a video or logs, and the timestamp so the backend logs can be correlated. Then severity and priority set with reasons. The test of a good report is whether a developer can act on it without asking you anything.

Likely follow-up

What is the single most commonly missing piece in the bug reports you see?

What they are assessing

The most frequently asked QA question of all, in a Jira context.

Model answer

Severity is the technical impact of the defect on the system, and it is usually the tester’s call. Priority is how urgently the business wants it fixed, and it is usually the product owner’s call. They diverge in both directions, which is the point of having both. A crash in an administrative screen used twice a year is high severity and low priority. A spelling mistake in the company name on the landing page is low severity and high priority. A candidate who can give an example in each direction has understood it.

Trap to avoid

Saying a high severity defect is always high priority. The interviewer is looking for the divergence.

What they are assessing

Professional conduct under disagreement, which is half of what QA is.

Model answer

I treat it as missing information rather than a disagreement. First I try to reproduce it again myself, because sometimes it was environmental or data-dependent and I can now say so precisely. If it still reproduces, I add what differs: exact build, account, data state, browser version, network conditions, a video, and any correlating log entry with a timestamp. If it is intermittent I say so and give the frequency, because an intermittent defect reported as reproducible is why developers stop trusting reports. If I genuinely cannot reproduce it either, I say that, and we agree whether to close it with a note so it is findable if it returns rather than deleting the record.

Likely follow-up

How do you log a defect you have only seen once?

What they are assessing

Process familiarity.

Model answer

A regular meeting where new defects are reviewed and agreed: is it valid, what is the severity, what is the priority, who owns it, and is it in scope for the current release. Typically the QA lead, a development lead and the product owner, kept short and run off a filter of untriaged items. The value is that it forces a decision on each defect while it is fresh, rather than letting an unreviewed backlog accumulate until nobody remembers the context of anything in it.

What they are assessing

Whether the candidate can act on a situation rather than describe it.

Model answer

I would first accept that nobody will ever read 400 defects, so the goal is a backlog people trust rather than an empty one. I would segment it: defects on features that no longer exist, defects raised against versions long since replaced, duplicates, and anything untouched for a year with no business pressure behind it. Most of those can be closed in bulk with a stated reason and a note that they can be reopened. What remains gets triaged properly against the current product. Then I would address the inflow, because a backlog of that size means triage was not happening, and clearing it without fixing that just resets a counter.

Trap to avoid

Proposing to fix them all. The honest answer is that a large proportion are no longer relevant, and the skill is deciding which with a defensible rule rather than one at a time.

What they are assessing

Whether the candidate uses the tool as the record rather than as an afterthought.

Model answer

So that anyone reading it later can reconstruct what was known and when, because this is the ticket an incident review or an auditor will open. That means severity and priority set and justified in the description rather than left at defaults, the fix version set to the release in question so it appears in release reporting, a blocks link to anything it holds up, and evidence attached with the build number and environment. If a decision is taken to ship regardless, it is recorded on the ticket with who took it and the agreed mitigation, not agreed verbally in a call. The go or no-go itself is not a QA decision; capturing it accurately is.

Likely follow-up

What would make that ticket useless to someone reading it six months later?

Trap to avoid

Treating the Jira record as administration to complete afterwards. It is the only durable account of a decision taken under pressure.

What they are assessing

Whether the candidate knows the boundary of the base product.

Model answer

Not properly. Jira has no native test case entity, no test execution cycle and no concept of a test run against a build. Teams improvise with a custom issue type called Test, or with sub-tasks, or with a linked Confluence page, and all of these work badly at scale because there is no way to execute the same test repeatedly against different versions and keep the history. This is why test management add-ons exist, and knowing the base product cannot do it is the point of the question.

What they are assessing

Market awareness.

Model answer

Zephyr, Xray, TestRail, qTest and PractiTest are the common ones. The main architectural split is whether test artefacts live inside Jira as issues, which Xray and Zephyr Scale do, or in a separate tool linked to Jira, which TestRail does. Storing tests as Jira issues gives you JQL, Jira permissions and native linking for free, at the cost of filling the project with issues. An external tool keeps Jira clean and gives richer test-specific reporting, at the cost of a synchronisation boundary that can drift.

Likely follow-up

Which would you recommend for a team of six, and why?

What they are assessing

A requirement in regulated and enterprise work.

Model answer

By linking deliberately and consistently: tests linked to the stories or requirements they cover, defects linked to the test that found them and the requirement they violate, and both carrying the fix version. With Xray or Zephyr there is a traceability report that follows those links and shows coverage per requirement, including which requirements have no tests at all, which is the question worth asking. Without an add-on you can approximate it with issue links and JQL, but the gap analysis becomes manual. The part that actually determines whether this works is discipline in linking at creation time, since nobody reconstructs links retrospectively.

What they are assessing

Integration knowledge.

Model answer

Through the test management add-on API from the CI pipeline. The common pattern is that the automated run produces a standard results file, typically JUnit XML, and the pipeline posts it to Xray or Zephyr, which creates a test execution against the right version and updates the individual test statuses. Mapping is by a key in the test name or an annotation tying the automated test to its Jira test issue. The failure mode worth mentioning is that this creates a large volume of execution records, so a retention policy matters, and that a broken pipeline step silently stops the reporting while everything looks green.

Likely follow-up

How do you prevent a failed upload from being mistaken for a passing run?

What they are assessing

Practical reporting.

Model answer

The sprint report and burndown for whether the sprint is on track and when testing work actually arrives. The created versus resolved chart for whether the team is keeping pace with defect inflow, which is the single most informative QA chart in Jira. The cumulative flow diagram on Kanban to see where work piles up, which usually shows the testing column. And the release or version report for readiness. Beyond those I build filters and dashboard gadgets, because the stock reports rarely answer the specific question being asked.

What they are assessing

Critical reading of a metric.

Model answer

It plots defects raised against defects resolved over time, so a widening gap means the team is falling behind and a closing gap means it is catching up. It misleads in several ways. Resolved includes rejected, duplicate and cannot reproduce, so a team can appear to be winning by closing defects without fixing anything. A dip in created often means testing stopped rather than quality improved, which is common at the end of a release or when a tester is on leave. And it treats a trivial defect and a critical one as equal, so the shape of the curve can improve while the risk gets worse.

Trap to avoid

Presenting the chart as a quality measure without caveats. It measures flow, not quality, and interviewers at this level want to hear you distinguish them.

What they are assessing

Whether they choose metrics that drive decisions.

Model answer

Open defects by severity against the release, which is the actual go or no-go input. Defects found per area, to show where risk is concentrated. Test execution progress and pass rate if a test management tool is in place. Reopen rate, because a high rate says fixes are not being verified properly or the environment is wrong. And anything blocked, with the reason. I would deliberately leave off counts that invite comparison between people, such as defects raised per tester, because the moment it is on a dashboard the number starts being managed rather than measured.

Likely follow-up

Why is defects-raised-per-tester actively harmful as a metric?

What they are assessing

Basic administration awareness.

Model answer

A reusable set of rules mapping permissions, such as who can create issues, transition them, edit or delete, to users, groups, project roles or fields. It is attached to a project, and several projects can share one. The recommended practice is to grant permissions to project roles rather than named users or groups, because roles are populated per project, so one scheme serves many projects and adding someone to a project does not require an administrator to edit a scheme.

What they are assessing

Systematic troubleshooting of a very common support request.

Model answer

I would work from the most likely outward. First, is the transition visible at all? If not, it is a condition on the transition, usually restricting it to a role the tester is not in on that project. If it is visible but fails, it is a validator, typically demanding a field such as resolution or fix version that is empty. If the issue is in a different project from the one they normally work in, their project role membership may simply be absent there. And if it is a team managed project, the workflow is local to that project and may differ from the one they are used to. Checking the permission helper as an administrator answers it in one step if you have access.

What they are assessing

Awareness of the no-code rules engine.

Model answer

A built-in rules engine with triggers, conditions and actions, configured without code. Useful QA rules include assigning a newly raised defect back to the reporter when a developer marks it resolved, so verification does not get lost. Commenting and transitioning when a linked pull request merges. Alerting a channel when a blocker-severity defect is raised. Flagging defects that have sat in Ready for Test beyond a threshold. The value is that these are the process steps everyone agrees to and nobody remembers to do.

Likely follow-up

What is the risk of automating transitions?

What they are assessing

Balance.

Model answer

Rules become invisible process. When an issue changes assignee or status with no human action, people stop trusting the tool and start keeping their own records. Rules also interact: two rules triggering on the same event can loop or fight, and Jira has execution limits that silently stop rules once hit. There is a real debugging cost too, because the audit log is the only way to see why something happened and most people do not know it exists. My rule is to automate notification and bookkeeping freely, and to be cautious automating anything that represents a human judgement, such as closing an issue.

What they are assessing

Toolchain understanding.

Model answer

Through the issue key. Putting the key in a branch name, commit message or pull request title makes the development panel on the issue show the related branches, commits, pull requests and builds. Combined with automation, this is what lets an issue transition when a branch is created or a pull request merges. For QA the practical value is being able to answer, from the issue alone, what code changed and whether it reached the environment under test, which otherwise requires asking a developer.

Trap to avoid

Assuming a merged pull request means the fix is testable. It means the code is merged, not deployed, and conflating the two sends defects back to testers before the build exists.

What they are assessing

Technical depth beyond the user interface.

Model answer

For things the interface makes slow or impossible: bulk-creating defects from an automated run, exporting issue data with its changelog for analysis that JQL cannot express, posting test results, generating a release report in a specific format, or auditing field completeness across a project. Authentication is by API token with basic auth on Cloud. The practical caution is rate limiting and pagination, since a naive script pulling several thousand issues one page at a time will be throttled, and expanding the changelog makes responses much larger than people expect.

Likely follow-up

How would you export every status transition for a set of issues?

What they are assessing

Configuration layering, which is where Jira is genuinely confusing.

Model answer

A field is defined once instance-wide. A field configuration decides whether it is required or hidden and what its description says. A screen is a layout of fields. A screen scheme maps screens to operations, so you can show different fields on create, edit and view. An issue type screen scheme then maps screen schemes to issue types, so a Bug can show severity and steps to reproduce while a Story does not. The practical consequence for QA is that a field missing on the create screen is the usual reason a mandatory field is never filled in.

What they are assessing

Awareness of a well known Jira failure mode.

Model answer

Performance and confusion. Custom fields are indexed instance-wide, so a large number degrades search and reindex time for everyone, not only the project that added them. They also proliferate duplicates, with three fields named some variation of environment created by three teams, which makes cross-project reporting impossible. For QA specifically it means the field you filter on may not be the field another team fills in. The discipline is to reuse existing fields, to use components and labels for lightweight categorisation, and to require a reporting justification before adding one.

What they are assessing

A small thing teams consistently get wrong.

Model answer

Sparingly and with an agreed vocabulary. Labels are free text with no validation, so without a convention you end up with regression, Regression and regression-test as three distinct labels, and every filter built on them is wrong. Where a categorisation is permanent and reportable, a component or a custom field is the right home. Labels are best for temporary, cross-cutting marks: a specific release concern, a themed test effort, or triage state during a bug bash.

What they are assessing

Interpersonal judgement, asked at senior level deliberately.

Model answer

I would look at my own reports first, because a pattern of rejections from one person is sometimes a pattern of reports that lack an environment, a build number or a clear expected result. If the reports hold up, I would raise it directly and privately, with examples, framing it as a shared problem about what information is needed rather than an accusation. If it continues, I would stop arguing in comments, which never works and leaves a bad record, and take the pattern to the leads with data: how many were rejected and later reopened, and what that cost in rework. Escalating first, before trying a conversation, is the thing that marks someone out as hard to work with.

Likely follow-up

How would you present that data without it reading as an attack?

What they are assessing

Agile process from the QA seat.

Model answer

A shared checklist a story must satisfy before it is called complete. From a QA standpoint I would insist on: acceptance criteria verified by someone other than the author, tests written and passing, no open defects of agreed severity against the story, regression impact considered, and the change actually deployed to a shared environment rather than working locally. The reason to fight for it is that a definition of done is the only lever that reliably stops testing being compressed, because without it a story is done when a developer says so and testing becomes a negotiation every sprint.

What they are assessing

Whether the candidate can design rather than operate.

Model answer

I would start from the questions the business will ask and work backwards, because configuration built without that becomes the fourteen-status workflow nobody uses. Typically those questions are what is blocking the release, where is quality worst, and is testing keeping up. That gives the minimum: a Bug issue type with the fields that make a report actionable, a defect workflow with real verification separated from resolution, Affects and Fix Version used properly, components aligned to the actual system, and a small set of shared filters and one dashboard. I would resist custom fields in the first months, since the ones requested on day one are rarely the ones needed by month three. And I would decide the test management question early, because retrofitting traceability onto a year of unlinked issues is far more expensive than linking from the start.

Likely follow-up

What would you deliberately leave out of the first configuration?

What they are assessing

Whether the candidate can push back on a bad metric constructively.

Model answer

I would agree with what they actually want, which is to know whether QA is working, and then explain why that particular number will not tell them. Defects found rewards volume, so it encourages splitting one problem into five tickets and raising trivia, and it punishes the most valuable QA work, which is preventing defects before they exist. It also drops when quality genuinely improves, so success looks like failure. Then I would offer alternatives that answer the real question: defects escaping to production, which is the one that matters, reopen rate, time from raised to resolved, and the proportion of production incidents that had a corresponding test. Offering a replacement rather than only objecting is what makes the pushback land.

Trap to avoid

Refusing the metric without proposing anything. The interviewer is assessing whether you can influence a decision, not whether you know the metric is flawed.

What they are assessing

Practical hygiene.

Model answer

Search before raising, which sounds obvious and is the step most often skipped under time pressure. Searching well means using distinctive text from the error rather than a paraphrase of the symptom, and including closed issues, since a returning defect is more useful linked to its original than raised fresh. Consistent summary conventions help enormously, because they make the search work. When a duplicate is found, link it rather than deleting it, since the duplicate often carries a different reproduction path that is genuinely useful.

What they are assessing

The hardest kind of report to write well.

Model answer

State the intermittency explicitly and quantify it: observed four times in roughly thirty attempts, rather than sometimes. Give everything that varied between attempts, since the cause is in there somewhere: data, timing, account, environment, concurrency. Attach evidence from an occurrence, with the timestamp, so backend logs can be correlated, because for an intermittent failure the server logs are usually more informative than the screenshot. State what you tried that did not reproduce it, which saves the developer repeating it. And resist the pressure to downgrade it because it is hard to reproduce, since intermittent defects in production are the ones that generate incidents.

Likely follow-up

How do you argue for prioritising an intermittent defect?

What they are assessing

A core QA metric and its implementation.

Model answer

Defect leakage is the proportion of defects that reached a later stage, usually production, rather than being caught in testing. In Jira I would track it with a field or label marking where a defect was found, such as environment found, with values for development, QA, UAT and production. Then the metric is a simple JQL count comparison per release. The field has to be set at creation time, because retrospectively deciding where something was found is guesswork, and the whole metric depends on that discipline.

Likely follow-up

What does a rising leakage rate tell you, and what does it not?

What they are assessing

Attention to the detail that saves the most time.

Model answer

Everything needed to reproduce the conditions rather than the steps: the build or version number, the environment name, the browser and version or the device and operating system version, the user role or account type, and anything relevant about the data state. The build number is the single most valuable item and the most frequently omitted, because without it nobody can tell whether a defect was fixed in a later build or is still present.

What they are assessing

A common two-stage workflow and its purpose.

Model answer

In a two-stage workflow, Resolved means the developer believes the work is done and it is ready for verification, and Closed means the reporter or a tester has confirmed it. The separation exists precisely so that fixed and verified are different states, which is the whole value. Teams that collapse them into one status lose the ability to answer how much work is sitting unverified, which is usually the real bottleneck late in a release.

What they are assessing

A practical query most testers eventually need.

Model answer

status CHANGED TO "In Test" BEFORE -5d AND status = "In Test" AND resolution IS EMPTY. The pattern matters more than the exact query: you combine a historical operator describing when it entered the status with a current state check confirming it has not moved since. It is the basis of most stale-work reporting, and it is far more useful than a plain created date, because an issue created months ago that moved yesterday is not stale.

Likely follow-up

How would you turn that into a recurring alert?

What they are assessing

Search behaviour, which has real gotchas.

Model answer

The tilde operator does a text search, so summary ~ "timeout" or the broader text ~ "timeout" which covers summary, description, comments and several other text fields. It uses the search index with stemming, so it matches word variants and ignores common stop words rather than doing a literal substring match. The practical limits are that it will not match partial words the way a wildcard would without an asterisk, it is case insensitive, and because it depends on the index, very recently edited issues can occasionally lag.

What they are assessing

Basic agile mechanics in Jira.

Model answer

The backlog is the ordered list of work not yet in a sprint, and in Jira it is a separate view where you rank items and plan sprints. The board shows the work currently in progress, which for Scrum means the active sprint and for Kanban means everything in the workflow columns. Ranking in the backlog is a drag-and-drop order stored as a rank field, which is why two people reordering simultaneously can produce surprising results.

What they are assessing

Flow thinking.

Model answer

A cap on how many items may sit in a column at once, shown as a warning when exceeded. QA cares because the testing column is usually where work accumulates, and a WIP limit is the mechanism that makes that visible and forces a response. Without it, the team keeps starting new work while testing falls behind, and the problem only surfaces at the end of the sprint when everything arrives at once. With it, the limit is hit mid-sprint and the team has to decide whether to help with testing or stop starting new work, which is the conversation that needed to happen.

What they are assessing

Communication, which separates senior candidates.

Model answer

In terms of risk and readiness rather than counts. Rather than saying 340 of 400 tests have passed, which invites the question of whether 85 percent is good, I would say which areas are verified, which are not yet covered and why, what the open defects would mean for a user, and what my recommendation is. A number without a judgement attached makes the stakeholder guess, and they will usually guess optimistically. I would also be explicit about what has not been tested at all, since that is the information most likely to be missing and most likely to matter.

Likely follow-up

How do you report when testing is genuinely incomplete and the date is fixed?

What they are assessing

Reading a standard chart with a QA eye.

Model answer

It plots remaining work against time in a sprint, with an ideal line for reference. The QA-relevant pattern is a flat line for most of the sprint followed by a cliff at the end, which almost always means stories were being completed by developers throughout but only closed once tested at the end. That shape says testing is a bottleneck squeezed into the final days, which is where defects get missed. A healthy chart steps down steadily, meaning work was genuinely finished, including verification, across the sprint.

What they are assessing

Testing strategy, in a tool context.

Model answer

Documented cases earn their maintenance cost when the same check must be repeated reliably by different people, when it is a regulatory or audit requirement, or when it is a candidate for automation. Everything else is usually better served by exploratory testing with a charter and notes, because a documented case that is run once and then maintained for two years is pure cost. In Jira terms that means a smaller, deliberately chosen set of test issues and a culture of recording exploratory sessions well enough that the coverage is visible even though it is not scripted.

What they are assessing

Awareness of the wider Atlassian toolchain.

Model answer

Confluence holds the documents and Jira holds the work items, with links in both directions. For QA that usually means the test strategy, test plan, environment details and release notes live in Confluence, while test cases, defects and executions live in Jira. The useful mechanism is embedding a Jira filter in a Confluence page, so a release readiness page shows live defect counts rather than a number typed in last week, which is otherwise the most common way a status document becomes wrong.

What they are assessing

Whether they have actually built one.

Model answer

A useful one is: when a Bug transitions to Resolved, assign it to the reporter and add a comment requesting verification. The problem it solves is that resolved defects routinely sat unverified because nobody owned the next step, and the backlog filled with issues that were neither open nor confirmed fixed. A second is flagging any Bug in Ready for Test for more than three days into a daily digest, which turns an invisible queue into a visible one. Both are bookkeeping rather than judgement, which is the kind of automation I trust.

What they are assessing

Basic query construction.

Model answer

It sorts the results. For a defect list I would usually order by priority descending then created ascending, so the most urgent appear first and, within a priority, the oldest first, which stops long-standing defects being perpetually overtaken by newer ones at the same level. For a triage queue, ordering by created ascending alone is often better, because the goal there is to process everything rather than to pick.

What they are assessing

Access model.

Model answer

A role is a project-scoped set of people, such as Developers, Testers or Administrators, populated independently in each project. A group is instance-wide. Roles are preferred in permission schemes because one scheme can then serve many projects while each project controls its own membership, and because a project lead can add someone to a role without needing a Jira administrator. Granting permissions directly to groups produces a scheme per project and a permanent dependency on administrators for routine access changes.

What they are assessing

Data lifecycle awareness.

Model answer

Closing is not a Jira operation as such: a project is usually wound down by moving its issues to a resolved state and removing it from boards. Archiving, available on Premium and on Data Center, makes the project and its issues read-only and removes them from search and indexes while preserving them. Deleting removes the project and all its issues permanently, and the issue keys are not reusable in a way that restores history. The QA-relevant point is that archived issues disappear from JQL results, so a historical defect report that used to work can silently return fewer rows after an archive.

What they are assessing

Deployment awareness, which affects what is possible.

Model answer

Cloud is Atlassian-hosted and updated continuously, with a REST API that differs in places from the server API and with app availability determined by the Marketplace for Cloud. Data Center is self-hosted, controlled by the organisation, and supports deeper customisation including server-side scripting apps. Server, the older single-node self-hosted option, reached end of support in 2024. It matters to QA because the available add-ons, the API surface and the ability to script are different, so an approach that worked at one employer may not be available at the next.

What they are assessing

Making invisible work visible.

Model answer

By giving it an issue so it is planned and visible rather than absorbed. A task per regression cycle or exploratory charter, estimated and pulled into the sprint like anything else. The argument for it is straightforward: work that is not on the board is not accounted for in capacity, so the team consistently commits to more than it can deliver and the shortfall lands on testing. The counter-argument, that it clutters the board, is usually really an objection to seeing how much time testing takes.

Likely follow-up

How do you estimate a regression cycle?

What they are assessing

Practical collaborative testing.

Model answer

A time-boxed session where a mixed group, including developers, product and support, tests a feature together to find defects quickly. In Jira I would prepare by agreeing a label so everything raised is findable, defining the scope and the environment, and making sure accounts and data are ready beforehand so the session is not spent on setup. Afterwards the label gives a single filter to triage from, which is the part that usually gets skipped and is what determines whether the session produced anything lasting.

What they are assessing

Interpreting a number rather than defending it.

Model answer

By establishing what changed before offering a conclusion, because the count on its own supports several contradictory stories. More defects can mean a larger or riskier feature set, a new tester finding things nobody had looked at, a deliberate exploratory push, an environment problem generating noise, or genuinely worse code. I would break it down by area, severity and origin, and say which of those explains the rise. The answer that matters is not whether the number went up but whether the risk went up, and those frequently move in opposite directions.

What they are assessing

Change management at lead level.

Model answer

I would write definitions with concrete examples from the team’s own product rather than generic wording, because critical and major mean nothing until someone sees a familiar example under each. Then I would calibrate rather than announce: take thirty recent defects, have the leads classify them independently, and discuss the disagreements. That exercise does more than any document, because it surfaces that the disagreement was real rather than a documentation gap. I would keep the scale short, four levels at most, since longer scales produce false precision and endless argument about the middle.

Likely follow-up

What would you do about the existing backlog with no severities set?

What they are assessing

Vocabulary in tools such as Xray and Zephyr.

Model answer

A test case is the definition of what to check, written once and reused. A test execution is a record of running a set of those cases against a specific build or environment at a point in time, holding the results. The separation is what lets you say this test passed in build 42 and failed in build 43, which a single status field on the test case cannot express. Candidates who have only improvised test management inside plain Jira often have not encountered this distinction, and it is usually what the question is checking.

What they are assessing

Closing the feedback loop.

Model answer

By linking the Jira Service Management incident to a Bug in the development project, and the Bug to the original story or change that introduced it. Then the question worth asking is whether a test existed for that behaviour: if yes, why did it pass, and if no, should one exist now. I would record that answer on the issue rather than in a retrospective document, because it is the only way the pattern becomes queryable later. Over time that linkage is what tells you which areas repeatedly escape, which is far more actionable than a count of incidents.

What they are assessing

A small thing with a large effect on whether Jira is used.

Model answer

It maps events, such as issue created or commented, to recipients, such as the reporter, assignee or watchers. You change it because the defaults are noisy: on a busy project everyone receives mail for everything, so people filter Jira mail into a folder they never read, and then genuinely important notifications are missed. Tightening it so people are notified about issues they report, are assigned or watch is usually the difference between a tool people respond to and one they ignore.

What they are assessing

A genuine judgement call with no universal answer.

Model answer

Usually not, if the story has not yet been delivered. A defect found while the story is still in progress is simply unfinished work, and raising a Bug for it inflates defect counts, distorts the quality picture and creates administration for no benefit. Once the story is marked done, or has been released, anything found afterwards should be a Bug, because at that point it is a failure of something previously declared complete. The boundary worth defining explicitly with the team is exactly where done falls, since that is what the rule hinges on.

Trap to avoid

Insisting every issue found must be logged as a bug. It produces metrics where a careful team looks worse than a careless one.

What they are assessing

Coverage gap analysis.

Model answer

With a test management add-on there is usually a dedicated coverage report, which is the right tool. In plain JQL the closest is fixVersion = "2.5.0" AND issuetype = Story AND issueLinkType != "is tested by", though link-type filtering is limited and behaves differently across versions, so in practice I would use issueFunction from Scriptrunner if available or export and analyse outside Jira. The honest answer is that native JQL handles links poorly, and knowing that boundary is more useful than producing a query that looks right and quietly misses issues with no links at all.

What they are assessing

Organisational problem solving.

Model answer

I would separate what genuinely must be consistent from what can stay different. A single report needs agreement on a small number of things: issue types, the definition of a defect, severity values, and what resolved means. Workflows, board layouts and local fields can differ without breaking the report. Trying to standardise everything is where these efforts usually die, because it asks two working teams to stop working the way that suits them for the benefit of a report neither of them reads. I would also check whether the report is answerable at all from existing data before asking anyone to change, since sometimes the request is for a number nobody has ever actually recorded.

Likely follow-up

What if one team is on a team managed project and the other is not?

What they are assessing

A considered overall view, used as a closing question.

Model answer

Four things. Defects that are readable months later, meaning environment, build and evidence are present as a matter of course rather than when someone has time. A workflow where fixed and verified are distinct states, so nobody can close their own work. Fields that are actually used, which in practice means far fewer of them than most instances have. And reports that drive a decision rather than decorate a status meeting. The underlying test is whether people trust what Jira says. Once a team starts keeping a private spreadsheet because the board is not accurate, the tool has stopped working, regardless of how well it is configured.