Software Testing Interview Questions and Answers (1970)

Software testing is the process of evaluating a system to find defects, verify it meets requirements, and validate it solves the user's problem. It combines verification (are we building the product right?) and validation (are we building the right product?).

SDLC (Software Development Life Cycle) covers building the product: requirements → design → development → testing → deployment → maintenance. STLC (Software Testing Life Cycle) covers only QA activities inside SDLC: requirement analysis → test planning → test design → environment setup → test execution → closure.

(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) The pesticide paradox — same tests stop finding bugs. (6) Testing is context-dependent. (7) Absence-of-errors is a fallacy — a bug-free app that solves the wrong problem still fails.

Verification — are we building the product right? Static, done via reviews, walkthroughs, inspections. Validation — are we building the right product? Dynamic, done via test execution and UAT against real user needs.

Severity = business impact (Critical/High/Medium/Low). Priority = urgency to fix (P1/P2/P3/P4). A misspelled company name on the homepage is low severity but high priority; a crash on a rarely used admin feature is high severity but low priority.

Smoke is a wide, shallow build-verification pass — 'does the build even start?' Run on every build, usually automated. Sanity is a narrow, deep check on a specific bug fix or small feature after a minor change. Smoke is broader; sanity is deeper.

Standard flow: New → Assigned → Open → In Progress → Fixed → Retest → Verified → Closed. Alternate states: Rejected, Deferred, Duplicate, Not-Reproducible, Reopened. Every transition is logged in Jira for audit and trend metrics.

Regression re-runs a curated suite after every change to confirm existing features still work. Typically automated at UI/API layer, gated in CI, and prioritised by risk (recent changes, high-traffic flows, top-defect modules).

Unique ID, clear title, precondition, atomic steps, single expected result, traceability to a requirement, priority, no dependency on other tests. Rule of thumb: another tester should reproduce it exactly from your steps alone. See our Manual Testing Q&A hub for 42 more.

BVA tests at input-range edges — min, min-1, min+1, max, max-1, max+1. For a text field 5–15 chars: test 4, 5, 6, 14, 15, 16 characters. Bugs cluster at boundaries where developers use wrong operators (< vs ≤).

EP divides inputs into partitions where behaviour should be identical, then tests one value per partition. For age 18–60: one from <18 (invalid), one from 18–60 (valid), one from >60 (invalid) — three tests instead of dozens.

Lists every combination of conditions and expected actions. For a loan-approval rule (age, income, credit score), each row becomes a test case. Guarantees complete logical coverage and exposes missing rules early.

Exploratory testing is simultaneous learning, test design, and execution — the tester uses charters, heuristics, and domain knowledge to probe the system. Best for new features, incomplete specs, and time-boxed risk assessments. Managed via Session-Based Test Management (SBTM).

Title, environment (browser/OS/build/device), preconditions, exact repro steps, actual vs expected result, severity, priority, screenshots/video, console + network logs, reproducibility %, and a link to the failing test case.

Automate when the test is (1) repeatable across builds, (2) stable in requirements, (3) high-value (top revenue flows), and (4) low-flake in the target environment. Do NOT automate one-off exploratory checks, UX-subjective screens, or captchas.

POM encapsulates a page's locators and actions in a class. Tests call loginPage.loginAs(user) instead of raw driver.findElement(...). Benefits: single point of change when the UI shifts, reusable actions, cleaner tests. See Automation Q&A.

Playwright wins for new projects: built-in auto-waits, first-class trace viewer, parallel by default, network stubbing, cross-browser without Grid. Selenium still wins for legacy suites, IE/older browsers, and Selenium Grid infra investments. See Playwright vs Selenium 2026.

~70% unit + component tests (fast, cheap), ~20% API/integration tests (medium), ~10% end-to-end UI tests (slow, brittle). Inverting the pyramid ('ice-cream cone') is the #1 cause of flaky, slow CI pipelines.

Diagnose the root cause (timing, test data, environment, order-dependence) before retrying. Use explicit waits, isolate test data per run, reset state via API (not UI), pin browser versions, and quarantine chronically flaky tests instead of hiding them behind retries.

Same test logic runs against multiple data sets from CSV/JSON/DB/Excel. Frameworks: TestNG @DataProvider, JUnit 5 @ParameterizedTest, Playwright test.describe.parallel with a data array. Keeps test code DRY and expands coverage cheaply.

API testing validates requests and responses at the service layer — status codes, headers, payload schema, business rules, auth, and performance. Tools: Postman, REST Assured, Playwright, k6, Karate. See API Q&A hub.

2xx success (200 OK, 201 Created, 204 No Content). 3xx redirect (301, 304). 4xx client (400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 409 Conflict, 429 Too Many Requests). 5xx server (500 Internal Server Error, 502, 503, 504).

POST creates a resource (not idempotent). PUT replaces a resource fully (idempotent). PATCH partially updates specific fields (idempotent when applied to the same state).

Verifies that the API request/response contract between consumer and provider holds — even when either evolves independently. Tools: Pact (consumer-driven), Spring Cloud Contract. Prevents 'my service works but breaks yours' incidents in microservices.

INNER JOIN — matching rows in both tables. LEFT JOIN — all left + matched right. RIGHT JOIN — reverse. FULL OUTER JOIN — all rows from both, nulls where no match. SELF JOIN — table joined to itself. See SQL Q&A for testers.

(1) Capture the primary key returned by the UI/API. (2) Run a SELECT against the target table with that key. (3) Assert row exists, column values match input, audit columns populated (created_at, updated_by). (4) Clean up test data or run inside a transaction rolled back at teardown.

SDET (Software Development Engineer in Test) writes production-grade test code, frameworks, tooling, and CI/CD pipelines. Expected to code fluently in one language (Java/Python/JS), design frameworks, review PRs, and own quality end-to-end. See SDET Q&A hub.

Involving QA earlier in SDLC — requirement grooming, story-point estimation, unit-test reviews, contract definition. Cuts defect-fix cost by 6–10× (bug found in prod vs bug found in design).

QA is embedded in the squad, not a downstream gate. Participates in refinement (adds acceptance criteria), sprint planning (test estimates), daily standups (blocker calls), and demos (validation). Definition-of-Done includes automated tests + no P1/P2 open.

CI = every commit is built + unit + component + API tested automatically. CD = every green build is deployable (Continuous Delivery) or auto-deployed (Continuous Deployment). QA owns pipeline gates: unit → API → smoke UI → full regression → performance.

Defect density, defect leakage %, escaped-defect trend, automation coverage %, mean-time-to-detect, mean-time-to-fix, flaky-test %, CI green-build %, sprint acceptance-criteria pass rate.

Risk-based: cover every P0/P1 acceptance criterion, top-5 revenue flows, top-5 defect-density modules, and any changed code. 100% coverage is a myth — aim for coverage of business risk, not lines of code.

Compare env vars, browser version, screen resolution, network policy, test data isolation, timezone, and race conditions with parallel workers. Reproduce inside the same Docker image CI uses. Capture Playwright trace / Selenium video from CI to see the exact failure step.

Keep: (1) top revenue flows, (2) recently changed modules, (3) tests protecting past P1 defects. Cut: duplicates, deprecated features, low-risk cosmetic checks. Run the trimmed set in parallel to fit the window and schedule the full suite post-release.

Re-verify in a clean environment with exact steps, capture video + logs + HAR, share back. If still disagreed, escalate with the requirement reference and a screen recording — never argue on Slack without evidence.

Explain that automation ROI drops after ~80% because remaining tests are exploratory, visual, subjective, or one-off. Propose a target of 70–80% automated regression + 100% CI gating on smoke, backed by defect-leakage metrics — not a raw automation-% target.

Positive (valid creds), negative (invalid password, empty fields, SQL injection, XSS), boundary (max username length), security (rate-limit, brute-force, forgot-password token expiry), session (concurrent logins, remember-me), accessibility (keyboard-only, screen reader), performance (100 concurrent logins), API-layer (401/403 responses).

Use STAR: Situation (context and stakes), Task (what you owned), Action (how you designed the test / spotted the anomaly), Result (impact avoided, in $ or user reach). Pick a bug with data — 'prevented a $40K refund incident' beats 'found a payment bug'.