Software Testing Interview Questions: The Master List (2026 Updated)

Software testing is the process of evaluating a system to find defects, verify that it meets specified requirements, and validate that it solves the user's problem. It is a structured activity that increases confidence in the software, reduces the cost of late defects, and provides objective information about product quality.

QA (Quality Assurance) is process-focused — the entire set of planned activities that prevent defects. QC (Quality Control) is product-focused — the operational activities that verify the product meets requirements. Testing is one specific QC activity that executes the software to find defects.

SDLC (Software Development Life Cycle) is the end-to-end framework for building software, typically with phases: Requirement Analysis → Planning → Design → Implementation → Testing → Deployment → Maintenance. The most common 2026 variants are Agile/Scrum, SAFe, and Shift-Left DevOps.

STLC (Software Testing Life Cycle) is the testing-specific subset of the SDLC: Requirement Analysis → Test Planning → Test Case Design → Test Environment Setup → Test Execution → Test Closure. Each phase has specific entry and exit criteria.

Verification answers "are we building the product right?" through reviews, walkthroughs, and inspections — done before code. Validation answers "are we building the right product?" through actual execution against user needs — done after code.

A test case is a documented set of preconditions, inputs, actions, expected results, and postconditions developed to verify a specific requirement. A good test case has a unique ID, a clear description, traceability to the requirement, repeatable steps, and an unambiguous expected result.

A test plan is a document that describes the scope, approach, resources, schedule, and deliverables of a testing effort. In Agile teams the test plan is often replaced by a lightweight test strategy inside the Definition of Done and the team's working agreement.

A bug is any deviation between actual and expected behavior, or any flaw in a software component that may cause it to perform incorrectly. Bugs are categorized as functional (wrong behavior), non-functional (performance, security, usability), or cosmetic.

Regression testing re-executes previously passed tests after a code change to confirm that existing functionality has not broken. In CI/CD it runs automatically on every pull request. The ideal regression suite is small, fast, deterministic, and high-coverage.

New → Assigned → Open → Fixed → Pending Retest → Retest → Verified → Closed (or Reopened if the fix fails). Rejected means the developer declines it. Deferred means a later release. Duplicate means another report already covers it.

For a complete walkthrough of these fundamentals with templates and examples, read our Manual Testing Complete Guide for 2026.

BVA tests at the boundaries of valid input ranges because defects cluster there. For a field accepting ages 18–60, you test 17, 18, 60, 61 (and the nominal values 30, 45). It pairs naturally with equivalence partitioning.

EP divides inputs into groups (partitions) that should behave the same way, then tests only one value from each group. For a 0–999 numeric field, partitions are <0, 0–999, and >999. You pick one representative from each.

A decision table captures combinations of inputs and their corresponding actions, useful when business rules depend on multiple conditions. For a discount engine (member + coupon code + order value), a table lists each combo and the resulting discount.

Used when system behavior depends on the sequence of events. You model the valid states (New → Approved → Active → Cancelled), the events that trigger transitions, and the guards that allow them. It catches defects around illegal transitions.

You derive test cases from use cases, identifying the actor, preconditions, main flow, alternate flows, and exception flows. Each flow becomes at least one test case.

Severity = technical impact (set by tester). Priority = business urgency (set by product owner). A typo on a pricing page is low severity but very high priority. A crash in a rarely-used admin filter is high severity but very low priority.

Title (one line, what & where), environment, preconditions, exact steps to reproduce, expected result, actual result, screenshots/video/logs, severity/priority, build/version, and a workaround if known. The goal: a developer can reproduce it in under 5 minutes without contacting you.

A simultaneous learning, test design, and execution activity where the tester charters a mission (e.g., "explore the new checkout on mobile for 90 minutes") and adapts based on what they find. It complements scripted testing and is excellent for finding usability and edge-case bugs.

SBTM structures exploratory testing into time-boxed sessions with charters, notes, and debriefs. Output is a session sheet that captures what was tested, what was found, and a coverage map. It provides accountability for exploratory work.

A test matrix tracks test coverage across a grid of variables (e.g., browsers × OS × devices). It is the foundation for prioritization when coverage is impossible on every cell and is the input for cloud testing platforms like BrowserStack and Sauce Labs.

For deeper coverage of test design techniques, see our complete manual testing interview Q&A.

Popularized by Mike Cohn: many fast unit tests at the bottom, a moderate layer of integration/API tests in the middle, and a small layer of end-to-end UI tests at the top. The shape tells you to invest more in fast, cheap tests and less in slow, brittle end-to-end tests.

Executing the same test logic against multiple data sets stored externally (CSV, Excel, JSON, database). Tools like Selenium, Cypress, and Playwright integrate with parameterized fixtures and data providers.

Tests are built from reusable keywords (e.g., openBrowser, loginAs, clickButton) abstracted from the test code. Robot Framework is the most popular keyword-driven tool and is widely used in enterprise QA.

A design pattern where each web page is represented by a class that encapsulates the page's locators and high-level actions. Tests interact with page objects, never raw locators. Benefits: maintainability, readability, parallel authoring of tests and locators.

A test that sometimes passes and sometimes fails without any code change. Causes: shared test data, hard-coded waits, race conditions, network instability, animation timing. The right response is to triage, fix the root cause, and quarantine if necessary.

Use explicit waits instead of sleep, isolate test data, design for parallelism from day one, run on containerized environments, and add retry only as a last resort — with quarantining and dashboards to monitor flake rate.

A practice of moving testing earlier into the SDLC — static analysis on PRs, unit tests on every commit, contract tests on every merge, and feature-flagged canaries in production. It catches defects when they are cheapest to fix.

The complementary practice of testing in production through canary releases, feature flags, synthetic monitoring, A/B testing, and chaos engineering. It catches issues that only appear at scale or under real-world variance.

A test that verifies the agreement between a consumer (frontend, mobile, other service) and a provider (API). Tools like Pact let each side define its expectations, then validate compatibility in CI without spinning up the full system.

TDD writes a failing unit test before the code (red → green → refactor). BDD expresses behavior as scenarios in natural language (Given/When/Then) that non-technical stakeholders can read. BDD frameworks (Cucumber, SpecFlow, Behave) map those scenarios to executable steps.

Build your automation skills with our Cypress Testing Complete Beginner's Guide.

Selenium WebDriver (browser automation API), Selenium IDE (record-and-playback Chrome/Firefox plugin), Selenium Grid (parallel/distributed execution), and Selenium Manager (driver and browser management, default since Selenium 4.11).

findElement returns the first matching WebElement or throws NoSuchElementException. findElements returns a (possibly empty) list of all matching elements and never throws.

ID, Name, ClassName, TagName, LinkText, PartialLinkText, CSS Selector, and XPath. The recommended priority order is ID > CSS > XPath for stability and speed.

close() closes the currently focused browser window. quit() closes all windows opened by the WebDriver session and ends the driver process.

Implicit wait tells WebDriver to poll the DOM for a specified time when finding elements. Explicit wait (WebDriverWait + ExpectedConditions) waits for a specific condition on a specific element. Best practice in 2026 is to avoid implicit waits entirely and use only explicit waits.

A deprecated-but-still-common pattern that initializes Page Object elements using @FindBy annotations. Modern codebases prefer the constructor-based Page Object pattern without Page Factory because it is simpler and faster.

Use stable, semantic locators (data-testid attributes), explicit waits with ExpectedConditions, JavaScript-based scrolling into view, and custom JavaScriptExecutor snippets. Avoid XPath with absolute indices.

Locator strategies like above, below, toLeftOf, toRightOf, and near that find elements based on their position relative to another element. Useful when stable IDs are unavailable.

Options: Selenium Grid (Hub + Nodes) on local VMs, Selenium Grid on Kubernetes, cloud providers (BrowserStack, Sauce Labs, LambdaTest), or TestNG/JUnit parallel attributes on a single machine. In 2026 most teams use cloud grids or containers.

Selenium: broadest language and browser support, mature. Playwright: best-in-class for new greenfield projects that need auto-waiting, tracing, and multi-tab. Cypress: best developer experience for front-end-heavy teams. The choice is usually ecosystem fit, not raw capability.

Drill deeper at Selenium interview questions hub.

Cypress runs inside the browser (not as a remote WebDriver), so it has native access to the DOM, network, storage, and timers. This enables auto-waiting, time-travel debugging, real-time reloads, and stubbing of network calls. The trade-off is a smaller set of supported browsers (Chrome, Edge, Firefox, WebKit) and no native support for multiple tabs or cross-origin iframes.

A static file (typically JSON) in the cypress/fixtures directory that holds test data. Loaded with cy.fixture('users.json'). Use fixtures for reusable, deterministic data; use factories for unique-per-test data.

Reusable functions defined in cypress/support/commands.js that wrap sequences of Cypress commands. cy.login('admin') is a custom command. They are the Cypress equivalent of POM helper methods.

Use cy.intercept('GET', '/api/users', { fixture: 'users.json' }) to stub a response, or cy.intercept('POST', '/api/orders').as('createOrder') and then cy.wait('@createOrder') to assert on a real call.

Use cypress run --headless --browser chrome --record --key <key> with the Cypress Dashboard, or run in your own CI pipeline (GitHub Actions, GitLab CI, Jenkins) and publish JUnit/Mochawesome reports. Cache ~/.cache/Cypress to speed up builds.

Cypress can mount individual React, Vue, Angular, or Svelte components in isolation and test them against their props, events, and rendered output. It is faster than full E2E and lets you test components without spinning up the whole app.

To go deeper, follow our Cypress Testing Complete Beginner's Guide.

REST (Representational State Transfer) is an architectural style for distributed systems. Constraints include statelessness, uniform interface, client-server separation, cacheability, layered system, and code-on-demand (optional). REST APIs typically use HTTP and JSON.

GET (read, safe, idempotent), POST (create, not idempotent), PUT (replace, idempotent), PATCH (partial update), DELETE (delete, idempotent), HEAD (headers only), OPTIONS (capabilities).

Authentication verifies who you are (login, JWT, OAuth token). Authorization verifies what you can do (RBAC, ABAC, scopes, claims). A user can authenticate successfully but be unauthorized to access a resource.

1xx informational, 2xx success (200 OK, 201 Created, 204 No Content), 3xx redirection, 4xx client error (400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 409 Conflict, 429 Too Many Requests), 5xx server error (500 Internal, 502 Bad Gateway, 503 Unavailable, 504 Gateway Timeout).

A test that validates the API matches its published specification (OpenAPI/Swagger). Tools: Pact, Dredd, Spectral, Prism. Contract tests catch breaking changes before they hit consumers.

Asserting that the API response matches the expected JSON schema (data types, required fields, formats). Tools: Ajv (Node), jsonschema (Python), RestAssured + Hamcrest matchers (Java), JSON Schema validators in Postman.

Validate queries (correct shape), mutations (correct side effects), subscriptions (real-time events), error handling, performance (depth, complexity), and security (introspection off in production, query depth limits).

Postman is a GUI + CLI (Newman) tool great for exploration, manual testing, and shared collections. REST Assured is a Java DSL for automated API tests integrated with JUnit/TestNG. In 2026 most teams use both: Postman for exploration, REST Assured or Pact for automation.

For a hands-on walkthrough, see our API testing Q&A hub and API testing pillar guide.

Load — expected load. Stress — beyond expected load until failure. Spike — sudden bursts. Soak/Endurance — sustained load over hours/days to find memory leaks. Capacity — gradual ramp to find the maximum sustainable users.

Throughput = transactions per second the system serves. Response time = time to serve one transaction. They are inversely related under load until saturation, after which response time climbs while throughput plateaus or drops.

Thread Group, Samplers (HTTP Request, JDBC), Listeners (View Results Tree, Summary Report, Aggregate Report, Backend Listener), Assertions (Response, Duration, JSON), Controllers (Loop, Transaction, If), Timers, and Config Elements (HTTP Header, CSV Data Set).

Use the JMeter Maven Plugin, JMeter Gradle Plugin, or jmeter -n -t test.jmx -l result.jtl -e -o report/ in headless mode. Publish the HTML report as a CI artifact and fail the build when SLA thresholds are violated.

JMeter — GUI-rich, broad protocol support, mature. Gatling — code-as-config in Scala, very high throughput. k6 — JavaScript, great developer experience, native Kubernetes integration. Pick by team skills and CI/CD integration.

Extracting dynamic values from a server response (session ID, CSRF token, OTP) and feeding them into subsequent requests. In JMeter use the Regular Expression Extractor, JSON Extractor, Boundary Extractor, or the __regexFunction. Without correlation, recorded scripts fail on replay.

Build a full JMeter plan step by step in our JMeter Performance Testing Step-by-Step Guide.

Test case generation from requirements and code, automated test repair when locators break, visual regression detection, log anomaly detection, predictive defect analytics, AI-generated test data, autonomous exploratory testing agents, and natural-language test authoring.

When a locator breaks, AI engines analyze alternative locators, DOM structure, and historical runs to recover automatically. Tools: Healenium, Mabl, Testim, Functionize. Self-healing reduces maintenance but must be audited — silent healing can hide real bugs.

Hallucinated test logic, biased training data, opaque decisions (hard to debug), over-reliance on flaky AI suggestions, license and IP concerns around generated code, and the false sense of coverage when AI-generated tests are shallow.

An LLM-powered agent that can navigate a UI, observe state, decide actions, and verify outcomes to achieve a high-level goal (e.g., "create a customer and verify the welcome email"). Examples in 2026: Anthropic Computer Use, OpenAI Operator, Microsoft Magentic-One, custom Selenium/Cypress agents.

Read the full landscape in our AI in Software Testing: Tools, Trends, and Careers.

1) Testing shows the presence of defects, not their absence. 2) Exhaustive testing is impossible. 3) Early testing saves time and money. 4) Defects cluster together. 5) Beware of the pesticide paradox. 6) Testing is context-dependent. 7) Absence-of-errors is a fallacy.

If the same tests are repeated, they stop finding new bugs. To overcome it, regularly review and update tests, target new and modified areas, and use exploratory testing.

A symptom is the observable failure (a 500 error on checkout). The root cause is the underlying defect (a null pointer in the discount service when the cart has zero items). Root cause analysis prevents recurrence.

Functional (what the system does), non-functional (how well it does it — performance, security, usability, compatibility), structural (white-box coverage), and change-related (confirmatory & regression).

An extension of the waterfall where each development phase has a corresponding testing phase: Requirements → Acceptance Testing, System Design → System Testing, Component Design → Integration Testing, Coding → Unit Testing. It emphasizes test planning in parallel with development.

Day 1–2: charter exploratory testing sessions to map the product. Day 3–4: identify the top 5 user journeys and build a smoke checklist. Day 5: write 10 critical regression test cases. Week 2: propose a test strategy, automation pyramid, and tooling decisions to the team.

Step back, re-read the requirement and acceptance criteria, reproduce the bug calmly, gather logs/screenshots, ask them which step they disagree with, and escalate politely to the PM if needed. Never let ego drive the discussion — facts and the spec decide.

Confirm impact (users, severity), open a war room, check recent deployments, run the smoke suite, attach logs to the incident, communicate status to stakeholders every 5–10 minutes, and write the timeline for the post-incident review.

Profile to find slow tests, run them in parallel, move API coverage up the pyramid, remove redundant tests, quarantine flaky ones, run smoke on every PR and full suite nightly, and use test impact analysis to run only the tests touching changed code.

Functional: valid creds, invalid creds, locked account, forgot password, MFA, OAuth, SSO. Validation: empty fields, SQL injection, XSS, long strings, special characters. Non-functional: rate limiting, brute force protection, accessibility (screen reader), performance under 10k concurrent logins. Security: cookie flags, session timeout, CSRF.

Map every path: guest checkout, registered checkout, saved cards, new cards, Apple Pay, PayPal, BNPL, promo codes, gift cards, taxes, shipping methods, address validation, partial failures (payment fails after inventory reserved), idempotency on retries, refunds, and 3DS/SCA.

Defect density (per KLOC or per story point), defect leakage to production, mean time to detect (MTTD), mean time to repair (MTTR), test coverage by requirement, automation coverage, flake rate, and cycle time from PR to deploy. Avoid vanity metrics like "bugs found."

Invest in the test pyramid, establish clear test strategy templates, build self-service test data tooling, train on domain knowledge, define a code review process for automation, and create centers of excellence (mobile, performance, security).

Understand the "why" first — fear, lack of training, unclear value. Pair-program with them, give small wins, show time saved, and tie automation outcomes to their goals. Avoid mandates; build believers.

Use risk-based testing: combine likelihood of failure (complexity, churn, defect history) with business impact (revenue, customer trust, compliance). Test the highest-risk areas first, then taper off. Re-prioritize weekly.

T-shape: deep unit tests from day one, contract tests between services, smoke E2E for top journeys, performance baselines from the first release, and production observability (synthetic checks, RUM, error budgets).

Pick a real story with measurable impact (revenue saved, customer trust protected). Show your curiosity — the extra test you designed that found it.

Show respect for the developer, the data you gathered, and the resolution. Avoid "I won" framing — show collaboration.

Own it. Explain the root cause, what you changed in process to prevent recurrence (new test technique, automation, review step), and the lesson learned.

Connect your curiosity, systems thinking, and care for users to the role. Mention specific recent advances (AI testing, shift-left) that excite you.

Describe a growth path that fits the company — senior SDET, test architect, engineering manager, or platform QA. Show ambition and loyalty.