50 JIRA & Agile Interview Questions for Testers (2026 Guide)

Nearly every QA role in India today runs in Agile/Scrum and tracks work in JIRA. Interviewers use these questions to check whether you can actually work in a sprint team — not just test.

Here are 50 JIRA and Agile interview questions for testers in five groups: Agile fundamentals, Scrum ceremonies and roles, the tester’s role in a sprint, JIRA and defect management, and JQL, test management and real scenarios.

Agile fundamentals (1–10)

1. What is Agile?
Agile is an iterative way of delivering software in small, working increments with continuous feedback. It values individuals and interactions, working software, customer collaboration and responding to change (the four values of the Agile Manifesto), supported by 12 principles.

2. Agile vs Waterfall — key differences for a tester?
In Waterfall, testing is a separate phase after development and requirements are fixed up front. In Agile, testing happens inside every sprint alongside development, requirements evolve through user stories, and testers collaborate daily with developers and the product owner.

3. What are Scrum, Kanban and SAFe?
Scrum works in fixed-length sprints with defined roles and ceremonies. Kanban is a continuous flow with a visual board and WIP (work-in-progress) limits, no sprints. SAFe is a framework for scaling Agile across many teams with Program Increments (PI) and release trains.

4. What is a user story?
A short description of a feature from the user’s view: “As a role, I want goal, so that benefit.” It comes with acceptance criteria that define when it is done. A good story follows INVEST: Independent, Negotiable, Valuable, Estimable, Small, Testable.

5. What are acceptance criteria?
Conditions a story must meet to be accepted, written before development. Testers use them to design test cases. Often written in Given/When/Then (Gherkin) form, e.g. “Given a registered user, when they enter a wrong password three times, then the account is locked for 15 minutes.”

6. What is an Epic, a Story, a Task and a Sub-task?
An Epic is a large body of work split into stories. A Story is a user-facing requirement deliverable in one sprint. A Task is technical work that is not a user feature. Sub-tasks break a story or task into pieces such as “Write test cases” or “Automate API tests”.

7. What are story points?
A relative estimate of effort, complexity and risk — not hours. Teams often use Fibonacci numbers (1, 2, 3, 5, 8, 13). Testers should estimate together with developers because testing effort is part of the story.

8. What is velocity?
The average number of story points a team completes per sprint. It helps plan how much work to commit to; it should not be used to compare teams.

9. What is the Definition of Ready and Definition of Done?
DoR: a story is ready for a sprint when it is clear, estimated, has acceptance criteria and dependencies resolved. DoD: a shared checklist for “done” — code reviewed, unit tests passed, acceptance criteria tested, no open critical bugs, automation updated, deployed to the test environment, documentation updated.

10. What is shift-left testing?
Testing earlier in the lifecycle: reviewing requirements and designs, joining refinement, writing test cases before code, testing APIs before the UI is ready and automating in the same sprint. It finds defects when they are cheapest to fix.

Scrum roles and ceremonies (11–20)

11. What are the Scrum roles?
Product Owner (owns and prioritises the backlog), Scrum Master (facilitates the process and removes blockers) and Developers (the cross-functional team that builds and tests — testers are part of this group).

12. What are the Scrum events (ceremonies)?
Sprint Planning, Daily Scrum (stand-up), Sprint Review, Sprint Retrospective, and the Sprint itself. Backlog refinement (grooming) is an ongoing activity most teams hold as a regular meeting.

13. What does a tester do in sprint planning?
Clarifies acceptance criteria, raises testability and data questions, estimates testing effort, identifies regression and automation needs, and flags environment or dependency risks before the team commits.

14. What do you say in a daily stand-up?
What I tested yesterday, what I will test today and any blockers — e.g. “Tested story 214 login flow, raised two bugs; today I will test the payment story and update API automation; blocked because the staging build is failing.” Keep it under a minute.

15. What happens in the sprint review?
The team demonstrates completed work to the product owner and stakeholders and gathers feedback. Testers may demo features and share quality status — what is done, known issues and test coverage.

16. What is a sprint retrospective?
A meeting after the review where the team discusses what went well, what did not and what to improve. Testers can raise points like late builds, unclear stories, flaky environments or missing unit tests, and agree on action items.

17. What is backlog refinement and why should testers attend?
The team reviews upcoming stories, clarifies details, splits large items and estimates. Testers find gaps and edge cases early, which prevents defects and rework later.

18. How long is a sprint?
Usually 1–4 weeks; two weeks is the most common in Indian companies. The length stays fixed so the team can measure velocity.

19. What is a burndown chart?
A graph of remaining work (story points or tasks) against days in the sprint. A flat line suggests blocked work; a sharp drop at the end often means testing happened too late.

20. What is a spike?
A time-boxed research story to explore an unknown — for example, evaluating Playwright for the project or investigating how to test a third-party payment flow — producing knowledge rather than shippable features.

The tester’s role in Agile (21–30)

21. What is the role of QA in an Agile team?
Quality advocate for the whole team: review stories, define acceptance tests with the PO, test features as soon as they are ready, automate regression, test APIs early, pair with developers, give quick feedback and help the team meet the Definition of Done.

22. How do you test when requirements keep changing?
Keep tests close to acceptance criteria, update them as stories change, communicate impact during refinement, favour exploratory testing for new areas, and rely on automated regression to protect existing features.

23. How do you finish testing within a short sprint?
Start test design on day one, test stories incrementally (not all at the end), use API testing before UI is ready, automate in the same sprint, ask developers to ship small stories early and use risk-based prioritisation if time is short.

24. What are the Agile testing quadrants?
A model by Brian Marick (popularised by Crispin and Gregory): Q1 technology-facing tests that support the team (unit, component), Q2 business-facing tests that support the team (functional, story tests), Q3 business-facing tests that critique the product (exploratory, UAT, usability), Q4 technology-facing tests that critique the product (performance, security).

25. What is BDD and how is it used in Agile?
Behaviour-Driven Development: the PO, developer and tester agree on examples written in Gherkin (Given/When/Then) before development. The same scenarios become automated tests with tools like Cucumber, so requirements and tests stay in sync.

26. What is the “three amigos” meeting?
A short discussion of a story between business (PO/BA), development and testing perspectives before development starts, to agree on behaviour, edge cases and acceptance criteria.

27. What is regression testing in Agile?
Re-testing existing features each sprint to make sure new changes did not break them. Because sprints are short, regression is mostly automated (smoke on every build, full suite nightly or before release) with manual exploratory checks on risky areas.

28. What is CI/CD and the tester’s part in it?
Continuous Integration builds and tests code on every commit; Continuous Delivery/Deployment releases it automatically. Testers add automated tests to the pipeline, keep them fast and reliable, and define quality gates that stop bad builds.

29. How do you handle a bug found at the end of the sprint?
Assess severity and impact with the PO. Critical bugs block the story from being “done” and are fixed if possible; minor ones can be logged and prioritised in the backlog with the PO’s agreement. Never quietly mark a story done with a known critical issue.

30. What metrics do Agile QA teams track?
Defect leakage (bugs found after release), defects per story, automation coverage, test pass rate, mean time to detect/fix, escaped defects by severity, and flaky test rate. Use them to improve, not to blame.

JIRA and defect management (31–40)

31. What is JIRA?
JIRA is Atlassian’s work-management tool used by Agile teams for backlogs, sprints, boards, user stories and bug tracking. It integrates with Confluence, Git (Bitbucket/GitHub), CI tools and test management apps such as Zephyr Scale and Xray.

32. What issue types are used in JIRA?
Epic, Story, Task, Sub-task and Bug by default; teams may add custom types like Test, Test Execution or Improvement (from Xray/Zephyr or admin configuration).

33. How do you raise a good bug in JIRA?
Clear summary (what is broken, where), environment and build, preconditions, numbered steps to reproduce, expected vs actual result, severity and priority, screenshots/video/logs, test data, and links to the story. See our bug report template.

34. Explain a typical defect life cycle in JIRA.
New/Open → Assigned → In Progress → Fixed (Ready for QA) → Retest → Closed. Alternative paths: Reopened (fix failed), Rejected/Not a Bug, Duplicate, Deferred/Won’t Fix, and Cannot Reproduce. The exact statuses depend on the project workflow.

35. Severity vs priority with an example?
Severity is the impact on the system (set by QA); priority is the urgency of fixing (set by PO/lead). High severity, low priority: app crashes on an old OS version used by 0.1% of users. Low severity, high priority: company logo misspelt on the home page before a launch.

36. What is a JIRA workflow?
The set of statuses and transitions an issue moves through (e.g. To Do → In Progress → In Review → In QA → Done), with conditions, validators and post-functions configured by admins. Testers should know who moves tickets into and out of “In QA”.

37. What are components, labels, fix versions and sprints in JIRA?
Components group issues by module (Payments, Login). Labels are free tags (regression, ui). Fix Version is the release the fix ships in. Sprint is the sprint the issue is planned in. They make filtering and reporting accurate.

38. Scrum board vs Kanban board in JIRA?
A Scrum board shows work committed for the active sprint and has a backlog, sprint planning and burndown. A Kanban board shows a continuous flow of work with WIP limits and a cumulative flow diagram, without sprints.

39. How do you link issues?
Use “Link issue” with types such as blocks / is blocked by, relates to, duplicates, is caused by, or link a bug to the story it was found in. Links help with traceability and impact analysis.

40. What dashboards and reports do QA use in JIRA?
Sprint report, burndown chart, created vs resolved chart, filter results gadget for open bugs by priority, two-dimensional filter statistics (bugs by component vs status) and test execution reports from Zephyr/Xray.

JQL, test management and scenarios (41–50)

41. What is JQL?
JIRA Query Language — a SQL-like syntax for searching issues by fields, operators and functions. Saved JQL filters power dashboards, boards and subscriptions.

42. Write useful JQL queries for testers.
A few you should know:

-- open bugs in current sprint
project = PAY AND issuetype = Bug AND sprint in openSprints() AND status != Done

-- my bugs reopened in last 7 days
issuetype = Bug AND reporter = currentUser() AND status changed to Reopened after -7d

-- critical/high bugs not yet fixed for a release
issuetype = Bug AND priority in (Highest, High) AND fixVersion = "2.4.0" AND resolution = Unresolved

-- stories ready for QA
project = PAY AND issuetype = Story AND status = "Ready for QA" ORDER BY priority DESC

-- bugs created this week by component
issuetype = Bug AND created >= startOfWeek() AND component = Payments

43. What JQL functions are useful?
currentUser(), openSprints(), closedSprints(), startOfDay()/startOfWeek(), endOfMonth(), membersOf("qa-team"), releasedVersions() and unreleasedVersions(), plus the WAS and CHANGED operators for history.

44. Which test management tools work with JIRA?
Zephyr Scale and Zephyr Squad, Xray, TestRail (via integration), qTest and QMetry. They add test cases, test cycles/executions, traceability to stories and execution reports inside JIRA.

45. How do you maintain traceability in JIRA?
Link each test case to the story it covers, link bugs to the failed test and the story, and use a traceability report (Xray/Zephyr) or a requirement traceability matrix to show coverage. See our RTM template.

46. A developer says “it works on my machine” and rejects your bug. What do you do?
Re-test on the latest build, check environment and data differences, add clear steps, logs, video and network details, and reproduce it together with the developer. If it is environment-specific, record that in the bug. Stay factual and collaborative — the goal is the fix, not winning.

47. The build arrives on the last day of the sprint. How do you handle it?
Raise it in stand-up early, test highest-risk stories first, use API tests and automation for quick coverage, agree with the PO what can be accepted, and bring it up in the retrospective so builds come earlier next time (smaller stories, earlier merges).

48. The PO wants to release with open bugs. What do you do?
Present the facts — severity, user impact, workaround and risk — and let the PO decide. Document the decision, the known issues and release notes. Escalate only if a critical/security issue is being ignored.

49. How do you prioritise testing when time is limited?
Use risk-based testing: business-critical and high-usage flows (login, payments, checkout), recently changed areas, areas with past defects and integrations come first. Run the automated smoke and regression suites and do focused exploratory testing on changes.

50. Describe your sprint process as a tester in 60 seconds.
Sample answer: “We run two-week sprints in JIRA. In refinement I review stories and add acceptance criteria and test scenarios. After planning I write test cases in Zephyr linked to the stories. As stories move to ‘Ready for QA’ I test on the QA environment, log bugs with steps, video and logs, and retest fixes. I automate stable scenarios in the same sprint, our smoke suite runs in Jenkins on every build, and before the sprint review I share a test summary with open bugs by priority.”

Quick revision: Agile terms for testers

FAQs

Do freshers get asked JIRA questions?

Yes — usually how to raise a bug, the defect life cycle, severity vs priority and what a user story is. Practise with a free JIRA Cloud account.

Is JIRA certification required for QA jobs?

No. Practical knowledge matters more. A short Atlassian or Scrum (PSM/CSM) certification can help but is not mandatory.

What is the difference between JIRA and Zephyr/Xray?

JIRA tracks stories, tasks and bugs. Zephyr and Xray are add-ons that add test cases, test cycles and execution reports inside JIRA.

How should I mention JIRA on my resume?

Show what you did with it: “Logged and tracked 300+ defects in JIRA, created JQL dashboards for sprint bug status, and managed test cycles in Zephyr Scale.”