Jira Defect Management
Finding a bug is only half the job. The other half is getting it fixed: logging it so a developer can reproduce it, moving it through the workflow, deciding what matters most before a release, and communicating risk to the team, management and clients. This guide covers defect management in Jira the way interviewers ask about it — with the scenario answers they expect.
Logging a Defect in Jira: Step by Step
1. Before you log it
- Reproduce it at least twice and note whether it happens every time or intermittently.
- Search Jira for duplicates — a quick JQL search saves everyone time (e.g.
project = SHOP AND issuetype = Bug AND text ~ "coupon"). - Isolate it — does it happen in other browsers, other users, other data?
2. Gather the evidence
Screenshots, a short screen recording, console and network logs, API responses, the test data used, and the environment: browser and version, device, operating system, application build.
3. Fill in the fields
| Field | Good example |
|---|---|
| Summary | Cart: total not updated after removing an item |
| Environment / Build | QA · build 3.2.1 · Chrome 131 · Windows 11 |
| Steps to reproduce | 1. Add 2 items 2. Open cart 3. Remove one item |
| Expected result | Total shows the price of the remaining item |
| Actual result | Total still includes the removed item until the page is refreshed |
| Severity / Priority | High / High — customers may be charged the wrong amount |
| Attachments | Recording, screenshot of the network response |
| Links | Relates to story SHOP-310; found by test case TC-88 |
4. Create it and notify
Assign it according to your team's process (to the developer, the team lead or the triage queue), mention the owner if it's urgent, and link it to the story and test case for traceability: Requirement → Test case → Defect.
For more on writing bug reports and fields, see The Complete Jira for Testers Guide and Working With Jira Issues.
The Bug Workflow (Status Flow)
A typical Jira defect flow — your company's workflow may use different names:
New/Open → Assigned/In Progress → Fixed/Ready for Retest → Verified → Closed, with Reopened when a retest fails.
| Status | What happens | Who |
|---|---|---|
| New / Open | Defect logged and waiting for review | QA |
| Assigned / In Progress | Developer investigates and fixes | Developer |
| Fixed / Ready for Retest | Fix deployed to the test environment | Developer |
| Verified / Closed | QA confirms the fix and checks related areas | QA |
| Reopened | The issue still occurs — add new evidence | QA |
Other outcomes: Rejected / Not a Bug, Duplicate, Cannot Reproduce, Deferred and Won't Fix. When you reopen a bug, always add what you retested, on which build, and new evidence — "still not working" alone starts an argument.
Defect Aging
Defect aging is how long a defect stays unresolved after it was logged. Old, unresolved bugs delay releases and hide risk. Track it with a saved filter and a dashboard gadget:
-- Open bugs older than 14 days, oldest first
project = SHOP AND issuetype = Bug AND resolution = Unresolved AND created <= -14d ORDER BY created ASC
Agree an aging threshold per priority (for example, critical bugs within 2 days) and escalate anything that exceeds it at stand-up or triage.
Defect Triage Meetings
- Before: QA prepares the list of new and disputed defects with evidence.
- Who attends: QA lead, developers or dev lead, and the product owner.
- Decide for each defect: is it valid, its severity and priority, the owner, and the target fix version — or defer it.
- After: update Jira immediately (status, assignee, priority, fix version, comments) so the board reflects the decisions.
Severity vs Priority: Quick Examples
Severity measures technical impact; priority measures business urgency. They're set independently, and every combination happens:
| Defect | Severity | Priority | Why |
|---|---|---|---|
| Login fails for all users | High | High | Users blocked from the app |
| Wrong total in billing | High | High | Financial and legal impact |
| App crashes in a rarely used legacy report | High | Low | Serious failure, but very few users affected |
| Company logo missing on the home page | Low | High | No functional impact, but visible to every visitor |
| Order confirmation email not sent | Medium | High | Orders work, but customers lose trust |
| Font mismatch on the settings page | Low | Low | Cosmetic |
| Typo in a tooltip | Low | Low | Minor |
Typically QA proposes severity, and the product owner decides priority. Full explanation with all four combinations: Severity vs Priority.
Managing Defects During a Release
- Fix first what blocks critical business flows, affects many users, or impacts production data or payments.
- Defer low-impact defects only with the product owner's agreement, and record them with a fix version.
- Retest fixes and run targeted regression around them before sign-off.
- Share a release bug summary: open defects by severity, priority, module and age.
QA metrics worth tracking
- Open defects by severity — the headline for release readiness.
- Defect aging — how long bugs wait.
- Reopen rate — how often fixes don't work; high rates point to rushed fixes or weak unit tests.
- Rejection rate — how often bugs are "not a bug"; high rates point to unclear requirements or weak bug reports.
- Defect leakage — bugs found in production that testing missed.
More in QA Concepts, Metrics & Glossary.
Team & Client Communication
When a developer rejects your bug
Stay factual: re-check the requirement, reproduce it again with a recording, and show the expected behavior from the acceptance criteria. If it's a genuine requirement gap, bring in the BA or product owner rather than arguing. Scenario answers: When a Developer Rejects Your Bug.
Communicating a critical issue to management
Immediately, clearly and with facts. A short message works best:
Subject: CRITICAL – Checkout fails for card payments on build 3.2.1 (QA)
Issue: Card payments fail with "Transaction error" (SHOP-412).
Impact: No customer can complete a card payment; release 3.2 is blocked.
Status: Reproduced on Chrome and Firefox; dev team investigating.
Next step: Retest as soon as a fix is deployed; update by 4 PM.
Handling client-reported bugs
- Listen, acknowledge the problem, and thank them for reporting it.
- Collect steps, screenshots, environment, time and error messages.
- Reproduce it, log it with the client's evidence, and set severity and priority.
- Give regular updates until it's resolved — even when the update is "still investigating".
For production issues, also see Production Incidents & RCA.
Other situations
- Ambiguous requirements — clarify with the BA or product owner before testing, and record the answer on the story.
- Blockers — raise them early, with the business impact and the dependency.
- Status reporting — share what's tested, what's open, and the risks, not just pass/fail counts.
From Real Projects
Preparing bug reports, tracking them in Jira and retesting the fixes was a core part of my work on Apkope, Canolog and Testsigma. Verifying customer tickets on Testsigma showed me how much the way a bug is described matters: a clear title, exact steps, expected versus actual result and a screenshot get a defect understood and prioritized much faster than a vague one-liner. I set severity from the impact I observed and left the business priority to the team's discussion.
📚 Official documentation: Jira Cloud documentation (Atlassian) · Selenium documentation
FAQs
How do you log a defect in Jira?
Reproduce it, check for duplicates, gather evidence, fill in the summary, environment, steps, expected and actual results, severity and priority, attach screenshots or logs, link the story and test case, and notify the owner. Related: Project Interview Questions for Testers.
What is the Jira bug workflow?
Commonly New/Open → Assigned/In Progress → Fixed/Ready for Retest → Verified → Closed, with Reopened when a retest fails. Other outcomes include Rejected, Duplicate, Cannot Reproduce, Deferred and Won't Fix.
What is defect aging?
How long a defect stays unresolved. It's tracked with Jira filters and dashboards, and escalated when it exceeds the agreed threshold.
What's the difference between severity and priority?
Severity is the technical impact; priority is the business urgency. They're set independently — a missing logo can be low severity but high priority.
How do you handle a defect triage meeting?
Prepare the list of new and disputed defects with evidence, agree validity, severity, priority, owner and fix version with the developers and product owner, then update Jira straight away.
How do you communicate a critical issue to management?
Immediately, with the issue, its business impact, the current status and the next step — short, factual and with the Jira link.
How do you handle a client-reported bug?
Acknowledge it respectfully, gather complete details, reproduce and log it, and give regular updates until it's resolved.
