Interview Drills — QA Fundamentals

Open-ended interview questions. Each has a Framework (the structure a strong answer follows), a Model answer (a concise example), and a Rubric (what an interviewer listens for). These test core definitions every QA engineer must own cold. Practice defining the term, contrasting it with its near-twin, and giving one concrete example — that pattern wins almost every fundamentals question. The app can role-play these as mock interviews (see mock-interview.md).

The universal fundamentals structure: Define A → define B → state the one axis that separates them → give a concrete example of each → (bonus) note when the distinction matters on the job. Use it on almost any "what's the difference between X and Y?" question.

D1

difficulty: easy
concept: severity-vs-priority What's the difference between severity and priority? Can a bug be high severity but low priority?
Framework: Define severity (impact on the product) → define priority (urgency of the fix) → state they're independent axes → give an example of each of the four combinations, especially a high-severity/low-priority one → note who owns each (QA/eng often set severity, PM/business sets priority).
Model answer: "Severity is how badly the bug damages the product; priority is how soon we should fix it — they're independent. A crash on a rarely-used admin export is high severity but low priority. The reverse: a typo in the company name on the landing page is low severity but high priority because it's embarrassing and customer-facing. Severity is usually a technical call by QA; priority is a business call by the PM."
Rubric: Strong answers keep the two axes clearly separate (impact vs. urgency), confirm a bug can be high-severity/low-priority, and give a specific example for each. Weak answers treat the terms as synonyms, can't give an example of them diverging, or say "they're basically the same."

D2

difficulty: easy
concept: regression-vs-retesting Explain the difference between regression testing and retesting.
Framework: Define retesting (re-running the exact failed test to confirm a specific fix works) → define regression (re-testing surrounding existing features to confirm the change didn't break anything else) → contrast scope (one fix vs. broader area) and trigger (a specific fix vs. any change) → give one example covering both.
Model answer: "Retesting is verifying a specific fix: a dev fixes the login bug, I re-run the exact failing steps to confirm it now works. Regression testing is checking that the fix didn't break anything around it — after the login fix I also re-test signup, password reset, and the session timeout, since they share auth code. Retest is narrow and targets the known defect; regression is broader and targets previously-working features. Retesting can't be automated until the bug's fixed; regression suites are prime automation candidates."
Rubric: Strong answers nail that retesting confirms the fix while regression protects everything else, contrast their scope, and give a concrete example tying them together. Weak answers blur the two, or define regression but forget retesting entirely.

D3

difficulty: medium
concept: smoke-vs-sanity What's the difference between smoke testing and sanity testing, and when do you run each?
Framework: Define smoke (broad, shallow check that critical paths work at all on a new build) → define sanity (narrow, focused check that a specific fix or small change behaves) → contrast on three axes: breadth (wide vs. narrow), depth (both shallow), and timing (new build vs. after a small change) → give an example of each → note the gate role of smoke.
Model answer: "Smoke testing is a wide-but-shallow check on a fresh build: can I open the app, log in, load the dashboard, and check out? If smoke fails, I reject the build and don't waste time testing deeper. Sanity testing is narrow-but-focused: a dev just fixed the discount-code calc, so I quickly verify a few discount scenarios work and nothing obvious near it broke. Smoke is broad across the app and gates whether testing even starts; sanity zooms in on one area after a small change. Both are quick — neither is exhaustive."
Rubric: Strong answers contrast breadth (smoke = wide, sanity = focused) and timing (new build vs. after a fix), and explain smoke's role as a build-acceptance gate. Weak answers swap the definitions, claim one is "deep" testing, or can't say when each is triggered.

D4

difficulty: medium
concept: black-box-vs-white-box Compare black box and white box testing. Which does a manual QA engineer mostly do, and why?
Framework: Define black box (test via inputs/outputs with no view of the code, like a user) → define white box (test with knowledge of internal code paths/logic) → state the dividing axis (visibility of internals) → map who does each (manual QA → black box; devs/automation/SDET → white box) → give an example of each → optionally mention grey box as the blend.
Model answer: "Black box testing checks behavior from the outside — I enter a valid and an invalid email and confirm the right response, without ever reading the code. White box testing uses knowledge of the internals — you write a unit test that drives a specific if/else branch in the validation function. The axis is whether you can see the code. Manual QA is mostly black box: we test like real users, which surfaces the bugs users actually hit, and it doesn't require reading source. White box is usually devs and automation engineers covering code paths and edge branches. Grey box mixes both — e.g., I check the database after a UI action to confirm the record saved correctly."
Rubric: Strong answers define both by code-visibility, correctly assign manual QA to black box with a reason (tests like a user, no code needed), and give an example of each. Weak answers reverse the definitions, claim manual QA does white box, or give no example.

D5

difficulty: medium
concept: sdlc-vs-stlc What is the SDLC, what is the STLC, and how do they relate? Where does QA fit, and what does "shift left" mean?
Framework: Define SDLC (the end-to-end software build cycle) and list its phases → define STLC (the testing-specific cycle that runs inside/alongside the SDLC) → relate them (STLC mirrors and feeds off SDLC phases) → place QA → define "shift left" and why it saves money.
Model answer: "The SDLC is how software gets built: Requirements → Design → Development → Testing → Release → Maintenance. The STLC is the testing lifecycle that runs alongside it — requirement analysis, test planning, test case design, environment setup, test execution, and test closure. They map onto each other: while devs design and build, QA is already analyzing requirements and writing test cases, not waiting until the end. QA's classic slot is the Testing phase, but 'shift left' means getting involved earlier — reviewing requirements before code exists — because a bug caught in requirements is far cheaper to fix than one caught in production."
Rubric: Strong answers distinguish the build cycle (SDLC) from the test cycle (STLC), list a few phases of each, and explain "shift left" with the cost rationale. Weak answers conflate the two acronyms, can't name phases, or describe QA as only a final gate with no early involvement.

D6

difficulty: medium
concept: bug-life-cycle Walk me through the bug life cycle. What does a "Cannot Reproduce" status usually tell you?
Framework: List the happy-path states in order (New/Open → Assigned → In Progress/Fixed → Re-test/Verified → Closed) → add the branch states (Reopened, Won't Fix, Duplicate, Cannot Reproduce) → name who owns each transition (QA reports/verifies, dev fixes) → interpret "Cannot Reproduce" as a signal about report quality.
Model answer: "A bug starts as New/Open when I report it, moves to Assigned when a dev picks it up, then In Progress and Fixed once they've worked it. It comes back to me for Re-test/Verified — I confirm the fix and Close it, or Reopen it if it's still broken. Side branches include Won't Fix (a real but low-priority issue we choose to live with), Duplicate, and Cannot Reproduce. 'Cannot Reproduce' usually points back at my report — the steps to reproduce weren't clear or complete, or I missed an environment detail like the browser or build. The fix is to tighten the steps, add the exact environment, and attach a screen recording."
Rubric: Strong answers give the states in correct order, include QA's two touchpoints (report and verify), name the branch statuses, and read "Cannot Reproduce" as a report-quality issue with a concrete remedy. Weak answers scramble the order, omit the re-test/verify step QA owns, or blame the dev for "Cannot Reproduce" instead of improving the report.

D7

difficulty: hard
concept: testing-pyramid Explain the testing pyramid. Why is it a pyramid and not an inverted one or a rectangle, and where does manual QA fit?
Framework: Name the layers bottom-to-top (unit → integration → system/E2E → acceptance/UI) → explain the shape: many fast, cheap, isolated tests at the bottom; few slow, brittle, expensive tests at the top → name the anti-pattern (the "ice-cream cone," top-heavy on slow E2E/manual) and why it's bad → place manual QA (mostly system/E2E and acceptance) → tie it to speed/cost/stability.
Model answer: "The pyramid stacks unit tests at the wide base, then integration, then system/end-to-end, with a thin layer of UI/acceptance tests at the top. It's a pyramid because the lower tests are fast, cheap, and stable, so you want many of them; the higher tests are slow, costly, and flaky, so you keep them few but high-value. Inverting it — the 'ice-cream cone,' where most coverage is slow E2E or manual clicking — gives you a brittle suite that takes forever and fails for flaky reasons, so bugs slip through. Manual QA mostly lives near the top, doing system/E2E and acceptance testing like a real user, while devs own the unit base. The lesson: catch as much as possible cheaply low down, and reserve the expensive top layer for the user-level flows that truly need it."
Rubric: Strong answers order the layers correctly, justify the shape with the speed/cost/stability trade-off, name the inverted anti-pattern and why it's harmful, and place manual QA near the top. Weak answers just list layers with no rationale for the shape, invert the cost logic, or can't explain why a top-heavy suite is a problem.