50 QA Interview Questions Hiring Managers Actually Ask in 2026
A QA interview in 2026 is no longer a vocabulary test. Hiring managers expect candidates to define the fundamentals in a sentence, then apply them under pressure — design a test strategy, decide what to run when the release window is two days, explain how they would QA a non-deterministic feature. This guide collects the fifty questions QA leads ask most often, with a strong answer for each.
Key takeaways
- The biggest knockout question of 2026 is test strategy design — KORE1's hiring debriefs report ten of eleven candidates freeze on it. Practise articulating one out loud.
- Automation fluency is now baseline. Playwright reached 45.1% adoption among QA pros in 2026 versus Selenium at 22.1% and Cypress at 14.4%.
- AI-feature QA is a real question category, not a buzzword filter. Expect to be asked how you would test something non-deterministic.
- Behavioural answers reward specifics — a number, a name, a concrete outcome.
- Fundamentals still come up early. QA vs QC, severity vs priority, smoke vs sanity — wobble on these and the interview ends before the real questions begin.
Category 1: QA fundamentals
1. What is quality assurance?
QA is the process discipline that prevents defects through standards, reviews, and feedback loops — rather than catching them after the fact. Testing is one activity inside QA, not a synonym. Interviewers listen for prevention vs detection drawn cleanly.
2. What is the difference between QA, QC, and testing?
QA is process-oriented and proactive — it shapes how software is built. QC is product-oriented and reactive — it inspects the finished work. Testing is a technique inside QC.
3. What is the difference between verification and validation?
Verification asks "are we building the product right?" — does it match the specification? Validation asks "are we building the right product?" — does it meet the user need? Verification is reviews and walkthroughs; validation is functional and UAT testing.
4. What is the difference between a bug, an error, and a defect?
An error is the human mistake. A defect is the flaw in the software the error produced. A bug is the informal term for a defect. In ISTQB and IEEE 1044 the distinctions matter; in conversation they collapse.
5. What is the difference between severity and priority?
Severity measures technical impact — a crash is high severity. Priority measures business urgency — a typo in the company name on the homepage might be low severity and the highest priority you have. QA sets severity, product sets priority.
6. What is the Software Testing Life Cycle?
The STLC sequences testing across six phases: requirement analysis, planning, test case design, environment setup, execution, and closure. Each has explicit entry and exit criteria. In agile teams the phases compress into a sprint rather than running linearly.
7. What is a Requirement Traceability Matrix?
An RTM maps every requirement to the test cases that verify it. Its job is to prove coverage and surface gaps. In regulated industries auditors ask for it directly.
8. What is shift-left testing?
Shift-left moves testing earlier — into requirements, design, and development. In practice: QA writing acceptance criteria during refinement, reviewing pull requests, integrating static analysis into pre-commit hooks. Capgemini's World Quality Report 2025-26 finds shift-left has moved from stated initiative to default expectation in mature engineering organisations.
9. What is exploratory testing?
Exploratory testing is simultaneous learning, test design, and execution. The tester probes the application with no pre-written script, using product knowledge to follow unexpected behaviour into the next test. It finds bugs no scripted suite would think to look for — and is the part of the job least exposed to AI.
10. What is the difference between black-box and white-box testing?
Black-box evaluates the software from the outside — inputs in, outputs verified, no implementation knowledge. White-box uses source code access to design tests around branches and code paths. Grey-box sits between: the tester knows some internals (schema, API contracts) but tests through the UI.
Category 2: Manual testing
11. What is a test plan and what does it contain?
A test plan scopes a testing effort: objectives, in-scope and out-of-scope features, entry/exit criteria, test types, environments, schedule, owners, and risks. In agile teams it is often a one-pager per release rather than a 40-page artefact. Weaker candidates forget the entry/exit criteria.
12. What is the difference between a test scenario and a test case?
A scenario is the one-liner — "verify user can log in with valid credentials". A case is the executable detail — preconditions, steps, test data, expected results, pass/fail criteria. Scenarios live in planning; cases in execution.
13. What are the main types of manual testing?
Smoke, sanity, regression, integration, system, UAT, usability, exploratory, and ad hoc. Smoke asks "is the build worth testing?" Regression asks "did the change break what worked?" UAT asks "does the business sign off?"
14. What is regression testing and when do you run it?
Regression testing verifies recent changes have not broken existing behaviour. It runs after every meaningful change. The art is scope: full suite on every commit is wasteful, too narrow a slice misses breakage. Most teams maintain a tagged subset for pull-request runs and a wider suite nightly or pre-release.
15. What is equivalence partitioning?
Equivalence partitioning divides input data into groups the software handles the same way, then tests one value from each. A field accepting ages 18–65 has at least three partitions — under 18, 18–65, over 65 — and you test one representative value from each, not every integer.
16. What is boundary value analysis?
BVA tests the edges of input ranges, where defects cluster. For a field accepting 1–100, you test 0, 1, 2, 99, 100, and 101. Off-by-one errors are among the most common production bugs — BVA is the cheapest technique that catches them.
17. What is the difference between smoke and sanity testing?
Smoke is broad and shallow — does the build start, can a user log in, do core flows respond? Sanity is narrow and deep — was this specific bug actually fixed? Smoke gates entry to fuller testing; sanity confirms a targeted change before regression continues.
18. How do you write an effective bug report?
A complete report has a clear title, environment (OS, browser, version, build), exact reproduction steps, expected vs actual behaviour, severity, priority, and evidence — annotated screenshot, screen recording, console output, network trace. The assigned developer should reproduce the bug from the report alone. See the bug report template.
19. What is risk-based testing?
Risk-based testing prioritises test effort by probability and impact of failure. Recently changed code, business-critical flows, and modules with a history of defects get the most coverage; stable, low-traffic areas get less. It is the honest answer to "we have an eight-hour regression suite and a two-hour release window."
20. What is ad hoc testing and how is it different from exploratory testing?
Ad hoc is unstructured and undocumented. Exploratory is also unscripted but operates inside a charter — a defined mission, time-box, and area of focus. Ad hoc is a coffee break; exploratory is a discipline.
Category 3: Automation testing
21. When should you automate a test, and when should you not?
Automate stable, repetitive checks with predictable outcomes — regression, data-driven scenarios, smoke suites, API contracts, performance baselines. Do not automate frequently changing UI screens, one-time validations, or anything that depends on subjective judgment. If maintenance will cost more than running it manually for a year, do not automate.
22. What is the Page Object Model and why use it?
POM is a pattern where each page or component gets its own class encapsulating locators and actions. Tests interact with the class, not the DOM. When the UI changes, you update one class — without POM, a button rename can break thirty tests.
23. What is the difference between Selenium, Cypress, and Playwright?
Selenium drives browsers via WebDriver, supports the widest range of languages, and is the default for enterprise and legacy stacks — 22.1% adoption among QA pros in 2026. Cypress runs inside the browser, JavaScript only, with single-tab/single-origin constraints — 14.4%. Playwright drives browsers out-of-process, supports JavaScript, Python, Java, and C#, has native parallel execution and cross-origin support, and reached 45.1% adoption and 91% developer satisfaction in State of JS 2025. See Selenium vs Playwright vs Cypress 2026 for the full breakdown.
24. What is Selenium Grid?
Selenium Grid runs tests in parallel across machines, browsers, and operating systems. A Hub routes commands; Nodes execute. A 400-test suite that takes 90 minutes on one machine can finish in eight on a grid of twelve.
25. What is the test automation pyramid?
The pyramid (Mike Cohn) recommends a wide base of fast unit tests, a narrower middle of integration and API tests, and a small tip of end-to-end UI tests. Some teams prefer a "trophy" or "honeycomb" shape that fattens the integration layer, but UI tests staying the minority still holds.
26. How do you handle a flaky test?
Quarantine first, fix second. A flaky test in the main pipeline trains the team to ignore failures. Tag it, route to a separate queue, investigate. Common causes: implicit timing (replace sleep() with explicit waits), test pollution, dynamic locators (use data-testid or accessible roles), environment instability. Track flakiness per test — the goal is a bounded rate, not zero.
27. What is a data-driven framework?
A data-driven framework separates test logic from test data. The same test runs against many inputs read from a spreadsheet, CSV, JSON, or database. You cover a hundred input combinations with one script; the 101st only changes the data file.
28. What is API testing and which tools do you use?
API testing exercises endpoints directly: status codes, payloads, headers, auth, error handling, performance. Faster, more stable, and more diagnostic than UI testing — when a test fails, you know which endpoint. Postman and Bruno cover manual exploration and lightweight automation. RestAssured (Java) and Playwright's request fixture (JS) are the code-based options. k6 and JMeter handle load.
29. What are self-healing locators?
Self-healing locators use heuristics (sometimes AI/ML, sometimes deterministic fallbacks) to recover when an element's primary locator breaks. Playwright's resilient locators (role, text, label) reduce the problem; Mabl, Testim, and Healenium tackle it explicitly. They buy time between maintenance cycles, not infinite test life.
30. How do you integrate automated tests into CI/CD?
Tests run inside the pipeline — GitHub Actions, GitLab CI, Jenkins, Azure DevOps — triggered by specific events. The typical split: fast unit and API tests on every pull request, smoke suite on merge to main, full regression nightly or pre-release, smoke pack post-deploy. Failing tests block merges per the team's quality-gate policy.
Category 4: AI and modern QA
31. How would you QA an AI feature whose output is non-deterministic?
Split the surface. UI, error handling, validation, latency, request logging — deterministic, test with standard methods. The model output is non-deterministic: define quality bands instead of exact assertions, run prompts many times to measure variance, build evaluation sets with known acceptable outputs (Promptfoo, Braintrust, OpenAI evals), and assert against statistical thresholds — "90% of responses score above 0.8 on the grading rubric." Test the failure modes AI features actually break on: prompt injection, off-topic inputs, refusal-to-answer, hallucinated facts, leaked system prompts.
32. What do you test in an LLM-powered feature beyond functional correctness?
Hallucinations, prompt injection, data leakage, bias across protected attributes, latency under load, cost per query, behaviour when the model API is degraded. The non-functional list is longer than for a traditional feature — and where most AI products fail in production.
33. How does AI change the QA role itself?
AI absorbs the scripted middle of the job — regression scripts, locator healing, flake triage, test data. Capgemini's World Quality Report 2025-26 finds 10% of teams using AI to generate up to 75% of their automation scripts. What AI does not do well: exploratory testing, risk judgment, translating "the cart API returns 400 on a specific cookie state" into business risk. The role is shifting toward orchestration and judgment — more about the quality advocate than the script-typer.
34. What is agentic QA?
An AI agent given a goal ("verify the checkout flow works on Safari iOS") explores the application, generates and runs its own test steps, and reports back. Commercial tools (Mabl, Testim, Functionize, agentic add-ons for Playwright and Cypress) are improving fast. Useful for coverage breadth; not a substitute for engineering judgment on what to test.
35. What is visual regression testing and which tools do you use?
Visual regression testing compares screenshots against a baseline and flags pixel-level differences. AI-diffing tools (Percy, Applitools, Chromatic, Playwright's toHaveScreenshot) ignore noise like font anti-aliasing. It catches bugs no functional test does — alignment regressions, font swaps, broken responsive breakpoints. See the visual regression tools roundup.
Category 5: Bug reporting and triage
36. What does a great bug report contain?
Bug ID, title summarising the issue in eight words or fewer, environment (OS, browser, version, build, user role), preconditions, numbered reproduction steps, expected and actual results, severity, priority, and evidence — annotated screenshot, recording, console, network log, request/response payloads. A developer who has never seen the feature should reproduce it from the report alone.
37. What is your bug-triage process?
A recurring meeting — daily for high-velocity teams, twice a week otherwise — where QA, engineering, and product review new bugs. For each: confirm reproducibility, set severity and priority, assign owner, target a release. The first ten minutes determine whether a bug ships next release or sits for a quarter, and the answer hinges on how well the report was written.
38. How do you decide a bug's severity?
By technical impact and breadth of users affected. Critical: data loss, security breach, total outage. High: major functionality broken with no workaround. Medium: broken with workaround, or affecting a minority. Low: cosmetic, edge case. The scale should be documented and consistently applied — different testers calling the same bug "high" or "medium" is a process smell.
39. How do you handle a bug a developer cannot reproduce?
Share a screen recording with the network and console panels open, capture browser/OS/extension state, test under a fresh profile to rule out local state. If intermittent, document frequency, timing, and pattern. Pair with the developer for a live session — most "cannot reproduce" cases collapse in fifteen minutes of paired investigation.
40. How do you handle a disagreement with a developer about whether something is a bug?
Anchor on the requirement or acceptance criterion as shared ground truth. Present evidence — steps, screenshots, spec reference — not opinion. If the spec is ambiguous, escalate to product for a ruling. Strong QA engineers escalate ambiguity early; weak ones argue in JIRA for three days.
Category 6: Agile, CI/CD, and modern process
41. How do you work inside an agile team?
Sprint planning to refine acceptance criteria, standups with a quality lens, pick up stories and test them inside the same sprint they are built, demo at review, raise process issues at retro. The regression suite grows incrementally. The anti-pattern is "QA sprint" — a separate testing sprint after development — which defeats most of agile's value.
42. What is a definition of done from a QA perspective?
A story is done when the code is merged, automated tests (unit, integration, and where appropriate end-to-end) are passing, acceptance criteria are verified, accessibility checks pass, no medium-or-higher bugs remain, and the feature is on staging behind a flag if needed. If "tests written and passing" is not on the DoD, the team accumulates test debt fast.
43. Describe an ideal quality gate in a CI/CD pipeline.
On pull request: linting, unit tests, type checks, fast API tests, Axe accessibility, CodeQL security scan. On merge to main: full unit and integration suites, smoke end-to-end pack, visual regression. Pre-deploy: full regression and a performance baseline. Post-deploy: production smoke and observability checks. Each gate has an explicit failure policy — block, warn, or quarantine.
44. How do you prioritise test cases when time is limited?
Cover recently changed code first — that is where defects concentrate. Then core revenue and user-experience paths. Then high-historical-defect areas. Deprioritise stable, low-traffic features. Communicate the cut-list to product and engineering so go/no-go is informed.
45. What is accessibility testing and where does it fit?
Accessibility testing verifies the application is usable by people with disabilities, against WCAG 2.2. The European Accessibility Act enforcement that began June 28, 2025 made this a budget line for any company shipping in the EU. The modern practice is accessibility-as-CI — Axe-core or Pa11y on every PR, builds failing on violations — plus manual screen-reader testing on critical flows. See the accessibility testing tools breakdown.
Category 7: Behavioural and scenario
46. Tell me about a critical bug you found late in a release cycle.
Use STAR: situation (release context, timeline pressure), task (what you needed to verify), action (escalation, reproduction, coordination), result (what shipped, what was deferred, the user impact). Strong answers include a number — "this affected 8% of users on Safari iOS" — and a lesson that changed your team's process afterward.
47. A critical production bug hits the checkout flow. Walk me through your response.
Confirm and reproduce, then communicate. Open an incident channel, post reproduction steps and current understanding, page on-call. Help gather logs, network traces, and affected user IDs. Verify the hotfix in staging before it ships. After the fire is out, drive the postmortem: root cause, the test that should have caught it, the regression rule added.
48. You inherit a feature with incomplete requirements. What do you do?
Document the gaps, then ask. Reach out to product, engineering lead, and the original designer. Make assumptions explicit in writing — "I will treat unauthenticated checkout as out-of-scope unless told otherwise" — and get them confirmed. Start with the validations you can infer. Flag the risks where missing information could ship a defect. Do not write test cases against guesses.
49. You have a large regression suite and a two-day release window. How do you decide what runs?
Map changed code to affected test areas, run that subset first. Layer in the always-run critical-path suite — auth, payment, core data write paths. Deprioritise stable areas untouched in this release. Parallelise where you can — Selenium Grid, Playwright sharding, CI parallel jobs. Communicate the cut-list and residual risk to product and engineering before the deploy gate.
50. How do you keep your skills current?
Specifics, not generalities. Following the State of JS and World Quality Report releases each year. A personal Playwright or Cypress repo to try new features. Reading a small set of QA and engineering blogs — Ministry of Testing, the Playwright release notes, Kent C. Dodds. ISTQB CT-AI v2.0 if it earns its fee for your market.
FAQ
How long should my answers be?
Two to four sentences for definitional questions, two to four minutes for scenario and behavioural questions. The most common failure mode is over-explaining a definition and under-explaining a story.
Should I use the STAR method for every behavioural question?
Yes for "tell me about a time" questions. For shorter ones, a compressed answer with one named example is enough. The structure is a scaffold — do not narrate "the situation was…" out loud.
How much automation experience is expected for a mid-level QA role in 2026?
You should write, run, and debug end-to-end tests in at least one framework (Playwright or Cypress for web; Appium or Espresso for mobile), integrate them into CI, and explain trade-offs. Reading and modifying someone else's test code matters more than designing a framework from scratch.
Are coding rounds common in QA interviews now?
Increasingly yes for SDET and senior QA roles. Expect an easy-to-medium LeetCode-style problem and a practical task like "write a Playwright test for this page." Pure manual roles often skip the coding round.
What is the single most-asked question in 2026?
"Design a test strategy for [X]" — where X is a payments API, a checkout flow, an AI chatbot, or a multi-tenant SaaS feature. Practise articulating one strategy out loud, end to end, before any senior interview.
Walk in with the bug-reporting workflow already sorted
Many of the answers above lean on the same thing: bug reports specific enough that a developer can reproduce without messaging back. Crosscheck is a free Chrome extension that captures screenshot, recording, console log, and network trace in one action and sends a complete report to Jira, Linear, ClickUp, Slack, or GitHub.
