Top 50 QA Engineer Interview Questions in 2026 (With Answers)

QA interviews test three things: fundamentals (can you discuss testing concepts clearly), technical skills (can you write and reason about test code), and judgment (can you make the right call when there's no obvious answer). The difference between a weak answer and a strong one is usually specificity, not technical depth: "I test everything thoroughly" fails; naming the risk-based criteria you actually use lands. This article covers the questions that actually appear in 2026 QA interviews, grouped by theme, with examples of both.

Testing fundamentals

Verification asks "are we building the product right?" by checking that the product matches specifications, designs, and requirements. Validation asks "are we building the right product?" by checking that the product actually solves the user's problem.

Weak answer: "Verification checks the code, validation checks the product." That's vague and confuses the two.

Strong answer: "Verification is internal: does the build match what was specified? Validation is external: does what we built actually satisfy the user's need? A product can pass verification (it matches the spec exactly) and fail validation (the spec was wrong about what users need)."

A test scenario is a high-level description of what to test, like "user can log in with valid credentials." A test case is the detailed step-by-step implementation: exact inputs, expected outputs, preconditions, postconditions.

Smoke testing is a shallow pass over the most critical functionality after a build. Does the app start, can users log in, does the main flow work? The goal is to decide quickly whether the build is worth testing further.

Regression testing verifies that existing functionality still works after new changes. It's broader and slower, because you're protecting what already worked from being broken by the new code.

Exploratory testing is simultaneous learning, test design, and test execution. Instead of following a predefined script, the tester explores the application, uses what they learn to guide where to look next, and adapts in real time. It's valuable for finding bugs that scripted tests don't cover because nobody thought to write a test case for them.

Black-box testing treats the system as a black box: you only know the inputs and expected outputs, not the internal implementation. White-box testing uses knowledge of the internal code, so you write tests based on code paths, branches, and logic.

Most QA engineers do black-box testing. White-box knowledge is useful for understanding what edge cases to test.

Test design

Risk-based testing: prioritize by likelihood of failure and impact of failure. A payment flow failing is high impact. A "hover tooltip" failing is low impact. A new feature has higher failure likelihood than a stable one that hasn't changed in months.

Weak answer: "I test everything thoroughly." Nobody tests everything. Time and build pipelines don't allow it.

Strong answer: "I start by understanding what changed and what's highest risk. New code gets more coverage than unchanged code. User-facing flows get more coverage than admin-only ones. I'd also talk to the developer to understand which edge cases they're most uncertain about."

Equivalence partitioning divides input space into groups where all values in the group behave the same way. Instead of testing every possible age, you test one value from each partition: under 18, 18–65, over 65.

Boundary value analysis tests the edges of those partitions (17, 18, 65, 66) because bugs cluster at boundaries. Code that handles "18–65" correctly often has an off-by-one error at exactly 18 or 65.

A strong answer includes: happy path (valid credentials → success), negative paths (wrong password, wrong username, empty fields, SQL injection attempt, very long inputs), boundary cases (minimum/maximum field length), and non-functional considerations (what if the submit button is clicked twice).

Title (concise, describes the problem), environment (browser, OS, app version), steps to reproduce (exact, numbered), expected result, actual result, severity/priority, and attachments (screenshot, video, network logs if relevant).

Automation

Automate when: the test is executed frequently (regression), the test data is consistent, the scenario is stable (won't change every sprint), and automation will save more time than it costs to build and maintain.

Don't automate when: the test requires human judgment (usability, visual design), the feature changes every sprint and tests would be rewritten constantly, or the test is run once and discarded (one-time data migration verification).

POM is a design pattern that wraps page interactions in a class. Instead of calling page.getByLabel('Username').fill(email) in every test, you create a LoginPage class with a login(email, password) method. Tests call the method; when the login form changes, you fix it in one place.

Unit tests at the base: many, fast, cheap to write and run. They test individual functions and components. Integration tests in the middle: fewer, test interactions between components. End-to-end tests at the top: fewest, slowest, test full user flows through the UI.

The pyramid shape matters. Inverting it (mostly E2E tests) gives you slow feedback, high maintenance cost, and flaky suites.

Flaky tests fail randomly on the same code. Common causes: timing issues (element not ready when the test acts on it), test pollution (state leaking between tests), parallel execution conflicts (two tests modifying the same data simultaneously).

Fix: for timing, use proper waits (wait for specific conditions, not fixed delays). For pollution, ensure each test sets up and cleans up its own state. For parallel conflicts, use unique test data per test or run conflicting tests serially.

Playwright-specific

Every Playwright action automatically waits for the target element to reach an "actionable" state before proceeding. For click(): the element must be visible, stable, and enabled. For fill(): the element must be editable. This waiting happens automatically with a configurable timeout (default 30 seconds).

Use storageState. Log in once in a setup file, save the browser's auth cookies and localStorage to a JSON file, then configure each test to load that state:

// Global setup: logs in and saves auth state
await page.context().storageState({ path: 'auth.json' });

// playwright.config.ts
use: {
  storageState: 'auth.json'
}

Each test starts already authenticated without going through the login UI.

Agile and process

QA should be involved from the beginning: reviewing requirements and acceptance criteria during planning, asking clarifying questions during refinement, writing or reviewing test cases before development starts. Testing shouldn't start only when development is "done." That creates a bottleneck at the end of the sprint.

Moving testing activities earlier in the development process. Instead of testing after code is complete, you review requirements for testability, write test cases during development, and run tests as part of the build process. The goal is finding defects earlier when they're cheaper to fix.

Bring evidence: exact reproduction steps, expected behavior from requirements or design, and the actual behavior. If it's genuinely ambiguous (not in the spec), escalate to the product owner who can decide whether the current behavior is acceptable. Don't argue. Document.

Assess the impact: who does it affect, how often does it happen, is there a workaround? Immediately escalate to the team lead and product owner with the impact assessment. Don't silently hold the release. The decision to release, delay, or hotfix belongs to the product owner, not QA. Your job is to surface the risk clearly and quickly.

Career and situational

QA Engineer focuses on test strategy, test execution, and quality process. SDET (Software Development Engineer in Test) is a more engineering-heavy role: building test frameworks, test infrastructure, CI/CD pipelines, and test tooling. SDETs write production-quality code for testing systems, not just test scripts.

In practice, the titles overlap and companies use them differently. Look at the job description, not the title.

Structure with STAR: Situation (what was being released), Task (your role), Action (how you found it, what you did), Result (what happened). Be specific: numbers, timelines, actual impact. "I found a bug that would have affected all checkout users and we delayed the release to fix it" is better than "I found an important bug once."

Name specific things: blogs you read (Ministry of Testing, Playwright changelog), conferences (TestBash), newsletters, courses you've completed. Generic "I read articles online" is a weak answer. Specific sources and examples are strong.