Scenario Based Jira Interview Questions for QA Engineers
How Do You Handle Defect Triage in Jira?
Defect triage is the process of reviewing, prioritizing, and assigning reported defects to the right team members for fixing.
It ensures the team focuses on the most critical bugs first and avoids duplicate or irrelevant defects.
Step-by-step
-
Gather defects
Advertisement-
Defects logged by testers, users, or automated tools enter Jira as Bug issues in the backlog or a defect queue.
-
-
Schedule triage meetings
-
Meet with testers, developers, project managers, and product owners to review new and existing defects.
-
-
Review and analyze bugs
-
Open each bug and check:
-
Description and steps to reproduce
Severity and priority
Attachments
Whether it's reproducible or a duplicate
-
Prioritize bugs
-
Assign priority values (Blocker, Critical, Major, Minor) based on:
-
Impact on users
-
Functionality
-
Deadlines
-
Release schedules
-
-
-
Assign bugs
-
Assign to the responsible developer or team via the Assignee field.
-
-
Link related issues
-
Use issue linking (duplicates, blocks, relates to) for related or duplicate bugs.
-
-
Update status
-
Transition the bug (e.g., Open → In Progress) using workflow transitions.
-
-
Add comments and communicate
-
Clarify with comments and @mentions.
-
-
Track and report
-
Use filters and dashboards to monitor defect metrics such as:
-
Bug counts
-
Resolution times
-
-
Jira Tools That Help
-
Filters (saved views for untriaged bugs)
-
Dashboards (bugs by priority/status/assignee)
-
Notifications (alerts on updates)
-
Custom fields (environment, root cause)
Handling a Reopened Bug in the Middle of a Sprint
Step 1: Reopen the Bug
-
Change status from Closed/Resolved back to Reopened.
-
Add a comment explaining why:
-
Issue still persists
-
New related defect found
-
Step 2: Notify the Team
-
Assign it back to the original developer.
-
@mention the QA Lead, Scrum Master, or Product Owner.
Step 3: Assess Impact and Priority
Discuss with the PO/Scrum Master whether it's critical enough to fix in the current sprint.
-
If it's a blocker, prioritize it back into the sprint backlog.
-
Otherwise, defer it.
Step 4: Update the Sprint Backlog
If it must be fixed now, add it and adjust sprint scope accordingly.
Step 5: Fix and Retest
-
Developer fixes it again.
-
QA retests.
-
Mark Resolved/Closed if it passes; otherwise, repeat.
Step 6: Document Everything
Keep detailed comments and attachments for the bug's lifecycle.
Useful for:
-
Retrospectives
Interview Answer
"If a bug is reopened during a sprint, I immediately change its status to 'Reopened' and document why. I assign it back to the developer, notify the team, and then discuss with the Scrum Master or PO to evaluate its priority. If it's critical, we include it in the current sprint and adjust scope; if not, we schedule it for the next sprint. The developer fixes it, QA retests, and proper documentation ensures transparency."
What If a Developer Closes a Bug Without Fixing It?
Review the Developer's Comments
The developer may have closed it because:
-
They thought it's not a bug.
-
They couldn't reproduce it.
-
It's a duplicate/already fixed.
-
It's low priority or out of scope.
Re-validate the Issue
-
Reproduce it with the same steps and test data.
-
Capture screenshots, videos, and logs.
-
Confirm it still exists in the current build.
Reopen the Bug
Attach all supporting evidence and clarify the steps to reproduce if they were unclear.
Discuss with the Developer
Example:
"Hi [Dev], I noticed [BUG-101] was closed, but I can still reproduce it on build #123. I've attached the steps and a video — can we recheck together?"
Keep it collaborative, not blame-oriented.
Escalate if Needed
Raise it in:
-
Daily stand-up
-
Defect triage meeting
Involve:
-
Product Owner
-
Business Analyst
-
QA Lead
| Activity | Purpose |
|---|---|
| Check comments | Understand the reason for closure |
| Re-test | Reproduce and gather proof |
| Reopen bug | With updated steps and attachments |
| Communicate | Discuss calmly with the developer |
| Escalate | Involve PO or lead if needed |
Finding a Blocker Bug During Regression
Immediately Log the Bug
Include:
-
Issue Type: Bug
-
Summary clearly marked as a blocker
-
Priority: Blocker/Highest
-
Environment (browser, OS, build)
-
Detailed steps
-
Actual vs Expected result
-
Attachments (screenshots, recordings, logs)
-
Labels like regression, blocker
-
Affects Version
-
Assign to the developer or lead
Notify the Team Immediately
Example:
"Found a blocker [BUG-1234] during regression — the app crashes on login. Logged in to Jira with steps and videos. Please prioritize."
Inform:
-
Scrum Master
-
QA Lead
-
Product Owner
Update the Jira Issue with Progress
-
Monitor workflow status.
-
Add comments.
-
Link related test cases.
-
Add watchers.
Block Regression or Release if Needed
If it affects critical flows like:
-
Login
-
Payment
-
Checkout
Then:
-
Pause regression.
-
Hold the release until fixed.
-
Mark the test case as Blocked in Zephyr/Xray.
Retest and Close
Once fixed:
-
Retest in the correct environment.
-
Move to Resolved/Done.
Example:
"Retested on build 2.3.4 — issue fixed. Verified login flow."
Reassigning Bugs When a Tester Goes on Leave
Identify All Assigned Bugs
Use JQL:
assignee = <tester_name> AND status != Done AND type = Bug
Inform the Team Lead/Scrum Master
Communicate the leave status and pending bugs during stand-up or via email.
Assess Other Testers' Workload
Example JQL:
assignee in (User1, User2, User3) AND status != Done
Bulk Reassign
-
Tools → Bulk Change
-
Select bugs
-
Edit Issues
-
Set a new Assignee
-
Confirm
Add Comments for Traceability
Example:
"Reassigned due to [Tester]'s leave. Assigned to [New Tester] for continuity."
Use Labels (Optional)
Example:
reassigned-due-to-leave
A Backup Assignee custom field helps in large teams.
Track Progress
Use:
-
Dashboards
-
Filters
-
Sprint board
Example filter:
labels = reassigned-due-to-leave AND status != Done
Logging and Tracking Automation Test Failures
Analyze the Failure
Determine whether it's:
-
A real code bug
-
A network/environment issue
-
An incorrect automation script
Use:
-
Logs
-
Screenshots
-
Application behavior
Log the Defect
Include:
-
Short title
-
Reproduction steps
-
Actual vs Expected
-
Screenshot
-
Logs
-
Failed test evidence
-
Test case ID or Traceability Matrix link
Link the Test Case to the Bug
Use:
-
Linked Issues in Jira
-
TestRail
-
Zephyr
-
Xray
Communicate
-
Assign to the correct developer.
-
Add labels (regression, blocker, sprint number).
After the Fix
-
Re-test.
-
Close if passed.
-
Reopen if still failing.
Automation Perspective
"In automation, I capture the failure in the ITestListener.onTestFailure() method to log the issue, attach a screenshot, and even auto-create Jira tickets via the API if needed."
Tools Worth Mentioning
-
Jira / Bugzilla / Mantis
-
TestRail / Zephyr / Xray
-
TestNG / Allure / Extent
-
Log4j / Screenshot capture
What Not to Say
-
Don't say "I just raised a bug."
-
Don't forget traceability and the retest workflow.
-
Don't ignore test environment or test data issues.
Story Marked "In Review," but No PR Exists
Cross-check Jira and Git Integration
Confirm:
-
PR exists
-
Code is pushed
-
Reviewer is assigned
Communicate with the Developer
Comment:
"Status moved to In Review, but no PR is linked. Please confirm the code is pushed and the PR is created."
Optionally assign it back.
Don't Test Without a PR
Testing begins only after proper developer review.
Document
Add a label like:
-
Awaiting PR
-
Blocked
Escalate if Repeated
Inform the Scrum Master or lead.
Bonus (Maturity)
"We have an automation rule in Jira that prevents a story from moving to 'In Review' unless a PR is linked, which reduces such mismatches."
Checking How Many Times a Bug Was Reopened
Open the Bug
Go to the issue (e.g., BUG-123).
Activity → History
Review:
-
Status changes
-
Field updates
-
Assignee changes
-
User actions
Count Reopen Events
Look for:
-
Resolved → Reopened
-
Closed → Reopened
Each rollback indicates a failed fix or missed scenario.
Add a Comment / Raise a Flag
Example:
"Bug reopened 3 times, potential root cause needs deeper analysis."
Raise it during retrospectives if it's a pattern.
Bonus
"We also have a Jira filter (JQL or automation) to identify bugs that were reopened more than once."
Tracking Release Test-Execution Completeness
Tag Test Cases
Add a release tag (e.g., Release 1.5) in:
-
Xray
-
Zephyr
-
TestRail
Execute the Test Cycle
Example:
Cycle_1_Release_1.5
Monitor the Test Execution Report
Track:
-
Passed
-
Failed
-
In Progress
-
Blocked
-
Not Executed
100% execution means Not Executed = 0.
Use Filters or JQL
project = QA
AND fixVersion = "Release 1.5"
AND type = Test
AND status != Executed
Dashboard View (Optional)
Use gadgets such as:
-
Test Execution Gauge
-
Test Run Progress
-
Requirement Coverage
Bonus
"I also maintain a test summary sheet for stakeholders showing total tests, execution %, pass %, defect count, and blocker bugs — this gives confidence on release readiness."
Managing the Bug Life Cycle in Jira
When a bug is found (manual or automated), log it with:
-
Clear summary
-
Detailed steps
-
Actual vs Expected
-
Severity
-
Priority
-
Screenshots/logs
-
Environment
-
Link to the test case or user story
Bug Life Cycle
| Status | Description |
|---|---|
| Open / To Do | QA reports the bug |
| In Progress | Developer starts the fix |
| Code Review | Peer review completed (if applicable) |
| Ready for QA / Resolved | Developer fixes and hands over to QA |
| Reopened | QA retests and finds it not fixed |
| Closed | QA verifies and confirms it's resolved |
| Deferred / Won't Fix | Not fixed in the current release (if approved) |
Strong Practices
-
Use labels (UI, Backend, Regression).
-
Use components (Login, Payments).
-
Link every bug to a user story or test case.
-
Attach logs and HAR files.
-
Reopen with notes when fixes fail.
During sprint reviews, use filters to show bugs per sprint or developer.
Common Jira Challenges and Solutions
Complex Workflow Customization
Challenge
Workflows become complex with many statuses and transitions.
Resolution
-
Simplify workflows.
-
Remove unnecessary transitions.
-
Use Workflow Designer.
-
Train the team.
Managing a Large Number of Issues
Challenge
Hard to track and prioritize.
Resolution
-
Use Filters.
-
Use JQL.
-
Use Dashboards.
-
Add Automation Rules.
-
Perform regular backlog grooming.
Permission and Access Issues
Challenge
Users cannot access projects.
Resolution
-
Configure Permission Schemes.
-
Use role-based access.
-
Document permissions.
Notification Overload
Challenge
Too many emails.
Resolution
-
Configure notification schemes.
-
Educate users about watchers.
-
Use Slack/Teams.
Integration with Other Tools
Examples:
-
Jenkins
-
Confluence
-
Plugins
Resolution
-
Follow vendor documentation.
-
Test integrations in staging.
-
Troubleshoot using logs, permissions, and API tokens.
-
Collaborate with DevOps/QA.
FAQs
1. How do you handle defect triage in Jira?
Gather defects, hold triage meetings, review and analyze each bug, prioritize by impact, assign to owners, link related issues, update status, communicate, and track metrics via filters and dashboards.
2. What do you do when a bug is reopened mid-sprint?
Reopen it with a reason, reassign it to the developer, notify the team, assess the priority with the PO/Scrum Master, adjust the sprint scope if it's critical, then fix, retest, and document.
3. What if a developer closes a bug without fixing it?
Review their comments, re-validate and reproduce the bug, reopen it with evidence and clear steps, discuss collaboratively with the developer, and escalate to the PO/lead if needed.
4. How do you report a blocker bug found during regression?
Log it immediately with Blocker priority and full details, notify the team, track its progress, pause regression or hold the release if a critical flow is affected, then retest and close.
5. How do you reassign bugs when a tester goes on leave?
Use JQL to find their open bugs, inform the lead, check other testers' workload, bulk-reassign, add comments and a label for traceability, and track progress.
6. How do you check how many times a bug was reopened?
Open the bug's Activity → History tab and count the status rollbacks from Resolved/Closed to Reopened; flag repeat patterns for root-cause analysis.
7. How do you confirm that test execution for a release is 100% complete?
Tag test cases to the release, run the test cycle, monitor the execution report until Not Executed = 0, and validate with JQL or dashboard gadgets.