11 QA Bugs and Process Interview Questions and Answers

Short answer: Severity is the technical impact of a defect on the system (how badly it's broken) and is set by QA. Priority is the business urgency of the fix (how fast it must be fixed) and is set by the PM or lead. They're two independent axes: a bug can be both very severe and not urgent at all.

In depth:

1. Severity — an objective trait: crash, data loss, blocked feature vs. cosmetics. The tester sets it.
2. Priority — a subjective business call: how many users are hit, reputation, release deadlines. The PM/product owner sets it.
3. Why they're separate — resources are limited, so the fix queue is ordered by priority, not by severity.

⚠️ Common mistake: conflating the axes or assuming high severity automatically means high priority. The interviewer is listening for exactly who owns each axis: severity is QA, priority is the business.

Short answer: New → Assigned → In Progress → Fixed → Retest → Closed. That's the main flow, but it has important branches: Reopened (the bug came back after the fix), Rejected (not a bug), Duplicate (already filed), Deferred (postponed). The key to the answer is naming not just the line but the branches, and who performs each transition.

In depth:

1. New — the tester filed the bug.
2. Assigned → In Progress — the lead assigns a developer, who picks it up.
3. Fixed — the developer fixed it and handed it back for verification.
4. Retest → Closed — the tester re-verifies on the new build and closes it.
5. Branches — Reopened (tester), Rejected/Duplicate (developer or lead), Deferred (PM postpones it).

 New ──► Assigned ──► In Progress ──► Fixed ──► Retest ──► Closed
 (QA)     (lead)        (dev)         (dev)     (QA)       (QA)
           │                                      │ failed
           ▼                                      ▼
 Rejected / Duplicate (dev, lead)          Reopened ──► back into work
 Deferred (postponed by PM)

⚠️ Common mistake: naming only the straight line New→Closed and forgetting the Reopened/Rejected/Duplicate/Deferred branches — those are exactly what show you've worked in a real tracker.

Short answer: A clear title, environment (OS/browser/build), preconditions, reproduction steps, expected and actual result, severity/priority, and attachments (screenshot, log, video). A good report lets the developer reproduce it without a single follow-up question.

In depth:

⚠️ Common mistake: the most frequent omission is not separating "expected vs. actual." Without an explicit expected result, the developer can't tell whether it's a bug or intended behavior, and the report turns into an argument.

Short answer: The Definition of Done (DoD) is a shared, team-agreed checklist of criteria that, when met, mark a task as complete. The QA part of the DoD must be concrete and measurable: test cases written and executed, no open critical/high bugs, regression passed.

In depth:

1. DoD is shared by the team — code review done, tests green, documented, deployed to staging.
2. QA gates in the DoD — the specific items testing owns:

[ ] Test cases written and cover the acceptance criteria
[ ] All test cases executed on the target environment
[ ] No open Critical / High bugs
[ ] Regression of affected areas passed
[ ] Bugs filed and accepted by development

3. Why — the DoD kills "done / not done" arguments and stops an under-tested task from slipping into a release.

⚠️ Common mistake: the vague phrase "testing complete" with no measurable criteria. "Complete" means how many cases, which regression, what bug threshold? Without numbers the DoD does nothing.

Short answer: Don't guess in silence — act proactively: clarify with the BA/PM/analyst, record your assumptions in writing in the test plan, and raise the ambiguity as early as possible — at requirements review, not once the bug is already on production.

In depth:

1. Clarify at the source — ask specific questions of the analyst, PM, or product owner, not the tester next to you.
2. Record assumptions — if there's no immediate answer, write your assumption in the test plan and explicitly flag it as an assumption.
3. Raise it early — a contradiction caught at requirements review is cheap; caught in testing it's expensive; on production it's very expensive.
4. Document it — leave a trail in the ticket/chat so the decision is traceable.

Unclear requirement
   │
   ├─► Ask BA/PM ──► Answer ──► Test per the answer
   │
   └─► No answer ──► Assumption in test plan ──► Flag to team

⚠️ Common mistake: passively complaining that "the requirements are bad" and then silently guessing the behavior during execution. The interviewer is checking for proactivity, not for a high tolerance for pain.

Short answer: Argue with evidence, not opinions: show the requirement, spec, or acceptance criteria the behavior violates, and explain the impact on the user and business. If there's no consensus, the PM/BA arbitrates and the disagreement is documented. The interviewer is checking communication maturity, not who is technically right.

In depth:

1. Check the spec — is there an explicit requirement or acceptance criterion? If yes, it's a bug, case closed.
2. Show the impact — on the user, conversion, data; facts instead of "I think."
3. Spec is silent — then it's a requirements ambiguity: a separate problem for the BA/PM.
4. Escalate to an arbiter — the PM/product owner decides, not the loudest voice.
5. Document it — record the decision in the ticket so you don't re-argue it later.

Dispute ──► Spec/AC? ──yes──► Bug, fix it
              │
              no
              ▼
     Impact on the user? ──► PM/BA arbitrates ──► Decision in ticket

⚠️ Common mistake: dropping into a personal "bug / not a bug" fight on emotion, or silently closing the ticket. The right move is to return to the requirements and escalate through process while keeping the working relationship intact.

Short answer: Answer with STAR and honestly: take ownership without shifting blame, walk through the root cause, and — most importantly — name the concrete process change that came out of it (a new regression check, better test data, monitoring). They're grading your reaction, not the bug itself.

In depth:

S — Situation: a payments release, Friday, tight window.
T — Task: I owned the checkout regression.
A — Action: I didn't test "discount + foreign card" combined.
R — Result: ~8% of payments failed for 3h; rolled back, fixed.
           Lesson: added that case to regression + an error-rate alert.

1. Ownership — "I missed it," not "the developer wrote a bug" or "they gave me no time."
2. Root cause — why you missed it: a gap in test design, an uncovered combination, an unstable environment.
3. Process change — a new regression case, monitoring/alerts, test-data review. This is the heart of the answer.

⚠️ Common mistake: telling a dramatic story with no takeaway — what actually changed afterward. A bug with no process change sounds like it'll happen again tomorrow.

Short answer: In Waterfall, testing is a separate late phase after all development is done. In Agile, testing runs continuously every sprint and QA is embedded from the requirements stage — that's shift-left. The tester stops being the "last line of defense" and becomes part of the team from day one.

In depth:

⚠️ Common mistake: failing to name shift-left, or describing the same waterfall model under the word "Agile" — "we built everything first, then tested in the sprint before release." The essence of Agile is exactly early and continuous QA involvement.

Short answer: Don't give one gut-feel number — decompose the work and estimate with techniques. Planning Poker is a team estimate in story points: everyone privately picks a card from a Fibonacci range (1, 2, 3, 5, 8, 13…), then all reveal at once — which removes anchoring on the loudest person's opinion.

In depth:

1. Decomposition — split the feature into areas/test types (functional, regression, integration) and estimate the parts.
2. Planning Poker — Fibonacci cards, simultaneous reveal; divergent estimates get discussed, not blindly averaged.
3. Triangulation — compare to a similar past task: "this is roughly like the one that took 3 days."
4. Risk buffer — unstable environment, new integrations, incomplete requirements — add a buffer.

⚠️ Common mistake: naming one number with no decomposition and no risk allowance. An estimate is a range plus a rationale, not a shot in the dark.

Short answer: An error (mistake) is a human mistake; a defect (bug, fault) is its material trace in the code or another artifact; a failure is the defect surfacing at runtime, when the system behaves differently than expected. It's a cause-and-effect chain in ISTQB terminology.

In depth:

1. Error — a human erred: misread a requirement, mistyped a formula.
2. Defect — that error became embedded in an artifact: a line of code, a spec item, a test case.
3. Failure — the defect fired at runtime: the user saw a wrong result or a crash.

Error            Defect              Failure
(a human)   ──►  (in code/artifact) ──►  (at execution)
misread          a bug in a line       system crashed
the requirement  or the spec          / returned wrong

⚠️ Common mistake (and a bonus to the answer): assuming every defect inevitably causes a failure. It doesn't: a defect in dead code or on an unreachable branch never executes and never produces a failure.

Short answer: Right after build and deploy, before deep testing — as a fast gate. Smoke checks that the critical core works at all (the app came up, login passes, the main screens open). A red smoke blocks the later pipeline stages so you don't run an hour-long regression against an already-dead build.

In depth:

1. When it runs — immediately after build/deploy, as the first automated step.
2. Gate role — green smoke = the build is alive enough to test deeper; red = stop, there's no point going further.
3. What it covers — only the basic critical paths, fast (minutes, not hours); it is not regression.

 build ──► deploy ──► SMOKE ──green──► regression / e2e
                        │
                       red
                        ▼
                  build rejected, pipeline stops

⚠️ Common mistake: reciting the definition "smoke is a shallow check" without tying it to a specific pipeline moment. A strong answer names exactly "right after deploy, as a gate before the deep run."