Preparing for a QA interview can be challenging, especially with the wide variety of QA testing questions that could be asked. Here’s a comprehensive list of the top 30 QA interview questions and answers for 2026, designed to cover both manual testing, automation testing, and general QA processes.

QA Interview Questions and Answers for 2026

Top 40 QA Interview Questions and Answers for 2026

Preparing for a QA interview means covering a wide range: testing fundamentals, automation decisions, behavioral questions, and strategic thinking about quality. This guide covers 40 questions across all of those areas — including questions that typically separate strong candidates from average ones.

Each question includes the answer and a note on what interviewers are actually evaluating. Read both. The difference between a passable answer and a strong one is usually less about the facts and more about demonstrating how you think.

Before the interview: three things that matter more than memorizing answers

1. Prepare one real example for each major area: a bug you caught that mattered, a test you designed from scratch, a time you pushed back on a release. Real stories beat textbook answers every time.
2. Know your resume. Interviewers will probe whatever you list. If you wrote "Cypress" on your CV, expect follow-up questions on Cypress specifics.
3. Ask one sharp question at the end. "What does your regression suite currently cover?" or "How do you handle test ownership when developers ship fast?" signals genuine understanding of the craft.

Difficulty Labels

• Foundational — expected from any QA candidate regardless of level
• Mid-level — expected from candidates with 2+ years of QA experience
• Senior / Leadership — expected from QA leads, managers, or senior engineers

Section 1: QA Fundamentals

1. What is the difference between QA, QC, and testing?

Foundational

QA (Quality Assurance) is process-focused and preventive — it defines how work should be done to avoid defects from the start. QC (Quality Control) is product-focused and reactive — it verifies that the output meets requirements. Testing is a subset of QC: the act of executing a system to find defects. In short: QA prevents, QC detects, testing executes.

What interviewers are really testing: Whether the candidate understands quality as a process, not just a testing activity. Confusing QA with testing is one of the most common gaps at junior level.

2. What is a bug? What is the difference between severity and priority?

Foundational

A bug is any deviation between actual and expected behavior of a system. Severity measures the impact of the bug on the application — a crash is high severity; a misaligned pixel is low. Priority measures how urgently it needs to be fixed relative to business needs — a cosmetic bug on the homepage before a major campaign launch might be high priority despite low severity. The two are independent: a typo on a checkout button could be low severity but high priority.

What interviewers are really testing: Whether the candidate can separate technical impact from business impact. Interviewers use this to probe if you can communicate with non-technical stakeholders.

3. What is the difference between verification and validation?

Foundational

Verification asks: are we building the product right? It checks that the product conforms to its specifications. Validation asks: are we building the right product? It checks that the product meets the actual needs of users. Verification is typically done through reviews, walkthroughs, and inspections. Validation is done through testing against real user requirements.

What interviewers are really testing: Whether the candidate understands that conforming to a spec and meeting user needs are different problems. Strong answers include a concrete example.

4. What is the difference between black-box and white-box testing?

Foundational

Black-box testing treats the system as opaque — the tester focuses on inputs and outputs without knowledge of internal code. It tests behavior from the user's perspective. White-box testing uses knowledge of the internal structure to design tests — the tester can see the code and test specific paths, branches, or conditions. Most QA engineers work primarily in black-box, while developers doing unit testing typically work in white-box.

What interviewers are really testing: Whether the candidate can clearly explain both modes and knows when each applies. Confusion between the two is a common gap.

5. What is the Software Testing Life Cycle (STLC)?

Foundational

The STLC is the sequence of activities performed during a testing project: Requirements Analysis, Test Planning, Test Case Design, Test Environment Setup, Test Execution, and Test Closure. Each phase has defined entry and exit criteria. Understanding the STLC matters because testing isn't just execution — planning, designing cases, and closing out findings are equally important.

What interviewers are really testing: Whether the candidate sees testing as a lifecycle activity rather than just running tests. Missing the planning or closure phases suggests gaps in process maturity.

6. What is regression testing?

Foundational

Regression testing verifies that new changes haven't broken existing functionality. It's typically run after every code change, deploy, or feature release. A regression suite should cover the critical paths most likely to break — login, core user flows, payment, and key integrations. The decision of what to include in regression is as important as running it: a suite that tests everything is too slow to be useful; a suite that tests too little misses real regressions.

What interviewers are really testing: Whether the candidate thinks about regression strategically — what to include, when to run, and how to keep it maintainable — not just as "running all the tests".

7. What is the difference between smoke testing and sanity testing?

Foundational

Smoke testing is a shallow, wide check — it verifies that the build is stable enough to proceed with further testing. If the app doesn't launch or core navigation is broken, there's no point running the full suite. Sanity testing is narrower and deeper — it verifies that a specific fix or change works correctly before wider testing resumes. Smoke tests the build; sanity tests the fix.

What interviewers are really testing: Whether the candidate can distinguish these without confusing them. Many candidates conflate the two.

8. What is exploratory testing, and when would you choose it over scripted testing?

Mid-level

Exploratory testing is simultaneous learning, test design, and test execution — the tester uses domain knowledge and intuition to investigate the system without predefined test cases. It's most valuable when: the application is new and requirements are unclear; you're trying to find edge cases that scripted tests would miss; or you need fast coverage without the overhead of writing formal test cases. Scripted testing is better when you need repeatability, compliance evidence, or automation. The best QA strategies use both.

What interviewers are really testing: Whether the candidate treats exploratory testing as a disciplined approach, not just "clicking around". Strong candidates mention charters, time-boxing, and note-taking during sessions.

9. What is User Acceptance Testing (UAT)?

Foundational

UAT is the final testing phase where actual users or business stakeholders validate the system against real-world requirements and use cases before go-live. It answers the question: does this software do what the business actually needs? QA teams typically support UAT by setting up environments, providing test scenarios, and tracking defects — but the testing is performed by the end users, not the QA team.

What interviewers are really testing: Whether the candidate understands that UAT is a business activity, not a QA activity. Confusing the two signals a gap in understanding how testing fits into delivery.

Section 2: Test Design and Process

10. What makes a good test case?

Foundational

A good test case has: a clear, single objective; unambiguous preconditions; specific inputs and expected results; independence from other test cases; and a pass/fail determination that requires no judgment. It should be maintainable — readable by someone who didn't write it — and traceable to a requirement. A test case that requires the tester to guess whether it passed is not a good test case.

What interviewers are really testing: Whether the candidate thinks about maintainability and traceability, not just coverage. Lists of features are less impressive than a concrete answer with criteria.

11. What is a Test Plan? What should it include?

Foundational

A test plan is the document that defines the scope, approach, resources, and schedule for a testing effort. It should include: objectives and scope; features to be tested and excluded; test approach and types; entry and exit criteria; resource and environment requirements; risks and mitigation; and the schedule. The test plan is the agreement between QA and the project team on what "done" looks like from a testing perspective.

What interviewers are really testing: Whether the candidate understands the test plan as a communication tool, not just a checklist. Strong candidates mention entry/exit criteria and risk coverage.

12. What is a Traceability Matrix and why does it matter?

Mid-level

A Requirements Traceability Matrix (RTM) maps requirements to test cases, ensuring every requirement has coverage and every test case has a reason to exist. It has three forms: forward traceability (requirements to tests), backward traceability (tests to requirements), and bidirectional. It matters because it prevents both gaps (untested requirements) and waste (tests with no corresponding requirement). It's also essential for compliance-driven projects.

What interviewers are really testing: Whether the candidate understands test coverage as a measurable, traceable concept rather than a feeling.

13. What is data-driven testing?

Mid-level

Data-driven testing separates test logic from test data — the same test script runs multiple times with different input values from an external source (spreadsheet, database, CSV). It's useful when a function needs to behave correctly across many input combinations: login with valid/invalid credentials, form validation, pricing calculations. The test script stays constant; the data varies. This reduces script duplication and makes adding new test cases as simple as adding a row to a data file.

What interviewers are really testing: Whether the candidate has used this in practice. Bonus points for mentioning parameterized tests in frameworks like Pytest, JUnit, or Cypress.

14. What is the difference between a Traceability Matrix and a Test Coverage Matrix?

Mid-level

A Traceability Matrix maps requirements to test cases — it answers whether all requirements are covered. A Test Coverage Matrix goes further, showing which test cases map to which test conditions (boundary values, equivalence classes, risk levels). Together they let you answer two different questions: "Are we testing everything we should?" (traceability) and "Are we testing each thing thoroughly enough?" (coverage).

What interviewers are really testing: Whether the candidate can distinguish between coverage breadth and coverage depth.

15. What is bug leakage vs. bug release?

Mid-level

Bug leakage is when a defect that existed during testing is only discovered by end users — it "leaked" past the QA process. Bug release is intentional: the team knowingly ships with a known bug because its severity or priority doesn't justify delaying release. Bug leakage is a quality failure; bug release is a business decision. A mature QA process minimizes leakage and documents releases with clear severity rationale in release notes.

What interviewers are really testing: Whether the candidate understands that not every bug in production is a QA failure — and can distinguish between process failures and intentional trade-offs.

16. How do you decide what NOT to test?

Senior / Leadership

This is more important than deciding what to test. Criteria for deprioritizing: low-risk areas with no recent changes; functionality covered by unit tests at a lower level; out-of-scope features (documented exclusions); code paths with no realistic user journey; and edge cases where the cost of finding a bug exceeds the cost of the bug itself. Good QA is about risk-based prioritization — applying the most testing effort where failure has the highest business impact.

What interviewers are really testing: Strategic thinking. Anyone can decide what to test. Deciding what not to test requires understanding risk, business impact, and resource constraints. This is a senior-level differentiator.

Section 3: Automation

17. What should be included in an automation test plan?

Mid-level

An automation test plan should cover: the scope of automation (what to automate and explicitly what not to); tool and framework selection rationale; test data strategy; environment and infrastructure requirements; ownership model (who maintains the suite); integration with CI/CD; reporting approach; and success metrics. Without an ownership model, automation suites are routinely abandoned within two to three sprints — someone specific needs to be accountable for keeping tests green.

What interviewers are really testing: Whether the candidate includes ownership and maintenance planning, not just tooling. Interviewers who've seen automation projects fail watch for this specifically.

18. What is the difference between Assert and Verify in automation testing?

Mid-level

Assert is a hard stop: if the assertion fails, the test immediately stops execution. Verify is a soft check: it logs the failure but the test continues running. Use Assert when a failure means the subsequent steps are meaningless (login failure means nothing downstream can run). Use Verify when you want to collect multiple failures in one run to understand the full scope of what's broken.

What interviewers are really testing: Whether the candidate makes deliberate choices about failure handling rather than using one approach everywhere.

19. When should you automate a test, and when should you keep it manual?

Mid-level

Automate when: the test is executed frequently (regression, smoke); the test is stable and unlikely to change with every sprint; the test is time-consuming to run manually; the test requires data-driven execution across many inputs. Keep manual when: the test is exploratory or involves human judgment; the feature is new and likely to change before stabilizing; the automation cost exceeds the testing frequency benefit; or the test requires subjective evaluation (visual design, UX flow).

What interviewers are really testing: The ability to make cost-benefit decisions about automation rather than treating it as an end goal. Interviewers who've managed automation debt watch for candidates who automate everything.

20. What is the difference between a test framework and a testing tool?

Mid-level

A testing tool is a specific application that helps you accomplish a task — Selenium drives a browser, JMeter generates load, Postman tests APIs. A test framework is a structured set of guidelines and reusable components that organizes how tests are written, executed, and reported — Cypress, Playwright, and TestNG are frameworks. Most practical test suites use both: a framework to organize tests and tools for specific capabilities (like screenshot diffing or network mocking).

What interviewers are really testing: Whether the candidate thinks architecturally about their test infrastructure rather than just listing tools they've used.

21. What is CI/CD and how does testing fit into it?

Mid-level

CI/CD is Continuous Integration and Continuous Delivery — the practice of automatically building, testing, and deploying code changes. Testing fits at multiple gates: unit tests run on every commit; smoke and integration tests run on every build; regression runs before deployment to staging; and full E2E runs before production. The goal is catching defects as early as possible, when they're cheapest to fix. A build that can't be automatically tested is a build that will ship bugs.

What interviewers are really testing: Whether the candidate sees testing as part of the delivery pipeline, not a separate phase that happens after development.

22. What are the most common causes of flaky tests, and how do you fix them?

Mid-level

Flaky tests are tests that pass and fail intermittently without code changes. Common causes: timing issues (hardcoded waits instead of dynamic waits); test interdependence (tests that rely on state from a previous test); environment instability (shared test data, network latency); and brittle selectors (CSS classes that change frequently). Fixes: replace static waits with event-based waits; ensure each test sets up and tears down its own state; use stable selectors like data-testid attributes; and isolate test environments.

What interviewers are really testing: Practical debugging experience. Candidates who've never dealt with flaky tests at scale will give textbook answers. Listen for real examples.

Section 4: Tools and Technical

23. What testing tools have you used and why did you choose them?

Mid-level

Strong answers name specific tools, explain the problem each one solved, and acknowledge trade-offs. Example: "We used Cypress for E2E because the team was JavaScript-based and the local debugging experience was faster than Selenium. We used BugBug for regression coverage because non-developer QA team members could record and maintain tests without code ownership. We considered Playwright when we needed Safari coverage but ultimately used BrowserStack for cross-browser execution." Weaker answers list tools without context.

What interviewers are really testing: Decision-making maturity. The tool matters less than whether the candidate can explain why one tool was chosen over alternatives.

24. What metrics do you use to measure test coverage and quality?

Mid-level

Useful metrics: requirements coverage (percentage of requirements with corresponding test cases); defect detection rate (bugs found in testing vs. bugs found in production); defect leakage rate; test pass rate over time; mean time to detect (MTTD); and automation coverage percentage. The most important metric varies by team — for a team worried about production bugs, defect leakage matters most; for a team worried about regression maintenance, flakiness rate matters most. There is no single "most important" metric — the right answer depends on the team's current biggest risk.

What interviewers are really testing: Whether the candidate thinks about metrics as diagnostic tools tied to specific problems, rather than generic KPIs to report upward.

25. How would you approach testing a feature with no written requirements?

Mid-level

Start by reconstructing requirements: talk to the developer or product manager to understand intent, review any design mockups or user stories, and look at similar existing features for consistency. Then write your own test cases against what you've learned and get sign-off from the team before testing. Document your assumptions. Test for happy path first, then edge cases, then boundary conditions. Flag the lack of documentation as a process risk — bugs found without requirements are harder to classify as defects vs. design decisions.

What interviewers are really testing: Whether the candidate takes ownership of clarity rather than waiting for perfect documentation. Strong candidates mention the risk of undocumented decisions and how they mitigate it.

Section 5: Process, Collaboration, and Judgment

26. When should QA start in a project?

Mid-level

As early as possible — ideally at the requirements phase. Shift-left testing means involving QA in design reviews, requirement clarification, and acceptance criteria definition before a line of code is written. Bugs found in requirements cost a fraction of bugs found in production. QA's role isn't just to test the finished product — it's to build quality into the process from the beginning.

What interviewers are really testing: Whether the candidate thinks of QA as a gate at the end of development or as a continuous practice. Shift-left awareness is increasingly expected even at mid-level.

27. How do you handle a disagreement with a developer about whether something is a bug?

Mid-level

First, verify the facts: reproduce the issue consistently and document expected vs. actual behavior with evidence. Then check the requirements or acceptance criteria — if the behavior deviates from documented expectations, it's a defect by definition. If requirements are ambiguous, escalate to the product owner for a ruling rather than letting it become a QA vs. dev argument. Keep it factual, not personal. The goal is shared understanding of what "correct" means, not winning the argument.

What interviewers are really testing: Conflict resolution and professional judgment. Strong candidates emphasize using documentation and stakeholder escalation rather than relying on personal authority.

28. How do you prioritize your work when faced with multiple testing tasks?

Mid-level

Risk-based prioritization: focus first on the areas with the highest probability of failure and the highest business impact if they fail. Practical order: critical path functionality (login, checkout, core user flows); areas with recent code changes; features flagged as high-risk by developers; and new functionality before regression. Communicate your prioritization explicitly to stakeholders — if you're not going to test something before the release, that's a decision that needs to be visible.

What interviewers are really testing: Whether the candidate communicates priorities explicitly rather than silently triaging. Missing the communication piece is a common gap.

29. Should QA be responsible for resolving production issues?

Senior / Leadership

QA's responsibility in a production incident is to help diagnose and reproduce the issue, verify the fix, and update regression coverage to prevent recurrence — not to fix the code. The engineering team owns the fix; QA owns the quality signal around it. Post-incident, QA should lead a retrospective on how the bug escaped testing and implement a concrete process improvement. If the same class of bug keeps reaching production, that's a coverage or process problem that QA owns.

What interviewers are really testing: Ownership mindset. Strong candidates take responsibility for improving the process that allowed the bug through, without overstepping into engineering responsibilities.

30. What is the most important test metric, and why?

Senior / Leadership

There's no single correct answer — the right test metric depends on the team's current biggest risk. If the team ships too many production bugs, defect leakage rate is most important. If the regression suite is slow and breaking CI, flakiness rate matters most. If stakeholders don't trust the test results, pass/fail trend over time builds the most confidence. Strong QA leaders choose metrics that surface the specific problem they're trying to solve, not metrics that look good on a dashboard.

What interviewers are really testing: Strategic thinking about quality measurement. "Defect density" or "test coverage percentage" without context is a weaker answer than explaining which metric matters and why.

31. Describe a time when you missed a bug.

Mid-level

The answer interviewers are looking for is honest and shows learning. A weak answer deflects, minimizes, or can't produce a real example. A strong answer describes: what the bug was, why it escaped testing (missing coverage, wrong assumptions, unclear requirements), what the impact was, and what changed in the process as a result. Every experienced QA engineer has missed bugs. The question is whether you learn from them.

What interviewers are really testing: Honesty, self-awareness, and the ability to improve from failure. Candidates who claim they've never missed a bug, or can't recall a specific example, are either inexperienced or not being truthful.

32. What qualities do you look for in a QA leader?

Senior / Leadership

Strong QA leaders: communicate risk clearly to non-technical stakeholders; build quality into the process rather than bolting it on at the end; invest in automation infrastructure as a team asset; create psychological safety for raising quality concerns without blame; and treat their team's skills as something to develop, not just deploy. Technical depth matters, but communication and judgment matter more at the leadership level.

What interviewers are really testing: Self-awareness and leadership maturity. If a candidate is applying for a senior or lead role, this is partially asking them to describe their own leadership philosophy.

Section 6: Advanced and Behavioral

33. What is shift-left testing and how have you applied it?

Senior / Leadership

Shift-left testing means moving testing activities earlier in the development lifecycle — from a post-development gate to an ongoing process starting at requirements. In practice: QA reviews acceptance criteria before development starts, flags ambiguities, writes test cases during development (not after), and participates in design reviews. The result is fewer bugs reaching the test phase because ambiguities and design flaws are caught when they're cheapest to fix.

What interviewers are really testing: Whether the candidate has actually practiced this or just knows the term. Listen for concrete examples of catching issues at the requirements stage.

34. What is monkey testing?

Foundational

Monkey testing is a technique where random inputs are entered into a system without predefined test cases, to observe whether it crashes or behaves unexpectedly. It's useful for stress testing and finding edge cases that scripted testing would miss. Smart monkey testing uses testers who understand the system; dumb monkey testing uses fully random inputs. It's not a replacement for structured testing but can surface unexpected failure modes quickly.

What interviewers are really testing: Breadth of testing knowledge. This is a foundational concept; candidates who blank on it suggest gaps in testing vocabulary.

35. What is the difference between gorilla testing and monkey testing?

Foundational

Both use random or repeated inputs, but at different scopes. Gorilla testing repeatedly hammers a single module with random inputs to exhaustively test one component. Monkey testing applies random inputs across the entire system to test overall stability. Gorilla testing is typically used in unit testing; monkey testing is used in system testing.

What interviewers are really testing: Whether the candidate can distinguish related concepts clearly. This is a common trick question.

36. What is testware?

Foundational

Testware is all the artifacts created and used during the testing process: test plans, test cases, test scripts, test data, test environments, and test reports. It should be maintained under configuration management just like application code — testware that's out of date is as dangerous as no testware, because it gives false confidence about coverage.

What interviewers are really testing: Whether the candidate thinks of testing artifacts as assets to be managed, not disposable documents.

37. What is a good approach to exploratory testing?

Mid-level

Structured exploratory testing uses charters: a defined scope, a time box (typically 90 minutes), and a specific question to investigate ("How does the payment flow handle failed card transactions?"). During the session, take notes on everything you try and find — not just bugs. After the session, report: what you covered, what you found, and what areas still need investigation. Unstructured "clicking around" misses the discipline that makes exploratory testing valuable.

What interviewers are really testing: Whether the candidate applies structure to exploratory testing rather than treating it as unplanned ad-hoc testing.

38. How would you test a broken toaster?

Mid-level

This is a test design thinking question, not a technical one. A strong approach: define "working correctly" first (what should a functioning toaster do?); identify all observable behaviors (heating, timer, eject mechanism, safety shutoff); design test cases for each; consider boundary conditions (too low/too high heat, too long/short time); and include edge cases (power interruption, wet bread, foreign objects). The structure matters more than the specific answers.

What interviewers are really testing: Systematic thinking and test design instincts. The toaster doesn't matter. The approach does.

39. How do you ensure quality across a QA team, not just in your own work?

Senior / Leadership

Process-level quality: peer review of test cases before execution; shared ownership of the regression suite; post-release retrospectives to identify escapes; onboarding standards so new team members test consistently. Culture-level quality: creating safety for raising concerns without blame; treating bugs found in testing as success signals, not failures; and making quality a team metric, not a QA-only metric. Quality at the team level is a leadership problem, not a technical one.

What interviewers are really testing: Whether the candidate thinks about quality as a systemic, cultural challenge rather than an individual skill.

40. Can you tell us about yourself and your QA career so far?

Foundational

This is your chance to tell a coherent story, not recite your resume. Frame it around: what drew you to QA, what you've learned that shaped how you think about quality, and what you're focused on developing next. Interviewers are looking for directionality — evidence that you take your craft seriously and are moving somewhere intentionally, not drifting between jobs.

What interviewers are really testing: Honesty, self-awareness, and a sense of professional identity. Candidates who can't articulate why they're in QA often struggle to articulate why quality matters.

Best Practices for QA Interviews

1. Understand the role before you walk in

Read the job description carefully. QA roles vary enormously: some are manual-only, some require automation, some are embedded in engineering teams, some are standalone QA functions. Know what this specific role is testing, what stack they use, and what their current quality challenges are. Generic interview prep performs poorly against a specific job.

2. Prepare for tricky questions

The questions most candidates stumble on aren't the technical ones — they're the judgment questions: "When would you not automate a test?" "What do you do when a developer says a bug is by design?" "How do you decide what to test first when you don't have time to test everything?" These require real experience or carefully reasoned answers, not memorized definitions.

3. Highlight your QA experience with specifics

"I have experience with regression testing" is a weak answer. "I built and maintained a regression suite of 200 Cypress tests that ran on every PR and caught an average of two production-preventing issues per sprint" is a strong answer. Specifics signal real experience. Generalities signal reading about testing.

4. Ask questions that signal depth

The questions you ask at the end reveal as much as your answers. Strong questions: "What does your current regression coverage look like, and what's the biggest gap?" "How do you handle test ownership when a feature is shipped by multiple teams?" "What does a post-release retrospective look like here?" Weak questions: "What does a day in the life look like?" "Do you have good work-life balance?"

5. Prepare for behavioral and open-ended questions

Use the STAR format (Situation, Task, Action, Result) for behavioral questions. Have three to four real scenarios ready: a bug you caught that mattered, a time you disagreed with a developer or stakeholder, a process improvement you drove, and a time you missed something. Real stories beat constructed answers.

6. Showcase leadership and strategic thinking if applying for a senior role

Senior QA roles are evaluated on how you think about quality at a system level, not just how well you can write test cases. Be ready to discuss: how you'd set up a test strategy from scratch, how you'd prioritize automation investment, how you'd handle a team that's resistant to QA involvement early in development.

7. Be ready for technical tests

Many QA interviews include a practical component: write test cases for a login form, find the bugs in a live application, or write a simple automation script. Practice writing test cases for real scenarios before the interview. For automation roles, be ready to write basic code in whatever framework they use — review the job description for clues.

Happy (automated) testing!