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

  1. Gather defects

    Advertisement
    • Defects logged by testers, users, or automated tools enter Jira as Bug issues in the backlog or a defect queue.

  2. Schedule triage meetings

    • Meet with testers, developers, project managers, and product owners to review new and existing defects.

  3. 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

  1. Prioritize bugs

    • Assign priority values (Blocker, Critical, Major, Minor) based on:

      • Impact on users

      • Functionality

      • Deadlines

      • Release schedules

  2. Assign bugs

    • Assign to the responsible developer or team via the Assignee field.

  3. Link related issues

    • Use issue linking (duplicates, blocks, relates to) for related or duplicate bugs.

  4. Update status

    • Transition the bug (e.g., Open → In Progress) using workflow transitions.

  5. Add comments and communicate

    • Clarify with comments and @mentions.

  6. Track and report

    • Use filters and dashboards to monitor defect metrics such as:

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:

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:

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

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

  • Jenkins

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.