Interview Drills — "How would you test X?"

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 this scenario" drills are the single most common QA interview question — the interviewer cares less about a complete list and more about whether you have a repeatable mental model. Practice thinking aloud. The app can role-play these as mock interviews (see mock-interview.md).

The universal "how would you test it?" structure: Clarify the feature and requirements (don't assume) → state your test categories out loud → walk each one: happy path → edge cases (boundaries, empty, max length, special chars) → negative (invalid input, fails gracefully) → usability → compatibility (browsers/devices) → security → then name what you'd prioritize and what you'd automate. Naming the categories before listing cases is what signals a structured tester.

D1

difficulty: easy
concept: test-design-techniques How would you test a login page?
Framework: Ask clarifying questions (what are the rules — email or username? password requirements? "remember me"? rate limiting?) → announce your categories → happy path → edge cases → negative → usability → compatibility → security → state what you'd automate.
Model answer: "First I'd clarify the rules: valid email format, password length, lockout policy. Happy path: valid credentials log in and land on the dashboard. Edge: boundary password length (min-1, min, min+1), max-length field, leading/trailing spaces, copy-paste, browser autofill. Negative: wrong password, valid email + wrong password, unregistered email, empty fields, SQL-like input — each should fail gracefully with a clear, non-revealing error. Usability: Enter-key submits, password show/hide, errors are readable. Compatibility: Chrome/Safari/Firefox, mobile, password managers. Security: error message shouldn't reveal whether the email or password was wrong, lockout after N failed attempts, password masked, no credentials in the URL, session expires on logout. I'd automate the happy path and core negative cases as regression checks."
Rubric: Strong answers clarify the rules first, name the categories explicitly, and reliably hit boundaries, graceful negative handling, and security specifics (don't reveal which field was wrong, lockout, masking). Weak answers list a few random cases ("try a wrong password"), skip security and compatibility entirely, and never mention prioritization or boundaries.

D2

difficulty: medium
concept: test-design-techniques How would you test a promo-code / coupon field at checkout?
Framework: Clarify the code's rules (fixed vs. percentage? expiry? minimum spend? one-time vs. reusable? stacking?) → happy path → edge/boundary → negative → state/concurrency → usability → security → prioritize the money-risk cases.
Model answer: "I'd clarify how codes behave: percentage vs. fixed amount, expiry date, minimum cart value, single-use vs. reusable, and whether two codes can stack. Happy path: a valid code applies the right discount and the total recalculates. Edge/boundary: cart exactly at the minimum spend, discount larger than the cart total (does it floor at zero, never negative?), expiry at the exact boundary (last valid second), case sensitivity, whitespace. Negative: expired code, invalid code, already-used single-use code, code below minimum spend — each gives a clear message and doesn't apply. State: apply then remove a code, apply two codes, change the cart after applying (does the discount re-validate?). Security: the discount must be enforced server-side — I'd try tampering with the request to force a 100% discount or reuse a single-use code, and confirm the price can't be manipulated from the client. Usability: clear success/error feedback, the discount line is visible. I'd prioritize the cases with direct financial risk — negative discounts, server-side enforcement, single-use reuse."
Rubric: Strong answers treat this as a money feature: they probe server-side enforcement, single-use reuse, discount-exceeds-total flooring, and minimum-spend boundaries, and they prioritize financial-risk cases. Weak answers only test "valid code works / invalid code fails," miss the boundary and concurrency cases, and never consider that the discount could be tampered with client-side.

D3

difficulty: medium
concept: test-cases-and-plans How would you test a file-upload feature?
Framework: Clarify constraints (allowed types, max size, single vs. multiple, where it's stored/used) → happy path → boundary (size/count) → negative (wrong type, corrupt) → interruption/state → compatibility → security → usability.
Model answer: "I'd clarify the rules: accepted file types, max size, single or multiple files, and what happens to the file afterward. Happy path: upload a valid, in-size file → it succeeds and is retrievable/displayed correctly. Boundary: a file at exactly the max size, one byte over, an empty (0-byte) file, the max number of files, very long filenames, names with spaces/Unicode. Negative: disallowed type, a file renamed to a fake extension (e.g., .exe renamed to .jpg), a corrupt file — should reject with a clear message, not crash. Interruption: cancel mid-upload, lose connection halfway, double-submit, upload then navigate away (does it leave orphaned data?). Compatibility: drag-and-drop vs. file picker, mobile camera upload, different browsers. Security: the big one — never trust the client. Verify type/size server-side, block path-traversal filenames (../../), executable uploads, and oversized files that could exhaust storage; confirm uploaded files can't be executed and aren't served from a path that lets one user read another's file. Usability: progress indicator, clear errors, ability to retry."
Rubric: Strong answers cover the 0-byte and over-max boundaries, the fake-extension and interrupted-upload cases, and especially server-side validation plus the security angles (path traversal, executable upload, access control). Weak answers only "upload a picture and check it shows up," forget the size/type boundaries, and ignore that file upload is one of the most security-sensitive features in any app.

D4

difficulty: medium
concept: types-of-testing How would you test a vending machine?
Framework: Clarify the model (what payment types? does it give change? inventory tracking?) → happy path → edge/boundary → negative → physical/environmental → state & concurrency → usability/accessibility → recovery.
Model answer: "I'd clarify: cash, card, or mobile? Does it dispense change? Happy path: insert exact payment, select an in-stock item → correct item dispenses and any change is returned. Edge: pay with exact change vs. overpay (correct change back), buy the last item in a slot, machine runs out of change. Negative: select a sold-out item (clear message, money refunded or not taken), insert a torn bill or foreign coin, enter an invalid slot code. Physical/environmental: item gets stuck mid-dispense, power loss mid-transaction (does it refund or dispense on recovery?), multiple coins inserted rapidly. State/concurrency: two selections at once, cancel after paying, inventory count decrements correctly. Usability/accessibility: readable display, button reachable from a wheelchair, clear out-of-stock indication. Recovery: what happens after a jam or power cycle — no money lost, no free item. The interviewer mainly wants to see I think beyond 'press button, get snack' into failure and money-handling cases."
Rubric: Strong answers treat the vending machine as a state machine with money and physical hardware: they cover change-making, sold-out, jams, power loss mid-transaction, and "no money lost / no free item" recovery. Weak answers list only the happy path or vague cases ("test all the buttons"), miss the money and failure-recovery scenarios, and don't think about the physical/environmental dimension that distinguishes a hardware product.

D5

difficulty: hard
concept: types-of-testing How would you test a search feature (e.g., the search bar on an e-commerce site)?
Framework: Clarify scope (what's searchable? autocomplete? filters? expected ranking?) → happy path → edge inputs → negative/no-results → relevance & ordering → performance → compatibility → security → prioritize.
Model answer: "I'd clarify what's indexed, whether there's autocomplete, and what 'good' results mean. Happy path: a common term returns relevant results, ordered sensibly. Edge inputs: empty query, a single character, very long query, special characters and emojis, leading/trailing spaces, different casing, partial words, common typos (does it handle 'iphnoe'?). Negative/no-results: a nonsense term shows a clean 'no results' state, not an error. Relevance: an exact product name ranks first; synonyms and plurals work. Performance: response time on a broad term, behavior under many concurrent searches, autocomplete latency as you type. Compatibility: keyboard vs. mobile, screen-reader announces result counts. Security: I'd test injection-style input and script tags in the query to confirm they're escaped and can't break the page (no XSS) or the backend query. I'd prioritize relevance, the no-results state, and the injection cases — those most affect users and risk."
Rubric: Strong answers go past 'does it return results' into relevance/ranking, typo and special-character handling, the empty/no-results states, performance under load, and injection/XSS — then prioritize. Weak answers only type a word and confirm something shows up, treat search as a simple input field, and miss that result quality, performance, and injection are the hard, interesting parts.

D6

difficulty: hard
concept: test-design-techniques How would you approach testing a feature when there's no written specification?
Framework: Don't freeze — state how you'd source the expected behavior → use exploratory testing → apply general quality heuristics → document assumptions and raise questions → still structure by category → flag the ambiguity as a finding itself.
Model answer: "No spec doesn't mean no testing — it means I define the expected behavior as I go. First I'd gather what does exist: designs, tickets, similar existing features, and a quick conversation with the PM or developer to learn the intent. Then I'd explore the feature hands-on, asking 'what happens if I…?' — and apply universal heuristics that hold regardless of spec: it shouldn't crash, it should handle empty/invalid input gracefully, boundaries should behave, it should be consistent with the rest of the app, and it shouldn't lose user data. I'd still structure my testing across the usual categories — happy path, edge, negative, usability, compatibility, security — and write down my assumptions ('I assumed names cap at 50 chars') so they can be confirmed. Crucially, the missing or ambiguous spec is itself a finding — I'd raise the open questions, because an undefined behavior is a bug waiting to ship. So I stay productive and turn ambiguity into documented questions rather than guesses."
Rubric: Strong answers refuse to be blocked: they source intent from people and analogous features, lean on exploratory testing and general quality heuristics, document assumptions, and treat the ambiguity itself as something to surface. Weak answers say "I can't test without a spec," guess silently without recording assumptions, or abandon structure entirely — missing that handling ambiguity well is exactly the mindset this question probes.