Manual QA interview questions

Severity describes technical impact — how badly the product is broken when the defect occurs. Priority describes business urgency — how soon someone needs it fixed. Severity is usually owned by the tester, because you saw the damage. Priority is usually owned by the product owner, because they know what the business can tolerate this week.

They move independently, and the interesting cases are where they diverge. A crash buried in a legacy report almost nobody opens is high severity but low priority. A typo in the company name on the landing page is trivially low severity but high priority, because every visitor sees it and it makes the brand look careless.

The reason interviewers ask this is not the definition — it's whether you can hold two different lenses at once. A tester who only thinks in severity argues that every crash must be fixed now; a tester who only thinks in priority stops flagging real risk. You need both, and you need to be able to explain the gap to a product manager without sounding like you're escalating for the sake of it.

A defect moves through states that mirror who currently owns it. Typically: New when you raise it, Assigned once a developer picks it up, In Progress / Open while it's being fixed, Fixed when the developer believes it's resolved, Ready for Test once it's deployed to your environment, and then either Verified/Closed if your retest passes, or Reopened if it doesn't.

There are also terminal states that don't involve a fix. Rejected means the developer says it isn't a defect. Duplicate means it's already tracked. Deferred or Won't Fix means it's real but the business has decided not to act now — worth noting, because a deferred bug is a documented, accepted risk, not a bug that vanished.

The detail that separates a junior answer from a good one: the exact state names vary by company and by Jira workflow. What doesn't vary is the ownership handoff. If you can explain who holds the ball at each stage, and what evidence moves it forward, you understand the lifecycle regardless of what the states are called locally.

A good bug report gets fixed. That's the only test of it. Everything else follows from making the developer's job easy.

The title should let someone understand the defect without opening it: what broke, where, and under what condition. "Checkout returns HTTP 500 when the cart contains more than ten items" beats "Checkout bug" every time.

The body needs numbered steps that reproduce it from a known starting state, the expected result, and the actual result. Both, always — the gap between them is the bug. Without expected, you've described an event, not a defect. Add environment (browser, OS, device, build), because that's the first thing a developer asks. Attach evidence: screenshot, video, console error, request ID, log excerpt.

Finally, state reproducibility honestly. "Happens every time" and "seen once, couldn't reproduce" are both useful — but only if you say which. The fastest way to lose a developer's trust is to over-claim reproducibility, have them fail to reproduce it, and get the bug closed.

Treat it as a data problem, not a conflict. The developer isn't lying — they genuinely didn't see it. Something differs between your run and theirs, and finding that difference is the actual work.

First, re-verify cleanly: fresh session, correct environment, correct build number. Confirm you weren't testing an older deployment, which is a genuinely common cause.

Then narrow the variables and hand them over. Environment, browser and version, user role, test data state, feature flag values, timing. Capture hard evidence: a video, the failing request and response, the request ID, the timestamp so they can find it in the server logs. "Here's the request ID, here's the 500, here's the exact time" ends the debate immediately.

If it still won't reproduce for them, offer to pair. Ten minutes screen-sharing beats three days of Jira comments.

And keep the tone collaborative. You're not trying to win — you're trying to protect users. The moment it becomes tester-versus-developer, the bug stops being the subject and the relationship does.

I anchor it to impact on the user and the availability of a workaround, not to how annoyed I am about it.

My rough scale: Critical — the system is unusable, data is lost or corrupted, or there's a security exposure, with no workaround. High — a major feature is broken and the workaround is painful or nonexistent. Medium — a feature is partially broken but a reasonable workaround exists. Low — cosmetic or minor, with no functional impact.

The two questions that resolve most arguments are: what can the user no longer do? and is there another way to do it? A broken button is Medium if there's another route to the same action, and High if there isn't.

I also factor in blast radius: how many users hit this path, and is it a money path? A defect on checkout is treated more seriously than the same defect on an admin settings page nobody visits.

What I avoid is severity inflation. If everything is Critical, nothing is, and the team stops reading your severities.

The classic phases are requirements gathering, design, implementation, testing, deployment, and maintenance. In a waterfall reading, QA sits in one box near the end. In practice — and in any answer that will impress — QA is present in every phase.

During requirements, testers review for ambiguity, testability, and missing edge cases. A requirement you can't write a test for is a requirement nobody has actually defined, and catching that here costs a conversation instead of a release.

During design, QA asks how the thing will be verified: what's observable, what's mockable, what data will exist.

During implementation, QA writes cases, prepares data, and often automates alongside development rather than after it.

During testing, execution happens — but if this is the first time QA sees the feature, the process has already failed.

During deployment and maintenance, QA covers release verification, smoke checks in production, and feeds escaped defects back into coverage.

That last loop — escaped defects becoming new tests — is what makes the cycle a cycle rather than a line.

The Software Testing Life Cycle is the testing-specific counterpart to the SDLC. It describes the sequence of testing activities, each with entry criteria, exit criteria, and deliverables.

The stages are: requirement analysis, where you determine what's testable and identify gaps; test planning, where scope, approach, effort, resources and risks are agreed, producing the test plan; test case design, where scenarios and cases are written and test data is prepared; environment setup, which often runs in parallel and is the stage most likely to blow your schedule; test execution, where cases are run, defects raised, and results tracked; and test closure, where you produce a summary report, capture metrics, and — the part people skip — run a retrospective on what the process missed.

The reason the STLC is worth knowing isn't ceremony. It's that each stage has explicit entry and exit criteria, which is what gives a tester the standing to say 'we cannot start execution, the environment isn't ready' rather than starting anyway and absorbing the blame later.

In Waterfall, testing is a phase that happens after development completes. The consequence is a long feedback loop: a requirements defect introduced in month one might not be discovered until month six, when it is enormously expensive to fix.

The V-model keeps the sequential structure but pairs each development stage with a corresponding test stage — requirements pair with acceptance tests, high-level design with system tests, detailed design with integration tests, code with unit tests. Its contribution is that test design starts early, even though execution is still late. It makes verification planning explicit.

Agile dissolves the phase boundary. Testing happens continuously inside each iteration, testers sit in the team rather than in a separate department, and the feedback loop shrinks from months to days or hours. The trade-off is that documentation is lighter and testers must operate with less up-front certainty — you're often designing tests against acceptance criteria that are still being negotiated.

The honest summary: none of them prevents defects. What changes is how quickly you find out, and therefore how much a defect costs.

Entry criteria are the conditions that must be true before a testing phase can meaningfully start. Exit criteria are the conditions that must be true before it can be declared finished.

Typical entry criteria for system testing: the build is deployed to the correct environment, smoke tests pass, unit tests are green, test data exists, and the test cases are reviewed. Typical exit criteria: an agreed percentage of planned cases executed, no open Critical or High defects, all Critical paths passing, and the known-risk list documented and accepted.

The practical value is that criteria convert opinion into agreement. Without exit criteria, 'are we done testing?' becomes a negotiation driven by whoever is loudest about the deadline. With them, it becomes a checklist you agreed to before the pressure started — which is precisely why you write them early, when everyone is still calm.

The senior nuance: exit criteria should include what you did not test. A signed-off release with documented untested areas is honest. A signed-off release that implies everything was covered is a lie you'll pay for later.

Shift-left means moving quality activity earlier in the delivery timeline, toward the left of a left-to-right schedule. The premise is economic: a defect caught in a requirements review costs a conversation; the same defect caught in production costs a hotfix, a rollback, possibly a customer.

In practice it looks like: testers reviewing requirements and acceptance criteria before code exists; the three-amigos conversation between product, dev and QA; developers writing unit tests and running them locally; static analysis and linting in the pipeline; API-level tests running on every pull request instead of a UI regression pack running once a week.

The part people miss is that shift-left is not 'testers do more work earlier'. It's a redistribution: quality becomes the whole team's responsibility, and the tester's role tilts from finding defects to preventing them and from executing checks to designing the strategy that decides which checks are worth running.

And there is a right-hand side too. Shift-right — monitoring, canary releases, observability in production — is the acknowledgement that you will never catch everything before release, so you'd better detect it fast afterwards.

Verification asks: are we building the product right? Validation asks: are we building the right product?

Verification is conformance to specification. It's largely static — reviews, walkthroughs, inspections, static analysis — and it checks the work against the documents that describe it. If the spec says the password field must accept 8–64 characters and it does, verification passes.

Validation is conformance to actual need. It's dynamic — you execute the software and check it against what the user genuinely requires. Validation is where you discover that the 8–64 character rule is fine but the error message is incomprehensible, or that nobody wanted this feature in the first place.

The reason both exist is that a product can pass verification completely and still be worthless. You can build exactly what the specification said and discover the specification was wrong. That's the failure mode validation exists to catch — and it's why user acceptance testing sits at the end rather than being folded into system testing.

They nest inside one another, from broad to narrow.

Quality Assurance is process-oriented and preventive. It asks how we work: are our requirements reviewable, are our definitions of done meaningful, is our pipeline gated, do we run retrospectives that change anything. QA tries to stop defects being created.

Quality Control is product-oriented and detective. It examines the artifact that was built to find defects that already exist. Reviews, inspections and testing all live here.

Testing is one activity within QC: executing the software with the intent of finding defects and evaluating whether it meets requirements.

The reason this matters beyond terminology is that most job titles say 'QA Engineer' while most of the work described is testing. A candidate who understands the distinction can talk about improving the process — reducing how many defects get created — not just finding more of them. That's the difference between a tester and a quality engineer, and it's exactly the distinction a senior interview is probing for.

Static testing examines artifacts without executing the code. Dynamic testing runs the software and observes behaviour.

Static techniques include requirement reviews, design walkthroughs, code reviews, pair programming, and automated static analysis or linting. What they catch is a specific class of defect: ambiguity, contradiction, missing cases, unreachable code, unsafe patterns, violated conventions.

Dynamic testing is everything you'd normally picture — unit, integration, system, acceptance, performance — where you supply inputs and compare actual results to expected ones.

The value proposition of static testing is timing. It runs before executable software exists, which makes it the earliest and cheapest place to catch a defect. A contradictory requirement caught in review costs a fifteen-minute conversation; the same contradiction discovered by a tester three weeks later costs rework across design, code and tests.

The limitation is equally clear: static testing cannot tell you whether the system actually works. Only running it does that. They're complements, not alternatives, and a team that does one without the other is leaving defects on the table.

Smoke testing is a shallow, wide check that a new build is stable enough to be worth testing at all. Can you log in, load the main screens, complete the core journey? If smoke fails, you stop and reject the build rather than wasting a day discovering that nothing works. It's usually scripted, usually automated, and usually the same set every time.

Sanity testing is a narrow, deeper check performed after a small change or a bug fix, focused on the specific area that changed and its immediate surroundings. If a defect in the promo-code calculation was fixed, sanity means checking that promo codes now behave — and that the neighbouring pricing logic didn't break — without re-running the entire regression suite.

The mental model I use: smoke is wide and shallow across the whole application; sanity is narrow and deep on the part that just changed. Smoke answers 'is this build worth testing?'. Sanity answers 'did this fix actually work, and did it break the neighbourhood?'

In practice, teams use the words loosely and sometimes interchangeably. What matters in an interview is that you can articulate the distinction in intent.

Retesting verifies a specific fix. A defect was raised, a developer fixed it, and you execute the exact steps from the bug report on the new build to confirm the defect is gone. It's targeted, it uses the failing case, and it either passes or the bug is reopened.

Regression testing verifies that the change didn't break anything that used to work. It's not aimed at the fix; it's aimed at everything around it. The suite is made of previously-passing tests, and the question is whether they still pass.

Two consequences follow. First, retesting is always on failed test cases, regression always on passed ones. Second, retesting cannot be skipped and cannot be automated ahead of time — you don't know the steps until the bug exists — whereas regression is the canonical candidate for automation precisely because it's repetitive, predictable, and grows forever.

If a build has a fix in it, you do both: retest the fix, then regress the surrounding area to make sure the cure wasn't worse than the disease.

Functional testing checks what the system does — does the feature behave according to its requirements. Can a user log in with valid credentials, is the discount applied correctly, does the order appear in the history. It's largely a question of correct outputs for given inputs.

Non-functional testing checks how well the system does it. Performance (is it fast enough under load), security (can it be abused), usability (can a real person complete the task), reliability (does it stay up), compatibility (does it work on the browsers and devices your users actually have), accessibility (can someone using a screen reader complete the journey), and scalability.

The reason this distinction earns marks is that non-functional defects are the ones that damage a business most and get tested least. A feature that works perfectly but takes eleven seconds to load is, in the user's experience, broken. A checkout that is functionally flawless and leaks card data is a catastrophe.

In interviews, candidates over-index on functional testing because that's what they do daily. Being able to name concrete non-functional risks for the product you're discussing is a strong senior signal.

The distinction is how much of the internal implementation the tester can see.

Black box: you know the inputs and the expected outputs, but nothing about the internals. You test against requirements and behaviour. Most system, acceptance and exploratory testing is black box. Its strength is that you test what the user experiences; its weakness is that you can't know which code paths you've missed.

White box: you can see the code and design tests against its structure — covering branches, conditions, loops, error handlers. Unit testing is the obvious example. Its strength is precision about coverage; its weakness is that you can achieve 100% code coverage and still miss a requirement that was never implemented, because you can only test the code that exists.

Grey box sits between: partial knowledge. You don't read every line, but you know the architecture, the database schema, or the API contracts, and you use that to design smarter tests — checking the database directly after a UI action, for example, or targeting a service you know is fragile.

Most experienced testers work in grey box whether they call it that or not.

Both are forms of acceptance testing performed before general release; the difference is who runs them and where.

Alpha testing happens internally, at the organisation's own site, typically by employees who are not the developers — an internal QA team, sometimes staff from other departments acting as users. The environment is controlled, the testers are reachable, and issues can be reproduced with the developers standing next to you.

Beta testing happens externally, with real users in their own environments, using their own devices, data and network conditions. That's precisely the point: it surfaces the problems no internal environment can simulate — a browser you never tested, a locale you didn't consider, a workflow real people use that nobody designed for.

The trade-off is control versus realism. Alpha gives you fast, clean, reproducible feedback in an artificial setting. Beta gives you messy, slow, sometimes unreproducible feedback from reality. Mature teams do both, and treat beta findings as signal about their coverage gaps, not just as a list of bugs to fix.

UAT is the final validation that the software solves the business problem it was built for. It's performed by the people who represent the users: business stakeholders, product owners, domain experts, or actual end users — not by the QA team, and definitely not by the developers.

The distinction from system testing matters. System testing asks 'does it meet the specification?' UAT asks 'does it meet the need?' Those diverge more often than people expect. A feature can satisfy every acceptance criterion and still be rejected in UAT because the workflow doesn't match how the business actually operates — which is a requirements failure surfacing very late.

QA's role in UAT isn't to execute it. It's to make it succeed: prepare a stable environment, provide realistic test data, write scenarios in business language rather than test-speak, support the users while they test, and triage what they find — separating genuine defects from misunderstandings and from change requests dressed up as bugs.

That last piece of triage is where most UAT cycles go wrong.

Equivalence partitioning divides the input space into groups where every value in a group should be treated identically by the system. If they're treated identically, testing one value from the group gives you the same information as testing all of them — so you test one, and you've covered the partition.

Take an age field that accepts 18 to 65. That yields three partitions: below range (anything under 18), valid range (18–65), and above range (over 65). One representative from each — say 10, 35, and 70 — covers the logic with three tests instead of ninety-eight.

The technique's power is economic: it's a defensible way to reduce test count without pretending you've covered everything. Its limitation is that partitions are only as good as your assumption that the system really treats the group uniformly. If the code has a special case at 21 that you didn't know about, your partition hides it.

That's why in practice you pair it with boundary value analysis, which targets the edges where the assumption most often breaks.

Boundary value analysis targets the values at the edges of a partition, because that's where defects concentrate. The reason is mundane and human: boundaries are where programmers write comparison operators, and >= versus > is the easiest mistake in software.

For a field accepting 1 to 100, the boundary values are 0 (just below minimum, must be rejected), 1 (minimum, must be accepted), 2 (just inside), 99 (just inside upper), 100 (maximum, must be accepted) and 101 (just above, must be rejected). Some teams use a two-value approach (just each side of the boundary), some a three-value approach (below, on, above). Either is defensible if you can explain it.

What makes it effective is defect density: empirically, off-by-one errors cluster at edges far more than in the middle of a range. Testing 47 tells you very little that testing 50 didn't. Testing 100 versus 101 tells you whether the developer got the inclusive/exclusive comparison right.

In an interview, the sentence that lands is: partitions tell me where to test, boundaries tell me exactly which value.

A decision table maps combinations of input conditions to the actions or outputs the system should produce. You list the conditions as rows, enumerate the possible combinations as columns, and record the expected outcome for each column. Each column becomes a test case.

It earns its keep when business logic depends on combinations of conditions rather than individual values. Insurance pricing, discount eligibility, loan approval, access control — anywhere a rule reads 'if the customer is a member AND the order is over 100 AND the promo code is valid, apply 20%'.

The technique's strength is that it makes gaps visible. When you enumerate combinations systematically, you discover the ones the requirements never mentioned — what happens if the promo code is valid but the customer isn't a member? Very often nobody has decided, and the decision table is what surfaces that before the code is written.

The cost is combinatorial growth: n binary conditions produce 2^n columns. In practice you collapse impossible or irrelevant combinations, or move to pairwise testing when the table becomes unmanageable.

State transition testing models the system as a set of states and the events that move it between them. You define the valid states, the transitions, the events that trigger each transition, and the actions that result. Test cases then walk the paths.

It applies whenever behaviour depends on history rather than only on current input. An order that is Draft, Submitted, Paid, Shipped, Delivered, Cancelled. A user account that is Active, Locked after three failed attempts, then Unlocked. A booking that can be Held, Confirmed, Checked-in.

The technique finds two classes of defect that other approaches miss. First, invalid transitions — can you cancel an order that's already delivered, can you pay twice, can you check in for a cancelled flight? These are the security- and money-relevant bugs. Second, unreachable or dead states that the design implies but the code never allows.

Coverage is expressed in terms of states visited, transitions exercised, or (more rigorously) sequences of transitions. In interviews, drawing the diagram out loud and then pointing at the transitions nobody defined is exactly the behaviour being assessed.

Pairwise testing is a combinatorial reduction technique. Instead of testing every combination of every parameter — which explodes exponentially — you generate a much smaller set of cases in which every pair of parameter values appears together at least once.

The justification is empirical rather than theoretical: studies of real defect data have repeatedly found that the large majority of defects are triggered by a single parameter or by an interaction between just two parameters. Faults requiring three or more specific values interacting are comparatively rare. So covering all pairs buys you most of the defect-finding power for a fraction of the tests.

A concrete case: browser (4 options) × OS (3) × payment method (5) × user type (3) is 180 exhaustive combinations. A pairwise set typically covers all value-pairs in roughly 20 cases.

The honest caveat — and the thing that earns senior marks — is that pairwise is a risk-reduction technique, not a guarantee. It will miss a defect that only appears when three specific values coincide. So you use it for broad configuration coverage and then hand-pick the high-risk combinations you know matter, rather than trusting the generator blindly.

Error guessing is designing tests based on experience of where defects tend to hide, rather than on a formal derivation from the specification. It's the tester who immediately tries an empty submit, a negative quantity, a double-click on Pay, a very long name with an apostrophe in it, a session left idle for an hour, a back-button after checkout.

It is absolutely legitimate — and it's also the technique most dependent on the individual. Its power scales with how many systems you've broken before. That's why it's a genuine argument for hiring experienced testers rather than treating testing as a purely mechanical exercise.

The way to make it defensible rather than random is to systematise it: maintain a defect taxonomy or a checklist of failure patterns your team keeps hitting — boundary handling, null and empty inputs, duplicate submissions, concurrency, timezone and locale, permission escalation, back-button and refresh behaviour. Then error guessing becomes a repeatable heuristic rather than a personal talent that leaves when the person does.

In interviews, this question is a chance to show you understand that formal techniques don't catch everything, and that experience is a tool you deliberately apply.

The number isn't the answer — the structure is. Interviewers ask this to see whether you enumerate randomly or reason in categories. So I'd answer by naming the categories, then filling them.

Positive: valid username and password logs in and lands on the right page. Negative: wrong password, wrong username, both wrong, empty fields, whitespace-only. Boundary: minimum and maximum password length, exactly at the character limits. Security: account lockout after N failed attempts, and does the error message reveal whether the username exists (it should not); SQL injection and XSS strings in both fields; password masked; no credentials in the URL. Session: remember-me behaviour, session timeout, back-button after logout must not restore the session, concurrent login from two devices. Usability and accessibility: tab order, Enter key submits, screen reader labels, error messages that a human can act on. Compatibility: browsers and devices your users actually have. Localisation: unicode characters, right-to-left languages.

That's the answer they're scoring. If they push for a number, I'd say roughly 25–40 cases depending on the security requirements — and note which I'd automate first.

A test scenario is a high-level statement of what to test — 'verify that a user can pay with a saved card'. It describes intent, gives coverage at a glance, and is readable by a product owner.

A test case is the executable detail beneath it: preconditions, test data, ordered steps, expected result, and postconditions. From that one scenario you might derive several cases — pay with a valid saved card, pay with an expired saved card, pay when the saved card is declined, pay when the saved card has been deleted on another device.

So the relationship is one-to-many: scenarios give you breadth and stakeholder communication; cases give you depth and repeatable execution.

Where it matters practically: in a fast-moving Agile team, heavy test cases go stale quickly and cost more to maintain than they return. Many teams therefore write scenarios plus a checklist of conditions, and rely on the tester's judgement for the steps. That's a legitimate trade-off, not laziness — but it depends on having testers experienced enough to fill the gap, and on the domain not being regulated.

A test strategy is the organisation's standing approach to testing: the layers we test at, the tools we standardise on, the environments we maintain, our automation philosophy, our defect and severity conventions, our quality gates. It's relatively stable, it applies across projects, and it's usually owned at a QA-lead or engineering-manager level.

A test plan is project- or release-specific and tactical: what's in scope, what's explicitly out of scope, the schedule, the resources, the environments needed, the entry and exit criteria, the risks and their mitigations, and who is doing what.

A useful way to hold it: strategy is how we test here; plan is how we're testing this.

In practice, in smaller companies the two collapse into a single document and nobody minds. In regulated or enterprise environments they're deliberately separate, because the strategy is audited and the plan is negotiated per release.

The senior signal isn't reciting the difference — it's knowing which artifact to reach for when someone asks 'what's the plan?', and being able to write both without producing forty pages nobody reads.

The sections I'd never drop, roughly in order:

Scope — what will be tested, and, more importantly, what will not be. Explicit out-of-scope is the single strongest signal of a mature plan; it prevents the argument at the end of the release about why something wasn't covered.

Approach — what testing happens at which layer, and how (API regression here, UI smoke there, exploratory sessions on the new flows). A single-layer plan is a red flag.

Environments and test data — what's needed and who provides it. This is where schedules die.

Entry and exit criteria — the agreed definition of ready-to-start and done.

Risks and mitigations — a plan with no risks section tells stakeholders you haven't thought hard enough.

Schedule, resources and responsibilities — who does what, by when.

Deliverables — reports, metrics, defect summaries.

Everything else is optional. The failure mode is a forty-page document nobody reads, produced because a template demanded it. A good plan is short enough that the team actually reads it and specific enough that a stakeholder can see what risk they're accepting.

An RTM maps requirements to the test cases that verify them, and often onward to the defects raised against them. It's a coverage ledger.

It answers two questions that are hard to answer any other way. Forward: is every requirement covered by at least one test? — which exposes gaps. Backward: does every test trace to a requirement? — which exposes tests that exist for no stated reason, either because they're obsolete or because they're testing an undocumented behaviour that someone should write down.

Its practical value spikes in two situations. In regulated domains — medical, aviation, finance — traceability is often a compliance requirement, not a nice-to-have; you must demonstrate coverage to an auditor. And during impact analysis: when requirement 47 changes, the matrix tells you in seconds which tests must be re-run, instead of re-running everything or guessing.

The honest downside is maintenance. In a fast-moving Agile team, an RTM maintained by hand rots quickly and becomes a lie in spreadsheet form. Which is why teams increasingly derive traceability from tooling — linking tests to stories in Jira or Xray — rather than maintaining a separate document.

I care about metrics that change a decision. If nobody would act differently based on the number, it's decoration.

The ones I trust: escaped defects (defects found in production versus found in testing) — this is the closest thing to a scoreboard for the whole quality process. Defect removal efficiency, the same data expressed as a percentage. Flake rate in the automated suite, because a suite people don't trust is worse than no suite. Mean time to detect and to resolve, which tells you whether feedback loops are healthy. And cycle time from bug raised to bug closed, which surfaces process friction.

The ones I'm sceptical of: raw test case count (rewards writing shallow tests), pass rate in isolation (a 100% pass rate can mean weak assertions), and code coverage as a target — the moment coverage becomes a goal, people write tests that touch code without asserting anything, and you get the number without the safety.

That's the lead-level point: no metric survives being turned into a target. I present them as a set, with the caveat of what each one can hide.

Defect density is defects per unit of size — commonly defects per thousand lines of code, per function point, or per module. Its purpose is comparison, not judgement in the abstract. A density of 3 means nothing on its own; a density of 3 in the payments module versus 0.4 everywhere else means you've found where to concentrate testing and code review.

Defect removal efficiency is the share of defects your process caught before release: defects found internally, divided by all defects found internally plus those found in production, expressed as a percentage. If you found 90 in testing and users found 10, DRE is 90%.

DRE is the more useful of the two, because it measures the whole quality system rather than a code artifact. But it has a lag: you can't compute it until production defects arrive, so it's a trailing indicator, and it's only honest if production defects are actually recorded and attributed.

The caveat worth voicing: both metrics are gameable. Density falls if you stop finding defects. DRE improves if production defects go unlogged. Numbers about quality are only as honest as the culture reporting them.

Exploratory testing is simultaneous learning, test design and execution. You don't write the cases first and then run them; you use what you observe to decide what to try next. Each result reshapes the plan.

It is not ad-hoc flailing. Done well, it's structured by charters — a stated mission for a time-boxed session, such as 'explore promo code application on mobile checkout, focusing on expired and stacked codes, for 60 minutes'. You take notes, record what you covered, and debrief.

When it's the right choice: new or poorly-specified features; areas where requirements are thin; after a big refactor when you don't yet know what moved; and any time you want to find the defects that scripted tests structurally cannot — because scripted tests only check what someone already thought of.

That's the core argument. A scripted suite is a memory of past thinking. Exploratory testing is where new thinking happens, and it's consistently where the surprising, high-value defects come from. The mature position is not exploratory versus scripted — it's using automation for the known, and human exploration for the unknown.

Session-based test management is the framework that makes exploratory testing accountable. It answers the manager's fair objection — 'if you're not following a script, how do I know what you did?'

The unit is a session: a time-boxed, uninterrupted block (typically 45–90 minutes) with a stated charter — the mission for that session. During it, the tester takes notes covering what was tested, what was found, what questions arose, and what was left unexplored. Afterwards there's a short debrief with a peer or lead.

Sessions are then measured in a lightweight way: how much time went to on-charter testing versus investigating bugs versus setup (the classic 'test / bug / setup' split). Over time this data reveals uncomfortable truths, like the fact that 40% of testing time is being consumed by environment problems.

What this buys you is the freedom of exploratory testing with the traceability of scripted testing. You can report coverage in terms of charters completed, you can plan capacity, and you can hand a manager evidence — without pretending that pre-written scripts were followed when they weren't.

Ad-hoc testing is unstructured and largely unrecorded — you poke at the application informally, without a mission, without notes, and usually without a way to say afterwards what you covered. It has some value (a fresh pair of eyes finds things), but it isn't repeatable, isn't reportable, and isn't a strategy.

Exploratory testing looks superficially similar because there's no pre-written script, but it is deliberately structured. There's a charter defining the mission and its scope. It's time-boxed. Coverage is recorded. Findings are debriefed. Crucially, the design of each next test is an explicit reasoning step based on what you just learned — that's the discipline.

The distinction matters in interviews because a lot of candidates use the words interchangeably, which suggests they've only ever done the ad-hoc version and called it exploratory. Being able to articulate charters, note-taking and debriefs is the tell that you've actually practised the technique rather than just clicking around and hoping.

Short version: ad-hoc is unplanned. Exploratory is unscripted but not unplanned. Those are very different things.

Risk-based testing allocates testing effort in proportion to risk, where risk is roughly likelihood of failure × impact of failure. You cannot test everything; risk-based testing is the defensible way to choose what not to test.

In practice: enumerate the areas of the product, score each on how likely it is to break (complexity, churn, recent changes, defect history, developer confidence) and how badly it would hurt if it did (money, data loss, safety, reputation, number of users affected). Multiply, rank, and let that ranking drive both depth of coverage and order of execution.

The consequences are practical. Checkout and payments get deep coverage and run first. The admin export screen used by three internal users gets a smoke check. A brand-new module written under time pressure by someone unfamiliar with the codebase gets more attention than a stable module untouched for two years — even if the stable module is more 'important' in the abstract, because likelihood matters as much as impact.

The reason interviewers love this question is that it's the difference between a tester who executes and one who prioritises. And the follow-up is always: what did you decide not to test, and how did you communicate that risk?

I don't test faster — I test narrower, deliberately, and I make the residual risk visible so the ship decision is made with open eyes.

Concretely: first, establish what actually changed. Pull the diff, the merged stories, the touched modules. Testing effort follows change, not tradition.

Second, rank by risk — money paths, data integrity, authentication, anything touching payments or personal data goes first. Run automated regression on those areas immediately, since it costs almost nothing to trigger.

Third, spend the human hours on the new and changed functionality via exploratory sessions, because that's where scripted regression has no coverage anyway.

Fourth — and this is the part that separates the answer — I write down what will not be tested, and I send it to the stakeholders before the deadline, not after the incident. 'These areas are covered, these are partially covered, these are not covered at all, and here is the risk if they fail.'

The decision to ship with that risk belongs to the business. My job is to make sure they're making an informed decision rather than an accidental one. What I don't do is quietly cut corners and let everyone assume it was fully tested.

I'd never answer 'I'd wait for requirements' — that's the response of someone who can't operate in ambiguity, which is most of real work.

There are always sources of truth, even when there's no document. I'd talk to whoever asked for the feature and to the developer who built it, and write down what they say — that conversation is the requirement, and capturing it is useful to everyone. I'd look at how comparable features in the same product behave, since internal consistency is an implicit requirement. I'd look at competitors or industry norms for what users will expect. I'd read the code or the API contract if I can. And I'd look at analytics or logs if the feature is live, because real usage tells you which paths matter.

Then I'd test exploratorily against those inferred expectations, recording every assumption I'm making as I go.

The deliverable at the end isn't just a defect list — it's the documentation that didn't exist. I hand back a written description of how the feature actually behaves, with my assumptions flagged for confirmation. That converts a testing problem into a requirements artifact the team keeps, which is far more valuable than the bugs alone.

Testers aren't spectators in Agile ceremonies; each one has a specific contribution.

In backlog refinement, the tester is the person asking the awkward questions: what happens if this fails, what's out of scope, how will we know it works. This is where testability gets designed in — or lost.

In sprint planning, the tester surfaces the testing effort so it's part of the estimate, not an afterthought squeezed into the last two days. If a story needs a new environment or test data that doesn't exist, that's said here.

In the daily stand-up, the tester flags blockers early — environment down, build not deployed, story handed over on day nine of a ten-day sprint.

In the review/demo, the tester often demonstrates, and speaks honestly about what was and wasn't covered.

In the retrospective, the tester brings the quality signal: what escaped, what was flaky, what process caused rework.

The underlying point is that testers shift from a downstream inspection role to an upstream prevention role. The best sprint is one where you found the defect in refinement and it never got written.

Acceptance criteria are specific to one story: the conditions that must be true for this piece of functionality to be considered correct. 'A user with an expired card sees an error and is not charged.' They're written per-story and they define what the feature must do.

Definition of Done is a team-wide standard that applies to every story regardless of content. Typically it includes things like: code reviewed, unit tests written and passing, automated regression green, acceptance criteria verified, no open Critical or High defects, documentation updated, deployed to staging. It defines how complete work must be before anyone can call it finished.

So: acceptance criteria vary story to story; DoD is constant. A story can meet every acceptance criterion and still not be Done — if it was never code reviewed, or the regression suite is red.

The reason a tester cares deeply: DoD is where quality gates are made non-negotiable at the team level. Getting 'automated tests written and passing' into the DoD does more for quality than any amount of arguing story-by-story. It converts a request into a rule.

The three amigos is a short conversation between three perspectives before a story is built: business (product owner — what problem are we solving and why), development (how might we build it, what's technically constrained), and testing (how will we know it works, what could go wrong, what happens at the edges).

The point is that these three perspectives ask different questions, and the gaps between them are where defects are born. A product owner rarely thinks about the concurrency case. A developer rarely thinks about what the business does when the third-party payment provider is down. A tester rarely knows that the underlying service can't support the workflow being described. Fifteen minutes together surfaces all three.

The output is usually clarified acceptance criteria, sometimes written as concrete examples or Given/When/Then scenarios, and a shared understanding that means the developer doesn't build the wrong thing and the tester doesn't discover the ambiguity two weeks later.

The economics are what make it worth advocating for: this is the cheapest defect prevention available. A misunderstanding caught in a fifteen-minute conversation costs nothing. The same misunderstanding caught in UAT costs rework across design, code, and tests.

This is the most common dysfunction in Agile teams, and the wrong response is to test faster and absorb it, because that hides the problem and guarantees it repeats.

Short-term, I mitigate: get involved before the code is finished — review the branch, test the API layer while the UI is still being wired, write and dry-run the test cases against the acceptance criteria so that execution is fast when the build lands. Ask developers to merge in smaller increments so testing can start on part of the story rather than waiting for all of it.

But the real fix is structural, and I'd raise it in the retro with data, not complaints: show the pattern — stories handed over on day nine, testing compressed to a day, defects found after the sprint ends, carry-over rising. That's a team problem, not a QA problem.

The systemic remedies are: smaller stories that finish sooner; a work-in-progress limit so developers finish before starting the next thing; adding 'testable increments delivered mid-sprint' to the working agreement; and making testing time part of the estimate at planning rather than a tax paid at the end.

The framing matters: this is a flow problem in the team's process, and it needs the team to fix it.

Not everything gets automated in the sprint it's built. The decision is economic: automation is an investment with a build cost and a maintenance cost, and it pays back only through repetition.

My rule of thumb: automate it in-sprint if the test will run many times (it's part of the regression path), the functionality is stable enough that the test won't be rewritten next sprint, and the check is deterministic. Payment flows, login, core journeys — these earn automation immediately.

I defer or skip automation when the UI is still in flux (automating a screen that's being redesigned next sprint is throwing money away), when the check is a one-off validation, when the setup cost is enormous relative to the risk, or when the thing being tested is genuinely a human judgement — visual polish, usability, 'does this feel right'.

One practical pattern: automate at the lowest layer that can catch the bug. A validation rule doesn't need a UI test; an API test is faster, more stable, and cheaper to maintain. A lot of automation debt comes from testing at the UI layer things that never needed to be there.

And the honest caveat: an automated test you don't trust is worse than no test.

REST is an architectural style for APIs where you address resources by URL and act on them with standard HTTP methods. It's stateless — each request carries everything needed to process it, and the server doesn't remember your last call.

The methods carry meaning. GET retrieves and should never change state (it's safe). POST creates and is not idempotent — call it twice and you get two resources. PUT replaces a resource entirely and is idempotent — call it twice with the same body and the end state is identical. PATCH partially updates. DELETE removes, and is idempotent (deleting an already-deleted thing should still leave it deleted).

Status codes come in families. 2xx succeeded — 200 OK, 201 Created (expect this from a POST), 204 No Content. 3xx redirection. 4xx the client got it wrong — 400 Bad Request, 401 Unauthenticated (you haven't proved who you are), 403 Forbidden (you have, and you're still not allowed), 404 Not Found, 409 Conflict, 429 Too Many Requests. 5xx the server got it wrong — 500 Internal Server Error, 503 Unavailable.

The 401-versus-403 distinction is a classic follow-up, and a lot of candidates get it backwards.

I'd work from the contract — the Swagger/OpenAPI spec if it exists — and build a collection that mirrors real usage rather than isolated calls.

Start with the happy path for each endpoint: correct method, correct headers (content-type, auth token), valid body. Assert status code, response body fields and types, and response time.

Then chain the requests so you're testing a workflow, not a list: create a resource with POST, capture the returned ID into an environment variable, GET it back and verify the data persisted correctly, PUT an update and verify the change, DELETE it and verify a subsequent GET returns 404. That chain catches integration defects that individual calls never will.

Then the negatives, which is where the real defects are: missing required fields, wrong data types, values outside boundaries, malformed JSON, missing auth token, expired token, a token belonging to a different user trying to access this resource (that's the authorisation test people forget), and unsupported methods.

I'd use environments to switch between staging and QA without editing every request, and write assertions in the Tests tab so the collection can later be run as a suite via the collection runner.

Status code is the shallowest possible assertion. A response can return 200 and still be wrong in a dozen ways.

Response body correctness — are the values right, not merely present? Schema and types — if a field silently changes from an integer to a string, every consumer breaks; a schema assertion catches that, a value assertion often won't. Required fields present, and no unexpected fields leaked — an API returning a password hash or an internal flag is a security defect that returns a cheerful 200.

Authorisation, not just authentication — can user A read user B's record by changing the ID in the URL? That's the classic insecure-direct-object-reference bug and it is everywhere.

Error contract consistency — do failures return a predictable shape, or does one endpoint return a JSON error object and another return an HTML stack trace?

Idempotency on PUT and DELETE. Pagination boundaries. Rate limiting behaviour. Performance under a realistic payload. And side effects: did the record actually change in the database, and did the downstream event get published?

That last one is what separates API testing from API poking.

Because the UI lies. It shows you what the front end renders, not what the system actually stored — and the gap between those two is where a whole class of defects lives.

Concretely, I use SQL for four things. Verification: after an action in the UI, check the database actually recorded what it should — right values, right foreign keys, right timestamps, right status. A booking that displays as confirmed but is stored as pending will eventually cause an incident.

Test data setup: creating a user in a specific state directly is faster and more reliable than clicking through six screens to reach it — and it lets you construct states the UI can't produce, like an account that's been dormant for two years.

Investigation: when a defect is intermittent, the data usually tells you why. Duplicate rows, nulls where the code assumed a value, an orphaned record from a partially-failed transaction.

Cleanup: removing test data so runs don't collide.

The queries a tester actually needs are unglamorous — SELECT with WHERE, JOINs across a couple of tables, GROUP BY with COUNT to find duplicates, ORDER BY and LIMIT. You don't need to be a DBA. You need to be able to check your own work.

To find duplicate emails in a users table, group by the column and keep only the groups with more than one row:

SELECT email, COUNT(*) AS occurrences
FROM users
GROUP BY email
HAVING COUNT(*) > 1
ORDER BY occurrences DESC;

The key detail interviewers listen for is HAVING versus WHERE: WHERE filters individual rows before grouping; HAVING filters the groups after aggregation. You cannot use COUNT(*) in a WHERE clause, and candidates trip on this constantly.

On JOINs: an INNER JOIN returns only rows with a match in both tables. A LEFT JOIN returns every row from the left table, with NULLs where the right table has no match. That NULL is the useful part for a tester — a LEFT JOIN with WHERE right.id IS NULL is how you find orphans: orders with no matching customer, test results with no matching test case.

SELECT o.id
FROM orders o
LEFT JOIN customers c ON o.customer_id = c.id
WHERE c.id IS NULL;

That query — finding records that should have a relationship and don't — catches genuine data-integrity defects, and it's a strong thing to be able to write on a whiteboard.

I start from data, not from a matrix someone wrote in 2019. Analytics tells you which browsers, versions, operating systems and screen sizes your users actually have. Testing Internet Explorer because it's on the standard list, while ignoring the Android WebView that 30% of your users are on, is a common and expensive mistake.

From there I build a tiered matrix. Tier 1 — the combinations covering the large majority of traffic — gets full functional coverage. Tier 2 — meaningful but smaller segments — gets the critical journeys only. Tier 3 — the long tail — gets a smoke check, or a documented decision not to support it.

What I look for differs from functional testing: layout and responsive breakpoints, font rendering, date and number formatting, touch versus click behaviour, virtual keyboard covering inputs, gestures, orientation change, and browser-specific handling of things like file upload and date pickers.

Execution-wise, a cloud device farm beats a drawer of physical phones for coverage, but I keep at least one real device for the things emulators lie about — actual touch responsiveness, real network conditions, and battery/performance behaviour.

And I'd automate the repetitive layout checks rather than clicking through thirty combinations by hand.

Accessibility testing checks that people with disabilities can actually use the product — visual, motor, auditory and cognitive. In many markets it's also a legal requirement, and increasingly it's contractually required in enterprise and government procurement, which is often what finally gets it funded.

The reference standard is WCAG, organised around four principles: content must be perceivable, operable, understandable and robust. Most organisations target level AA.

Where I'd start, in order of value per hour: keyboard-only navigation — unplug the mouse and try to complete the core journey; if you can't tab to it, activate it, and see where the focus is, the feature is unusable for a large group. Then screen reader testing on the critical path with a real reader (NVDA or VoiceOver), because that surfaces missing labels, unlabelled buttons, and images with no alt text. Then colour contrast and the rule that colour alone must never carry meaning — a red border on an invalid field means nothing to a colour-blind user without accompanying text.

Automated tools like axe catch perhaps a third of issues — the mechanical ones. The rest need a human. That honesty is worth stating: automated accessibility scans are a floor, not a certificate.