QA Engineer Interview Questions & Answers

1. How do you decide what to test when you can't test everything?

Why they ask: The single most important QA skill. They want risk-based prioritization, not "I'd test all of it" — which is impossible and signals you don't understand the constraint.

"You can never test everything — the input space is effectively infinite — so I test by risk, not by exhaustion. I weight each area by two factors: the probability it breaks and the cost if it does. A rarely used admin export failing is annoying; a checkout flow or an auth boundary failing is a business incident, so those get the deepest coverage. I use equivalence partitioning and boundary-value analysis to collapse huge input ranges into a handful of representative cases — one valid case per partition plus the edges, zero, negative, max, and the off-by-one around limits. I also let the data guide me: where defects clustered historically, what changed in this release, and the most-used paths in production. The goal is the highest defect-detection per hour, with the riskiest things covered first so that if I run out of time, I've already protected what matters most."

2. How would you test a login page?

Why they ask: The classic open-ended test-design prompt. They're watching whether you go beyond the happy path into negative, security, and edge cases in a structured way.

"I'd structure it in layers rather than listing random cases. Functional: valid credentials log in, the right landing page loads, 'remember me' and logout work. Negative: wrong password, nonexistent user, empty fields, and clear, non-revealing error messages. Boundary & input validation: max-length fields, leading/trailing spaces, Unicode and emoji, SQL-injection and XSS payloads in the inputs. Security: credentials sent over HTTPS, password masked and not logged, rate-limiting and account lockout after repeated failures, session expiry and token handling. UX & accessibility: tab order, screen-reader labels, error focus, and the form working on mobile. Cross-environment: the major browsers and devices. I'd start by asking clarifying questions — is there SSO, 2FA, a password-reset flow? — because half the value here is showing I scope before I test."

3. Explain the test pyramid and how you'd structure a suite.

Why they ask: Tests whether you understand automation economics. Many candidates over-invest in slow, brittle UI tests; they want someone who knows where coverage belongs.

"The test pyramid says: many fast unit tests at the base, fewer integration and API tests in the middle, and a thin layer of end-to-end UI tests at the top. The reason is economics and stability — unit tests run in milliseconds, pinpoint the failure, and rarely flake; end-to-end tests are slow, brittle, and tell you that something broke without telling you where. The anti-pattern is the inverted 'ice-cream cone' of mostly UI tests: a slow suite that fails for reasons unrelated to real bugs until everyone stops trusting it. So I push coverage as low as it can meaningfully live — business logic to unit tests, service contracts to API and integration tests — and reserve end-to-end for a small set of critical journeys like sign-up, checkout, and login. I'd rather have fifteen rock-solid end-to-end tests that gate a release than two hundred flaky ones everyone ignores."

4. What's the difference between severity and priority?

Why they ask: A fast check on quality judgment. Confusing the two is the mark of someone who can't help a team triage, which is half the job.

"Severity is how bad the defect is technically — its impact on the system if it occurs. Priority is how urgently it needs to be fixed from a business standpoint. They're independent axes. A crash on a core flow is high severity, high priority. A misspelled word in the company logo on the homepage is low severity but high priority — trivial technically, but embarrassing enough to fix now. A data-corruption bug that only triggers on a deprecated path used by two internal users is high severity, low priority. And a cosmetic misalignment on a rarely seen settings page is low on both. I always set them separately in a bug report, because collapsing them into one number is exactly what makes triage meetings go sideways."

5. A test passes locally but fails intermittently in CI. How do you handle the flaky test?

Why they ask: Flaky tests are the daily reality of any automation suite. They want to see you diagnose root cause, not slap a retry on it and move on.

"First, I don't just add a retry — a retried flaky test still hides a real signal. I treat flakiness as a defect in the test or the system. I reproduce by running it in a loop and check the usual culprits: timing and race conditions where the test asserts before the app is ready, hard-coded sleeps instead of waiting on a condition, shared or unclean state between tests, test-order dependency, and time-zone or environment differences between local and CI. The fix is almost always to replace fixed sleeps with explicit waits on the actual condition, isolate test data so tests don't collide, and make each test set up and tear down its own state. If I can't fix it immediately, I quarantine it out of the gating suite and file a ticket — but quarantine is a holding pen with a deadline, not a graveyard. And sometimes the flakiness is exposing a genuine race condition in the product, which is the most valuable bug the test will ever find."

6. How do you test a REST API?

Why they ask: Modern QA tests below the UI. They want to know you can validate contracts, status codes, and edge cases with tools or code rather than only clicking through a front end.

"I test an API independently of any UI, because that's where the contract lives. For each endpoint I verify the happy path — correct status code (200, 201), response schema, and body — then the error paths: 400 for bad input, 401/403 for auth and permission boundaries, 404 for missing resources, 422 for validation. I check data validation at the boundaries: required fields, type mismatches, max lengths, and injection payloads. I test idempotency for PUT and DELETE, pagination and filtering on collection endpoints, and auth — that a token from one user can't read another user's data. I'll automate these with Postman/Newman or a code-based approach like REST Assured or pytest with requests, and wire them into CI. I also do contract testing between services so a backend change that breaks the schema fails fast, before it reaches a slow end-to-end test."

7. How do you write a bug report that actually gets fixed?

Why they ask: A bug nobody can reproduce is a bug nobody fixes. This tests communication and bug advocacy — turning a finding into action.

"A good report makes the developer's life easy and removes every reason to send it back. I lead with a clear, specific title capturing the symptom, then exact reproduction steps anyone can follow, expected vs. actual, and the environment — build, browser/device, OS, and the data or account state. I attach evidence: a screenshot, a screen recording for anything timing-related, and the relevant logs, console errors, or network responses. I set severity and priority separately, because a typo is low severity even if visible, while silent data corruption is critical even if rare. And I practice bug advocacy — I frame the impact in terms of the user and the business, not just 'this looks wrong,' so the team prioritizes correctly. The test of a good report is that a developer can reproduce it in one read without pinging me back."

8. What's your regression strategy, and where does QA fit in CI/CD?

Why they ask: They need someone who keeps a fast-moving pipeline safe. Re-running everything by hand doesn't scale, so they want a smart, automated approach.

"Regression testing confirms that new changes didn't break existing behavior. I don't re-run everything by hand every release — I maintain an automated regression suite covering the critical paths and high-risk areas, and I use risk-based selection to add targeted coverage around whatever changed in a given release. In CI/CD, I shift testing left: fast unit and API tests run on every pull request and block the merge if they fail; a smoke suite of critical journeys runs on every deploy to staging; and the full regression and end-to-end suite runs nightly or pre-release so it never blocks fast feedback. I gate releases on the right layer — you don't want a thirty-minute end-to-end run on every commit. I also watch for test coverage and pass-rate trends over time so the suite stays meaningful instead of decaying into noise."

9. If a developer says "it works on my machine," and you've found a bug, what do you do?

Why they ask: A judgment-and-collaboration check disguised as a technical one. They want rigor in isolating the variable, not a standoff.

"'Works on my machine' usually means an environment difference, so I make the bug undeniable by isolating the variable. I confirm exact reproduction steps, capture the full environment — build version, browser/OS, feature flags, config, and the specific data — and grab logs, console output, and network traces. Then I sit with the developer and reproduce it together, or hand them a recording plus a minimal repro so the gap between our setups becomes obvious. Often it's a difference in data, a stale cache, a config value, or a flag that's on in staging and off locally. I treat it as a shared problem to solve, not a 'you're wrong' moment — the goal is the same on both sides, which is shipping something that works for the user, not just on one laptop."

10. Tell me about the most important bug you ever caught.

Why they ask: Quality is the whole job. They want proof you find bugs that matter — and understand why they mattered to the business.

S/T: "Before a release, I was testing a new discount-code feature and needed to confirm it was safe to ship. A: Beyond the happy path, I tested concurrency — what happens when two users redeem a single-use code at the same instant. The code had a race condition: under simultaneous requests it could be redeemed twice, which on a high-value promotion would have meant uncapped, stackable discounts. I reproduced it reliably with a parallel-request script, filed a high-severity report with the repro, and flagged the revenue exposure rather than just logging a defect. R: The team added a database-level lock on redemption, we verified the fix under load, and we shipped on schedule. The bug never reached production, where it would have been a direct, unbounded revenue loss the moment the promo went viral."

11. Tell me about a time you advocated against shipping something on time.

Why they ask: They want to see you hold the quality line responsibly — quantifying risk and offering options, not just blocking the train.

S/T: "During a release-readiness review, regression testing surfaced a currency-rounding bug that silently under-charged a small subset of orders, and the team was under pressure to ship that day. A: I made the risk legible instead of saying 'it feels risky' — I showed how many order types hit the path, the dollar exposure per occurrence, and that it produced wrong financial data silently rather than failing loudly. I proposed two options: a one-day slip to fix it, or shipping with that one payment path feature-flagged off, so leadership had a real decision rather than a veto. R: We flagged the path off, shipped the rest on time, and patched the bug the next day. We hit the date on everything safe and protected the revenue — and the PM said the framing of options made it an easy call instead of a fight."

12. Describe a disagreement with a developer about whether something was a bug.

Why they ask: QA lives at a natural friction point. They want someone who resolves it with evidence and the spec, not ego.

S/T: "I filed a defect on a form that accepted a future date in a 'date of birth' field; the developer pushed back that it wasn't in the requirements. A: Rather than argue it as opinion, I went to the source — the acceptance criteria were silent on it, so I reframed it around the user and the data, showing it let through obviously invalid records that would pollute downstream reporting. I pulled in the product owner to make the ruling instead of forcing my view, and I proposed a concrete fix: validate the field against today's date with a clear error. R: The PO agreed it was a real defect, we added the validation and an acceptance criterion so the ambiguity wouldn't recur, and the developer and I ended up tightening the rest of the form's validation together. Disagreeing about the spec turned into improving it."

13. Tell me about a time you improved a testing process or built automation from scratch.

Why they ask: Manual-only QA doesn't scale. They want initiative and an eye for where time and risk hide — the SDET mindset.

S/T: "Our regression pass was fully manual — roughly two days of click-through every release, which slowed shipping and missed things when people rushed. A: I built an automated suite for the critical user journeys using Playwright, started at the top of the risk list, and used the page-object model so the tests stayed maintainable as the UI changed. I wired it into the CI pipeline to run on every deploy to staging and added clear failure reporting so a red build pointed to the exact step. I documented it so the team could extend it without me. R: The regression cycle dropped from about two days to under thirty minutes, we caught several regressions before release that the manual pass had been missing, and it freed the team to spend manual effort on exploratory testing where humans actually add value."

14. Tell me about a bug that escaped to production. What did you do?

Why they ask: The accountability question. They want ownership and a systemic fix — not blame, and not pretending it never happens.

S/T: "A defect slipped past us into production where a specific timezone caused a scheduling feature to display the wrong day for some users. A: I didn't hunt for who to blame. I helped reproduce and confirm it fast so engineering could hotfix, then I led a blameless retro to find why our testing missed it. The root cause was that our test data and CI all ran in one timezone, so the class of bug was invisible to us. I added timezone-boundary cases to the regression suite, parameterized the relevant tests to run across multiple timezones in CI, and added a checklist item for any date/time feature. R: The fix shipped within hours, and more importantly, we never shipped a timezone bug of that class again because the gap that let it through was closed, not just the single instance."

15. Why QA — and why this role specifically?

Why they ask: Fit and genuine interest. Plenty of people land in QA by accident; they want someone who chose it and will grow in it.

"I like that QA is where you get to think like an adversary on behalf of the user — I genuinely enjoy the puzzle of finding the one input or sequence that breaks an assumption everyone else made, and the satisfaction of a release going out clean because of work that's invisible when it goes right. I'm drawn to this role specifically because you're building automation into the pipeline and treating QA as engineering, not a manual gate at the end — that's exactly the SDET direction I want to grow in. I also saw you ship frequently, which means quality has to be fast and automated rather than a bottleneck, and that's the environment where I do my best work: shifting testing left and partnering with developers to prevent defects, not just catch them."