Manual QA interview questions

Pick one where you argued the call: a payment crash behind a disabled feature flag — severe but zero users hit it, so it waited a sprint. Or a cosmetic logo issue shipped as an emergency fix before a client demo.

Move off adjectives onto impact: who hits it, how often, is there a workaround. Often they're pricing the fix effort while you're pricing user damage — both can be right. If it still stands, the product owner owns the call.

Reproduce it again on a clean state and count the rate, diff your environment against theirs — build, data, flags — then bring evidence: a recording, the request ID, the log line. Ten minutes at your desk beats a week of comments.

The product owner or triage group — not the tester and not the developer alone. QA's job is making the risk visible and recorded; the business's job is deciding to carry it. Keep the decision and the date in the ticket.

The honest rate — '3 of 10 attempts' — plus everything that varied between attempts: timing, data, account state. Never write 'happens sometimes'; count it. An intermittent bug labelled as always-reproducible burns your credibility on the retest.

Almost always reproducibility: a missing step, an unstated starting state, data that exists only in your session, or an environment difference nobody mentioned. The fix is writing steps from a clean state and naming the account, build and flags.

Then say so and switch tactics: capture the production request ID, pull the logs for that timestamp, and compare production config and data against staging. A bug that needs production data is an environment-parity finding in itself.

When repeated clean-state attempts, an environment diff and a pairing session all come up empty — then it's documented with everything tried and parked as cannot-reproduce, not closed as invalid. If it returns, the history is waiting.

Low severity — nothing is broken functionally. Probably high priority — every prospect sees it and it makes the brand look careless. It's the classic diverging pair, and saying so shows you understand both dials.

Yes — when the workaround doesn't cover the damage. Data corruption with a manual repair path is still Critical: the loss already happened. Security issues too — 'log out and back in' doesn't un-leak a token.

Read the stories and attack the gaps: undefined edge cases, missing error states, untestable wording like 'fast' or 'user-friendly'. Every ambiguity you get answered before coding is a bug that never gets written.

Exactly this — moving testing effort earlier: requirement reviews, design input, test cases before code, checks in CI. The logic is cost: the earlier a defect is caught, the cheaper it is to fix.

All of them — compressed into every sprint. Requirement analysis happens in refinement, planning in sprint planning, design and execution inside the sprint, closure at the review. The stages didn't die; they shrank from months to days.

Entry: build deployed, smoke passing, data ready — fit to start. Exit: planned cases run, no open critical or high defects — allowed to stop. Both must be checkable facts, not opinions.

Not wait for builds: review the stories' acceptance criteria, ask the edge-case questions, plan test data and environments, extend regression coverage for what's coming. Testing work starts before the first commit.

In regulated domains — medical, automotive, aviation — it's alive and often mandated, because it produces the traceability auditors want. Elsewhere its core idea survived inside Agile: design tests from requirements, before code.

100% of planned cases executed, 95%+ passing; zero open critical or high defects; regression suite green on the release build; performance within the agreed threshold; known issues documented and signed off by the product owner.

Test what's testable and put the rest on record: which criteria failed, what can't be verified because of it, what risk that leaves. The business can trade quality for time — but knowingly, in writing, not by accident.

Have one ready: an undefined error state, a rule that contradicted another feature, a 'what happens at zero items' nobody had decided. The interviewer is checking shift-left is something you've done, not a diagram you've seen.

Extending quality work into production: monitoring, alerting, canary releases, feature flags, testing with real traffic. Shift-left prevents; shift-right detects fast and limits blast radius. Mature teams do both.

Verification — you're checking the work products are consistent and complete without executing anything. But a sharp review question like 'is this what the customer actually asked for?' edges into validation. Saying both shows range.

Yes — the product serves users fine but drifted from the documented spec. That usually means the spec is stale. It still needs fixing: the next person to trust that document inherits the gap.

A defect root-cause review that changes the process — like adding API contract checks after a breaking-change incident. Also: requirement review standards, definition-of-done rules, coding standards. All prevention, none of it is executing the product.

Habit, and the roles genuinely blur: a good tester does both — finds the defect (QC) and pushes the process change that stops its siblings (QA). Knowing the difference matters more than policing the job title.

Yes — static testing by definition: examining the work product for defects without executing it. It catches logic gaps, missing error handling and unclear code that dynamic tests would only surface later, if at all.

Keep a real one ready: an undefined empty-state, two stories contradicting each other, an unmeasurable word like 'quickly'. The question behind the question is whether you actually attend reviews with your tester hat on.

Smoke — it runs on every single build, has stable scope, and its value is speed of verdict. Automated smoke in CI means a broken build bounces in minutes without a human touching it. Sanity's scope changes with every fix, so it stays flexible longer.

App loads, login works, product search returns results, add-to-cart, the checkout happy path to order confirmation, and the payment provider responds in sandbox. Ten to twenty checks, under fifteen minutes — alive or not alive.

Retest the fix, then risk-scoped regression: the module it lives in, anything sharing its code, and the revenue path end to end. Full regression isn't happening overnight — say what you ran and what you didn't, in writing.

From the diff and the dependency map: what shares code, data or state with the change? Plus the product's history — modules that broke before, break again. Blast radius first, bug history second, revenue paths always.

Product with engineering — but in practice nobody, until QA asks. 'How fast is acceptable? How many concurrent users? Which accessibility standard?' If those numbers don't exist, asking for them is itself senior tester work.

Accessibility — it has no angry user in the room until it's a legal letter. Second place: performance under realistic data volumes; staging with 100 rows never predicts production with 10 million.

Have one ready: verifying a 'deleted' record was soft-deleted with a flag rather than removed, catching a UI success toast over a failed API call, or using the schema to build an edge-case input the interface alone wouldn't suggest.

Through the contract it's black box — you send requests and assert responses without reading code. It becomes grey box the moment you use internal knowledge: the schema, the queue behind the endpoint, the cache you know sits in front.

Signal still arriving: crash rate not yet flat, a critical flow with thin coverage (say, few users tried payments), or a fresh fix that needs re-exposure. You end a beta when new sessions stop teaching you things.

Instrument first: crash reporting, analytics on the flows you care about, an in-app report button that auto-attaches device, OS and logs. 'Email us if something breaks' collects nothing — the app must carry the evidence itself.

Shrink the ask: pre-built scenarios for their top five workflows, ready data, a booked hour with someone sitting alongside. If they still can't, escalate the risk in writing — skipped UAT is the business accepting unvalidated fit.

The business owner of the process — not QA, not the project manager. It means: we confirm this supports our real work, known issues acknowledged. It's an acceptance of fit and remaining risk, not a claim of zero defects.

They're the same idea at two zoom levels: partitioning tells you WHERE to test (one value per class), boundaries tell you WHICH exact values (the edges between classes, where off-by-one bugs live). Use them together.

Valid active code; expired code; not-yet-active code; used-up code; malformed string; empty input; valid code for a different product. Each behaves differently, so each is its own partition — one test per class.

Step is 0.01, so: 0.00, 0.01, 0.02 and 99.98, 99.99, 100.00. Plus the precision attack: 0.015 — does it round, truncate or reject? Decimal fields hide a second boundary in the number of decimal places.

Read the requirement's wording: '18 to 60' usually means inclusive, 'under 100' means 100 is out. If the spec doesn't say, that's a real requirements bug — ask, don't assume, and get the answer written down.

Sixteen — 2 to the power of conditions. That growth is the point of the next question: at five or six conditions you collapse rows that share an outcome, or switch to pairwise to keep the table testable.

Merge rows where one condition decides the outcome regardless of the rest (write a dash for 'doesn't matter'), drop impossible combinations, and if it's still huge, cover pairs of conditions instead of all combinations.

Requested → email sent → link clicked → new password set → done; with expiries off 'email sent' and 'link clicked', and 'link already used' as a refused re-entry. The money tests: reusing a used link, and clicking after expiry.

Bring one: editing a submitted form by hitting back, cancelling an already-shipped order, double-clicking pay and charging twice. Double-submission is the classic — same event, fired twice, in a state that should accept it once.

When specific combinations carry known risk — payment provider × currency in a payments product needs every pair that moves money, explicitly. Pairwise is for broad configuration spread, not for the combinations your business bleeds on.

From analytics and bug history: the browsers and devices users actually run, the locales that broke before, the roles with different code paths. Pairwise over factors nobody uses is efficient coverage of nothing.

Zero-byte file; huge file just over the limit; wrong extension with a renamed type (exe as jpg); filename with spaces, unicode or path characters; and double-submitting the same upload. Each maps to a real production incident somewhere.

Error guessing is a targeting trick — specific inputs aimed at likely failures. Exploratory is a whole approach: charters, time-boxes, learning as you go. You'll use error guessing INSIDE an exploratory session constantly.

Valid login (the smoke check every build needs), invalid password with the right error, and lockout after N failures. They're stable, objective and run constantly — the definition of good automation candidates.

When error messages reveal whether an account exists — 'wrong password' vs 'no such user' tells an attacker which emails are registered. Test both a real and a fake account: the error must be identical, in text AND response time.

When the executor has context and the feature is exploratory-friendly: scenarios plus session notes cover it. Detailed cases earn their cost where precision matters — compliance, handovers, offshored execution, or flows with exact data setups.

Valid credentials; wrong password; unknown email; empty fields; case-sensitivity check; locked account; remember-me persists; redirect after login returns to the page you came from. Eight cases, one scenario line.

Strategy: the QA lead or head of engineering — it's a standing policy. Plan: whoever leads testing for that release, reviewed by the team. If both are owned by nobody, you find out during the incident review.

Every plan reinvents decisions: which layers to automate, what environments exist, what 'critical' means. Plans contradict each other, tooling fragments, and new joiners learn a different process per project. The strategy is what makes plans short.

Examples with reasons attached: the deprecated card provider (sunsetting in Q4), chargeback flows (owned by finance ops), load beyond current peak (platform team's plan). Every exclusion names why and who carries it instead.

As short as honesty allows — one or two pages for most features. The moment a plan is long enough that nobody reads it, it stops preventing arguments, which was its whole job. Scope, criteria, risks; cut the boilerplate.

Make it a by-product, not a document: link test cases to stories in the tool you already use (Jira, TestRail do this natively), and check it at the same moments you already review — refinement and release readiness.

A heavyweight matrix, rarely. The idea, always: every acceptance criterion needs at least one check, and the story-to-test link in your tooling IS the lightweight matrix. Regulated Agile teams keep the formal version because auditors ask.

Read the escaped bugs before touching any process: which module, which type, findable how? Then fix the specific hole — a missing environment, an untested integration, thin regression in one area. Leakage is a symptom; the bug list is the diagnosis.

Bugs-per-tester. It turns colleagues into competitors, rewards shallow bug-splitting, and punishes the tester who spends a day proving a hard critical. Anything that gamifies individuals corrupts the data and the team at once.

90 ÷ (90 + 10) × 100 = 90%. Above 90 is generally strong. The follow-up trap is 'is 90 good?' — the honest answer: against our own last three releases, not against an industry table.

Because the units aren't standard: teams count size differently, log defects at different thresholds, and build different-risk software. Within one codebase the comparison finds hotspots; across teams it's numerology.

Session notes: the charter, what you covered, bugs raised, questions left. Post them where the team lives — the ticket, the channel. Exploration without a trail looks like 'played with the app'; with notes it's auditable coverage.

The session's mission, one line: 'explore refund flows with expired cards'. Tight enough to focus, loose enough to follow surprises. It's the difference between exploring and wandering.

'Explore file upload with hostile files — oversized, zero-byte, wrong extensions, renamed types, unicode filenames — and watch server responses and storage.' One line, an attack direction, room to chase whatever bleeds.

Five minutes with the lead: what was covered, what was found, what's still worrying, what the next charter should be. It converts one tester's session into the team's knowledge — and often reprioritises tomorrow.

Yes — as a quick pulse: a smoke-style poke at a fresh build, a two-minute check after a config change. It becomes a problem only when it's the whole strategy, because it can't show coverage or be repeated.

Header: charter, build, time-box. Body: bullet trail of areas touched, bugs raised with ids, questions for the team, and what I'd explore next. Half a page, written during the session, readable by anyone.

From evidence, not vibes: how often the area changes (git history), its bug history, its complexity, how new the code is. A module that changed twelve times this quarter with five past bugs scores itself.

The product owner — because a risk ranking is really a business-priority statement wearing QA clothes. QA proposes with evidence; the business owns the accepted risk. Get it visible in planning, not buried in a test plan.

Then they're choosing more scope, so they choose the currency: more time, more people, or accepting specific risks by name. 'Test everything in two days' isn't an option on the menu — my job is keeping the menu honest.

Attack the cause in retro with numbers: testing windows compressed four releases running. Push for QA in refinement (smaller, testable stories), automation of the repeat regression, and release criteria agreed before the date, not at it.

That contradiction is a finding — the feature can't satisfy both. Put the two versions side by side in the ticket, get a decision in writing, and test against it. You've just done requirements work; that's the job under ambiguity.

No — I'd test against my documented assumptions while flagging them loudly. Blocking punishes users for a process gap. But high-risk ambiguity — money, data deletion — gets answered before I sign anything off.

Have one ready — the shape is 'what happens when X fails mid-Y': payment mid-renewal, network mid-upload, expiry mid-checkout. The best refinement questions are about the failure paths nobody wrote in the story.

Estimate together, but testing effort must be visible inside the number — a two-point code change with heavy data setup is not a two-point story. Silent testing effort is how sprints 'mysteriously' overflow.

Concrete, checkable items: acceptance criteria verified, regression around the change green, automated checks added or updated in CI, no open critical/high defects, exploratory notes for risky stories. Nothing vague like 'properly tested'.

The product owner drafts intent, but the strongest criteria come out of three-amigos — QA adds the edge cases, dev adds feasibility. Criteria written alone by anyone tend to cover only the happy path.

The recurring shapes: what happens at zero/empty, at the limit, on retry, on expiry mid-flow, on two users doing it at once. Bring one concrete catch of your own — 'refund after partial shipment' style — and the answer lands.

Refinement is the whole team processing the backlog; three-amigos is three perspectives going deep on ONE story, often just before it's picked up. Refinement decides what and when; amigos nails down exactly what correct means.

Then the sprint is quietly shipping untested work, and the bill arrives as production bugs. Show the leakage: which escaped defects came from last-day stories. When the pattern has a cost attached, 'just how it is' stops being an answer.

Story-reached-QA date vs sprint end, per story, across sprints; and escaped defects traced back to last-day stories. Two simple numbers — the pile-up and its price — make the case better than any argument.

Same sprint if the feature is stable and the DoD demands it; next sprint if the UI is still settling. What matters is that automation debt is tracked, not silent — a named backlog item, not a hope.

Have a real answer: a PDF's visual layout, a one-time migration check, a flow behind a flaky third-party sandbox where the suite would cry wolf weekly. Knowing what NOT to automate is the mid-to-senior tell.

PUT replaces the whole resource — send everything, omissions may be wiped. PATCH updates only the fields you send. The test that catches teams out: PUT with a missing field — does it null the field or reject the request?

404 — the resource is gone. A second 200 can be acceptable idempotent design if documented, but a 500 is always a bug: the API failed to handle its own successful past. This exact probe finds real defects constantly.

A login request stores the token into an environment variable via a post-response script; every other request references it in the Authorization header. New environment = same collection running against dev, staging, or sandbox unchanged.

Body assertions: required fields exist, values match what you created, types are right. Plus a response-time ceiling and — for creates — a follow-up GET asserting persistence. A 200 with a wrong body is still a failing test.

Schema validation in the tests — assert structure and types, not just values — so a renamed or re-typed field fails immediately. Teams with consumers they don't control add contract tests (Pact-style) pinning what consumers rely on.

Insecure Direct Object Reference: accessing others' resources by guessing IDs. Test with two accounts — create as A, fetch as B expecting 403/404, walk sequential IDs, and repeat on every resource type, not just the obvious one.

Query the table: row there? If yes, the API layer is filtering or failing — check its query and permissions. If no, the UI is showing cache or local state. One SELECT splits the stack in half and tells you which team owns the bug.

Interviewers ask this to check SQL is real for you, not a course certificate. Have one ready with a purpose: 'joined users to orders to find accounts with a paid order but no confirmation email row — data for an email-delivery bug.'

WHERE filters rows before grouping, so COUNT doesn't exist yet when it runs. HAVING filters groups after aggregation. 'WHERE COUNT(*) > 1' is a syntax error — and the exact mistake this question is fishing for.

LEFT JOIN users to orders, then WHERE orders.id IS NULL. INNER JOIN can't do it — it drops non-matching rows, which are precisely the ones you're hunting.

Ask what the 2% is worth: on a consumer product that can be thousands of users, and iOS often over-indexes on payments. Minimum: critical flows each release. Dropping a browser is a business decision to propose, never a silent skip.

Touch targets too small, hover-only interactions with no tap equivalent, virtual keyboards covering inputs, viewport overflow, and interrupted-state bugs — rotation, backgrounding mid-flow, flaky networks. Different input model, different bug class.

Everything needing judgment: whether alt text is meaningful, whether focus ORDER makes sense, whether the screen-reader experience is usable, whether errors are announced. A scan checks attributes exist; it can't tell if the page works eyes-closed.

Invisible or missing focus indicators; inputs without programmatic labels (placeholder is not a label); and colour-only meaning — the red/green status dot a colour-blind user reads as identical. All three are five-minute finds.

Query for the row and assert it exists with the exact values you entered, that timestamps/defaults are set, and that no related table was wrongly changed. UI 'success' isn't proof of persistence.

LEFT JOIN A to B and filter WHERE B.key IS NULL — the unmatched left rows. It's the standard 'find the orphans' pattern in data testing.

Yes — WHERE narrows the rows first (say, this year's orders), then GROUP BY aggregates them, then HAVING filters the groups (customers with >5 of those orders). They run in that order.

No — the response can be built in memory and never persisted, or a trigger/mapping can change the value on write. The DB query is the independent proof, a different code path from the response.

A missing database constraint plus a race — two requests insert the 'same' record before either commits. The query finds the symptom; the fix is a unique constraint, and testing the concurrent path.

As part of the test suite against a seeded DB, or as monitoring queries in production. Either way they're cheap standing assertions that catch data drift the UI hides.