QA and Testing Interview Questions (2026)

Quality assurance (QA) is about the process: preventing defects by improving how software gets built. Quality control (QC) is about the product: checking finished work against requirements. Testing is a QC activity, the act of running the software to find defects.

So QA is preventive and process-focused, QC and testing are detective and product-focused. In practice job titles blur these, but interviewers like to hear you know QA is broader than clicking through screens.

A test scenario is a high-level thing to verify: "a user can reset their password." A test case is the detailed, step-by-step check under that scenario, with data and an expected result: the exact steps, inputs, and the outcome you'd call pass or fail.

One scenario usually spawns several test cases (valid email, unregistered email, expired reset link). Scenarios keep you from missing an area; test cases make the check repeatable by anyone.

A good test case is clear, independent, and repeatable. It states preconditions and test data, gives unambiguous steps, and names one expected result so any tester runs it the same way and reaches the same verdict. It targets a specific risk rather than restating the requirement.

Weak test cases are vague ("check login works"), depend on the order you run them in, or bundle five checks into one so you can't tell what failed.

Positive testing checks that valid input produces the expected result: the happy path. Negative testing feeds invalid, unexpected, or malicious input and checks the system handles it gracefully instead of crashing or corrupting data.

Good coverage needs both. A login form that accepts the right password (positive) but also crashes on a blank field or a 10,000-character username (negative) isn't done.

Boundary value analysis is a technique that tests the edges of an input range, because defects cluster at boundaries. For a field accepting 1 to 100, you test 0, 1, 2 at the low end and 99, 100, 101 at the high end, rather than random middle values.

It pairs with equivalence partitioning: split inputs into groups that should behave the same, then test one value per group plus every boundary. Together they cut a huge input space to a handful of high-value cases.

Equivalence partitioning divides input data into groups (partitions) where every value should be handled the same way, then tests one representative value per group instead of all of them. If age 25 works, you assume 26 through 99 in the same valid partition behave the same.

It's how testers get meaningful coverage without testing every possible input. Combine it with boundary value analysis, which then checks the edges between partitions where the assumption breaks.

Black-box testing works from requirements and behavior with no view of the code: you test inputs and outputs. White-box testing uses knowledge of the internal code and structure to test paths, branches, and logic. Gray-box testing sits between: partial knowledge of internals (like the database schema or an API contract) used to design smarter black-box tests.

Most functional QA is black-box; developers and SDETs do more white-box work like unit and code-path testing. Gray-box is common when you can see the API but test it as a user.

Verification asks "are we building the product right?": reviews, walkthroughs, and static checks that the work matches its spec. Validation asks "are we building the right product?": running the software to confirm it meets the user's actual need.

A quick memory hook: verification is static and happens against documents, validation is dynamic and happens against a running system. You can pass verification (matches the spec) and still fail validation (the spec was wrong).

Static testing examines artifacts without running the code: requirement reviews, code reviews, walkthroughs, and static analysis tools. Dynamic testing runs the software with inputs and checks the outputs. Static testing catches defects early and cheaply; dynamic testing catches what only shows up at runtime.

They complement each other. A requirement review (static) can kill an ambiguity before a single test case exists, which is far cheaper than finding it after the feature ships.

A requirements traceability matrix (RTM) maps each requirement to the test cases that verify it. It's a table linking requirement IDs to test case IDs, so you can prove every requirement has coverage and spot any requirement with no tests.

It matters because it answers the two questions auditors and managers ask: is everything tested, and if a requirement changes, which tests do I need to update? Without it, coverage gaps hide until production.

Testing is never exhaustively complete, so you stop against exit criteria agreed up front: all planned test cases run, a target pass rate met, no open critical or high-severity defects, coverage of key requirements confirmed, and the deadline or budget reached. The decision balances risk against time.

The honest coverage names risk-based judgment: you test the highest-risk areas hardest and ship when the remaining risk is acceptable to the business, not when zero bugs exist, because that state doesn't arrive.

The ISTQB names seven. The ones interviewers probe: testing shows the presence of defects but can't prove their absence; exhaustive testing is impossible, so you prioritize by risk; defects cluster (a few modules hold most bugs, the Pareto pattern); and the pesticide paradox, where repeating the same tests stops finding new bugs, so you keep revising them.

Two more worth knowing: test early (defects are cheaper to fix the earlier you find them) and testing is context-dependent (a banking app and a game demand different rigor).

Start by understanding, not clicking. Read the requirement or user story, list the scenarios it implies, and clarify anything ambiguous with the product owner before writing a single case. Then design test cases covering positive, negative, and boundary paths, prioritized by risk, so the critical flows get the most cases.

From there: set up the environment and data, run the cases while staying alert for anything unexpected (that's where exploratory testing earns its place), log defects with clear reproduction steps, retest fixes, and confirm nothing else broke. The order matters because rushing to click before you've mapped the scenarios is how coverage gaps happen.

Smoke testing is a shallow, wide check that a new build's critical paths work at all, run before deeper testing to decide if the build is even worth testing. Sanity testing is a narrow, deeper check on a specific area after a small change or bug fix, to confirm that piece works before moving on.

Memory hook: smoke is wide and shallow (does the whole build hold together?), sanity is narrow and focused (did this one fix actually work?). Both are quick gates, not full test passes.

Regression testing re-runs existing tests after a code change to confirm that new work didn't break something that used to work. You run it after bug fixes, new features, config changes, and before every release, because a change in one module can ripple into others.

The scaling problem is real: the suite grows every release. Teams solve it by prioritizing high-risk areas, and by automating the stable regression cases so they run on every build without a human clicking through them.

Retesting (confirmation testing) re-runs the exact failed test on a specific defect after it's marked fixed, to confirm the fix works. Regression testing runs a broader set of tests to make sure the fix, or any change, didn't break something elsewhere.

So retesting is narrow and targeted at one defect with known steps; regression is wide and guards against side effects. You retest the bug, then regression-test around it.

Four levels, from small to large. Unit testing checks individual functions or components, usually by developers. Integration testing checks that components work together and data passes correctly between them. System testing checks the whole application end to end against requirements. Acceptance testing checks the system meets the user's or business's needs, often by the client (UAT).

Each level catches different defects: unit finds logic bugs, integration finds interface bugs, system finds end-to-end flow bugs, acceptance finds fit-for-purpose gaps.

The software development life cycle (SDLC) covers the whole build: requirements, design, development, testing, deployment, maintenance. The software testing life cycle (STLC) is the testing slice: requirement analysis, test planning, test case design, environment setup, test execution, and test closure.

The modern point is that testing isn't one phase at the end. Reviewing requirements (static testing) starts before code exists, and shift-left testing pushes QA earlier so defects are caught when they're cheap to fix.

Functional testing checks what the system does: does the feature behave per the requirement (login, checkout, search). Non-functional testing checks how well it does it: performance, load, security, usability, compatibility, reliability.

A checkout that computes the right total passes functional testing but can still fail non-functional testing if it takes 30 seconds under load or leaks card data. Both matter; the non-functional gaps are the ones that make headlines.

Exploratory testing is simultaneous learning, test design, and execution: you interact with the app, follow your instincts about where bugs hide, and design the next test based on what you just saw, instead of following a pre-written script. It's structured curiosity, not random clicking.

It's valuable when requirements are thin, on new features, and for finding the weird bugs scripted cases miss, because a script only checks what its author thought of. Strong teams pair scripted regression with timed exploratory sessions.

Ad hoc testing is informal, unstructured testing with no plan, documentation, or defined approach: you try to break the software however you can, often to reproduce a reported issue fast. Exploratory testing is also unscripted but is structured: it has charters, notes, and a learning approach you can repeat and report on.

So both are unscripted, but exploratory is deliberate and leaves a trail; ad hoc is throwaway. Ad hoc is fine for a quick check; exploratory is a real testing strategy.

UAT is the final testing level where actual users or the client validate that the system meets their business needs and is ready for real use. It happens after system testing, in a production-like environment, and focuses on real workflows rather than technical edge cases.

The tester's role is to support UAT: prepare realistic scenarios and data, help users run them, and triage what they report. Passing UAT is usually the gate to release, so it's as much about business sign-off as defect finding.

Compatibility testing checks the app works across the environments users actually have: browsers, operating systems, devices, screen sizes, and network conditions. The trap is trying to cover everything, which is impossible, so you prioritize.

You decide from data: analytics on which browsers and devices your users actually use, then cover the top combinations that represent most traffic, plus any known-fragile ones. Testing Chrome, Safari, one Android, and one iPhone often covers the large majority; chasing a browser with 0.1% share is wasted effort.

Load testing checks behavior under expected traffic. Stress testing pushes past expected limits to find the breaking point and how it fails. Spike testing throws a sudden surge at the system. Soak (endurance) testing runs normal load for a long time to catch slow leaks like memory growth. Scalability testing checks how adding resources changes capacity.

You don't run all of these on every project. Match the type to the risk: an e-commerce site fears Black Friday spikes; a long-running service fears memory leaks under soak.

Automate tests that are stable, repeated often, and expensive to run by hand: regression suites, smoke tests, data-driven checks with many input combinations, and anything run on every build. Keep manual the tests that change frequently, need human judgment (usability, look and feel), or run once, because automating them costs more than it saves.

The rule of thumb: automation pays off when a test runs many times and the feature under it is settled. Automating a screen that's redesigned every sprint just means rewriting scripts every sprint.

The automation pyramid is a guideline for how to distribute automated tests: a wide base of fast, cheap unit tests, a middle layer of integration and API tests, and a thin top of slow, brittle UI (end-to-end) tests. The shape argues for pushing tests as low as possible.

The anti-pattern it warns against is the ice cream cone: mostly UI tests, few unit tests. UI tests are slow and flaky, so a top-heavy suite is expensive to run and painful to maintain. Testing logic at the unit or API level is faster and more stable.

Selenium finds elements by ID, name, class name, tag name, link text, CSS selector, and XPath. ID is the most reliable when available because it should be unique and stable. CSS selectors are fast and readable. XPath is the most flexible (it can traverse up the DOM and match on text) but is slower and more brittle.

The reliability rule: prefer stable, purpose-built attributes. A test-specific attribute like data-testid or a good ID beats an XPath that depends on the page's exact structure, because a layout change breaks the XPath but not the id.

An implicit wait sets a global timeout: Selenium polls for a bit before throwing 'element not found', applied to every element lookup. An explicit wait pauses for a specific condition on a specific element (until it's clickable, visible, or present), so it waits only as long as needed for that one thing.

Explicit waits are preferred because they target the actual condition you care about and avoid both flaky failures and wasted time. Mixing implicit and explicit waits can cause unpredictable timing, so teams usually pick explicit and drop implicit.

The Page Object Model (POM) is a design pattern where each page (or major component) gets a class that holds its locators and the actions you can do on it. Tests call methods like loginPage.login(user, pass) instead of scattering raw locators everywhere.

The payoff is maintenance: when a page changes, you update one page object, not fifty test scripts. It also makes tests readable, because they describe intent (log in, add to cart) instead of clicks and selectors.

You send requests (GET, POST, PUT, DELETE) with the right headers, auth, and body, then assert on the response: the status code, the response body's structure and values, response time, and error handling for bad input. Tools like Postman or REST Assured make and validate these calls.

A solid API test set checks the happy path (valid request returns 200 and correct data), negative cases (missing fields return 400, no auth returns 401), and edge cases (large payloads, boundary values). API testing is faster and more stable than UI testing, which is why it sits in the middle of the pyramid.

API tests are faster, more stable, and pinpoint failures better. They skip the browser, so they run in milliseconds instead of seconds, don't break when a button moves, and tell you exactly which endpoint failed rather than 'the page didn't load'. You can test business logic and edge cases directly without setting up a full UI flow.

UI tests still matter for verifying the actual user experience end to end, but they should be the thin top of the pyramid. Pushing logic tests down to the API layer is how teams get fast, reliable suites.

A flaky test passes and fails without any code change, usually from timing (racing the app before it's ready), test-order dependencies, shared test data, or an unstable environment. Flaky tests are dangerous because they erode trust: people start ignoring failures, and a real bug slips through.

The fix is root-cause, not retry: use explicit waits instead of fixed sleeps, make tests independent with their own data and teardown, stabilize locators, and isolate the environment. Blindly re-running until green just hides the problem.

In CI/CD, automated tests run on every code push. A typical pipeline runs fast unit tests first, then integration and API tests, then a smoke or regression suite, and blocks the merge or deploy if tests fail. The goal is fast feedback: catch a regression within minutes of the commit that caused it.

The QA role is keeping that suite fast and trustworthy. Slow or flaky tests get skipped, which defeats the point, so you prioritize quick, stable checks in the pipeline and run longer suites (full regression, performance) on a schedule.

Good test data is independent and repeatable: each test creates or resets the data it needs, rather than depending on data left by another test or a shared fixture that anyone might change. Common approaches are seeding a clean dataset before a run, generating data via API setup calls, and tearing it down afterward so runs don't pollute each other.

The failure mode to avoid is tests that pass locally but fail in CI because they assumed a record existed. Self-contained data is what makes automation reliable across environments.

Severity is how badly a defect affects the system, a technical measure the tester usually sets: a crash or data loss is high severity. Priority is how soon it should be fixed, a business decision often set by the product owner: how urgent is this to users or the release?

They move independently, which is the whole point. A misspelled company name on the homepage is low severity (nothing breaks) but high priority (it's embarrassing and public). A rare crash in a feature nobody uses is high severity but low priority.

A defect moves through states from discovery to closure. You log it as New; a lead or triage marks it Assigned to a developer; the developer works it and marks it Fixed; you retest and, if the fix works, mark it Closed. If the fix fails retesting, it goes to Reopened and back to the developer.

Other common states: Rejected (not a real defect or works as designed), Duplicate (already logged), and Deferred (real, but pushed to a later release). Knowing these shows you've lived in a bug tracker.

A good bug report lets a developer reproduce and understand the issue without asking you a single question. It needs a clear title, exact steps to reproduce, the expected result, the actual result, the environment (browser, OS, build), severity and priority, and evidence: a screenshot, video, or logs.

The most important part is reproduction steps. A bug that can't be reproduced usually gets marked 'cannot reproduce' and closed, so the value of your report is measured by how easily someone else can hit the same problem.

Pick a real bug with stakes, and walk it as a story: what you were testing, the odd behavior you noticed, how you narrowed down the reproduction, the severity and priority you assigned, and how it got resolved. The best stories involve a bug that scripted cases would have missed, which you caught through boundary thinking or exploratory testing.

Sample answer: "Testing a payments feature, I noticed refunds on orders that used a discount code returned the full pre-discount amount, so the company was over-refunding. It only triggered with a specific coupon-then-partial-refund sequence, so no basic test case hit it. I isolated the exact steps, logged it as high severity, and flagged it high priority because it was losing real money. It turned out the refund logic ignored the applied discount. The fix shipped that week, and I added a regression case so it couldn't come back."

Don't argue, investigate. First confirm your own report is precise: exact steps, exact environment, exact data. Then compare environments (browser version, OS, build, config, user role, network) because 'works on my machine' usually means a difference you haven't captured yet. Capture more evidence: a screen recording, console logs, network traces, the specific account or data.

Often the difference is data state, a role permission, or a cached build. Pinpointing that turns an unreproducible bug into a reproducible one. If it truly can't be reproduced after that, you document the attempts and monitor for recurrence rather than forcing a fix.

A test plan is the document that defines the scope, approach, resources, and schedule of testing for a project. It answers what will be tested, what won't, how, by whom, on what environment, and against what pass or fail criteria. It's the shared agreement so testing isn't improvised.

Core sections: scope (in and out), the test approach and types, environment and tools, entry and exit criteria, roles and responsibilities, schedule, and risks with mitigations. A tester usually works within a test plan and owns the test cases under it.

A test strategy is high-level and usually organization-wide: the standards, testing types, tools, and general approach the company follows across projects. A test plan is project-specific: how that strategy applies to this release, with its scope, schedule, and criteria.

Think of the strategy as the policy and the plan as the project instance of it. Smaller teams sometimes fold both into one document, but knowing the distinction matters at larger organizations.

Risk-based testing: test the areas where a defect would hurt most and where defects are most likely. That means the critical business flows first (login, checkout, payment), then anything recently changed, then high-traffic features, then known-fragile areas. You consciously skip low-risk, rarely used, unchanged corners.

You also communicate the trade-off: tell stakeholders what you tested, what you didn't, and the residual risk, so shipping is an informed decision rather than a silent gamble.

You don't guess silently. First, ask: go to the product owner, business analyst, or developer and get the expected behavior clarified, because testing against an assumption produces useless results. While you wait, you can still do exploratory testing to understand the current behavior and surface obvious issues.

You can also test against implicit standards: even without a spec, a login form shouldn't crash on empty input, an amount field shouldn't accept letters. Document your assumptions in the bug reports so any wrong assumption is easy to correct.

Keep it about the evidence, not the person. A well-written report with clear reproduction steps and impact does most of the arguing for you: it's hard to dismiss a bug that reproduces on demand with a real business cost attached. Frame it as a shared goal, shipping good software, rather than QA versus dev.

If there's genuine disagreement on severity or whether it's a defect at all, that's a triage conversation for the product owner or lead, not a standoff. The tester's job is to surface risk clearly; the business decides what to fix.

Useful metrics include defect density (defects per unit of size or per module, shows where quality is weakest), defect leakage or escape rate (defects found in production vs testing, shows how effective testing was), test case pass rate, defect removal efficiency, and coverage against requirements.

The caution to voice: metrics guide, they don't rule. Chasing a number, like counting bugs logged, can reward the wrong behavior. The point is to spot trends (leakage rising, one module always buggy) and act, not to game a dashboard.