Software Testing Interview Questions
2026 Edition

Testing is the process of evaluating software to find defects and verify it meets requirements — before users find the problems in production. It is needed because bugs found late cost exponentially more: a requirement-stage fix costs minutes, a production bug can cost a customer. Testing builds confidence, not just bug lists.

SDLC (Software Development Life Cycle) covers the entire product journey — requirements, design, development, testing, deployment, maintenance. STLC (Software Testing Life Cycle) is the testing slice in detail: requirement analysis, test planning, test case design, environment setup, execution, and closure. STLC runs inside SDLC.

Verification — "are we building the product right?" Static checks against design: reviews, walkthroughs, inspections, done without executing code. Validation — "are we building the right product?" Dynamic testing of the running software against user needs. Verification first, validation after.

QA (Quality Assurance) — process-oriented, preventive: defining standards, reviews, audits so defects are not introduced. QC (Quality Control) — product-oriented, detective: checking the actual product against requirements. Testing is the main activity inside QC — executing the software to find defects.

Four classic levels: Unit (individual functions/classes, usually by developers), Integration (modules working together — interfaces between them), System (the complete application end to end against requirements), and UAT (User Acceptance Testing — business users confirm it solves their problem before go-live).

Functional — does the system do what it should? Features, business rules, inputs/outputs (login works, order total is correct). Non-functional — how well does it do it? Performance, security, usability, compatibility, reliability. "The payment works" is functional; "the payment completes in under 2 seconds with 1000 concurrent users" is non-functional.

Black box — testing through the UI/API with no knowledge of internal code; based on requirements. White box — testing with full code knowledge: statement/branch coverage, unit tests. Grey box — partial internal knowledge, e.g. testing through the UI while knowing the database schema to verify the data behind the screen.

A test strategy is the high-level, organisation/product-level approach — what types of testing, tools, environments; it rarely changes. A test plan is project/release-specific — scope, schedule, resources, entry/exit criteria, what is in and out for THIS release. Strategy is the constitution, plan is this month's budget.

A test scenario is a one-line "what to test": "Verify login functionality". A test case is the detailed "how to test": preconditions, exact steps, test data, and expected result for one specific condition — "enter valid username + wrong password, expect error message X". One scenario typically yields many test cases.

Equivalence partitioning — divide inputs into groups expected to behave the same, test one value per group. Age field 18–60: partitions are <18, 18–60, >60 — three tests instead of a hundred. Boundary value analysis — bugs cluster at edges, so test the boundaries: 17, 18, 19 and 59, 60, 61. The two techniques are used together.

Severity — technical impact of the defect (set by the tester). Priority — business urgency to fix it (set by lead/product). The four-quadrant classic: company logo misspelled on the homepage = LOW severity, HIGH priority. App crashes in a rarely-used legacy report = HIGH severity, LOW priority.

New → Assigned → Open (dev working) → Fixed → Retest → Closed if verified, or Reopened if it still fails. Side exits: Rejected (not a bug), Duplicate (already reported), Deferred (fix postponed to a later release). Name the states confidently and mention that the workflow lives in tools like Jira.

Retesting — running the failed test case again after the fix, to confirm THAT defect is gone; always planned and specific. Regression testing — running existing passed tests to confirm the fix did not break something ELSE. Retesting is about the defect; regression is about the neighbourhood around it. Regression suites are the #1 automation target.

Coverage measures how much of the application your tests exercise. In manual testing it is tracked via the Requirements Traceability Matrix (RTM) — every requirement mapped to at least one test case, so untested requirements are visible. In automation/unit testing it is code coverage (statement/branch %).

A unique ID and a clear one-line summary, exact steps to reproduce, test data used, expected vs actual result, environment (browser/OS/build), severity and priority, plus a screenshot or video. The gold standard: a developer can reproduce the bug from your report alone without coming to your desk.

Smoke — a broad, shallow check on a new build: do the critical paths work at all (app starts, login, main flow)? Decides whether the build is testable. Sanity — a narrow, deep check after a small change/fix: does the affected area behave rationally? Smoke = is the build stable enough to test; sanity = is this fix worth deeper testing.

Simultaneous learning, test design and execution — no scripted cases; the tester actively explores using experience and intuition, often time-boxed in charters. Valuable when documentation is thin, time is short, or after scripted suites pass — it finds the bugs scripts were never written for.

Both are unscripted, but exploratory is structured exploration — charters, time-boxes, notes, learnings feed future tests. Ad-hoc is informal random testing with no documentation, usually to quickly break things. Exploratory is a discipline; ad-hoc is a quick raid.

Performance testing checks speed and stability under workload. Load testing — expected user volume: does the site stay fast with 1,000 normal users? Stress testing — beyond capacity: where does it break and does it fail gracefully? Also: spike (sudden surges) and endurance/soak (sustained load over hours, catches memory leaks). Tool to name: JMeter.

Verifying the application behaves correctly across environments — browsers (Chrome/Firefox/Safari/Edge), operating systems, devices and screen sizes, and network conditions. In practice you test a priority matrix of the most-used combinations from analytics, not every combination.

Testing the application's endpoints directly (request → response) without the UI — using Postman or REST Assured. It is faster and more stable than UI testing, catches issues earlier (the UI may not even exist yet), and lets you verify business logic, status codes, response bodies, and error handling precisely.

Automate: regression suites, smoke tests, data-driven repetitive cases, cross-browser checks — anything stable and repeated. Do not automate: one-time tests, constantly-changing UIs, exploratory/usability testing, CAPTCHA/OTP flows. The honest answer interviewers want: automation is an investment that pays off through repetition.

Selenium WebDriver — the core API driving real browsers; what everyone means by "Selenium". Selenium IDE — record-and-playback browser extension for quick prototypes. Selenium Grid — runs tests in parallel across many machines/browsers. (RC is the deprecated ancestor — mentioning that shows you know the history.)

id, name, className, tagName, linkText, partialLinkText, cssSelector, xpath. Preference order: id (fastest, unique) → name → cssSelector → xpath as the flexible fallback. CSS is generally faster than XPath; XPath wins when you must traverse upward (parent) or match by text.

driver.findElement(By.id("username"));
driver.findElement(By.cssSelector(".login-form input[type='email']"));
driver.findElement(By.xpath("//button[text()='Sign In']"));

Absolute starts from the root: /html/body/div[2]/form/input — breaks the moment the page structure shifts; avoid it. Relative starts from anywhere with //: //input[@id='email'] — shorter and resilient. Know the power functions: contains(), starts-with(), text(), and axes like following-sibling.

Implicit wait — a global default: when an element is not found, poll up to N seconds before failing; applies to every findElement. Explicit wait — WebDriverWait + ExpectedConditions for one specific condition (clickable, visible, text present). Best practice: rely on explicit waits, never Thread.sleep(), and avoid mixing the two (it makes timeouts unpredictable).

WebDriverWait wait = new WebDriverWait(driver, Duration.ofSeconds(10));
wait.until(ExpectedConditions.elementToBeClickable(By.id("pay"))).click();

findElement returns the first matching WebElement and throws NoSuchElementException if none exists. findElements returns a List<WebElement> — empty list (no exception) when nothing matches, which makes it the safe way to check element presence.

Dropdowns (<select>): the Select class — selectByVisibleText/Value/Index. JS alerts: driver.switchTo().alert() then accept/dismiss/getText. Frames: driver.switchTo().frame(nameOrIndexOrElement), and back with defaultContent() — forgetting to switch back is a classic bug in candidates' answers.

A design pattern: one class per page/screen holding its locators and actions; tests call readable methods like loginPage.loginAs(user, pass) instead of raw findElements. When the UI changes you fix one page class, not 50 tests. Combine with PageFactory or plain By locators — and be ready to sketch the folder structure.

Richer annotations, built-in parallel execution, test grouping and dependency control, the testng.xml suite file for selective runs, native data-driven support via @DataProvider, and HTML reports out of the box. (JUnit 5 has closed much of the gap — saying so earns credibility.)

@BeforeSuite → @BeforeTest → @BeforeClass → @BeforeMethod → @Test → @AfterMethod → @AfterClass → @AfterTest → @AfterSuite. Browser setup typically goes in @BeforeMethod (fresh browser per test) or @BeforeClass (shared browser), teardown in the matching @After.

Hard assert (Assert.assertEquals) stops the test immediately on failure. Soft assert (SoftAssert) records failures and continues — but reports nothing unless you call assertAll() at the end, the detail interviewers check. Use soft asserts to verify multiple fields on one page in a single test.

A method annotated @DataProvider returns Object[][]; the @Test method that references it runs once per row with the row's values as parameters — same logic, many datasets. For business-managed data, combine with Apache POI to read the rows from Excel.

@DataProvider(name = "logins")
public Object[][] logins() {
    return new Object[][] {{"user1", "pass1"}, {"user2", "pass2"}};
}

@Test(dataProvider = "logins")
public void loginTest(String user, String pass) { /* ... */ }

Data-driven — logic separated from test data (Excel/CSV/DB). Keyword-driven — tests written as keywords/actions in tables, readable by non-coders. Hybrid — combines both, the industry default: POM structure + TestNG + data providers + reporting (Extent/Allure) + CI integration (Jenkins/GitHub Actions). Describe the hybrid one as "what we built in our course project."

2xx success (200 OK, 201 Created), 3xx redirection (301 permanent, 302 temporary), 4xx client errors (400 bad request, 401 unauthenticated, 403 forbidden, 404 not found), 5xx server errors (500 internal, 503 unavailable). The 401-vs-403 distinction is a favourite follow-up: 401 = who are you?, 403 = I know you, you may not.

CRUD over HTTP: GET reads (no body, cacheable, never changes data), POST creates (body carries the new resource), PUT updates/replaces (idempotent — same call twice, same result), DELETE removes. Also PATCH for partial updates. Idempotency of PUT vs POST is the classic probe.

Response body values and structure (against the schema/contract), response headers (content-type, auth tokens), response time, error handling for invalid inputs, and authentication/authorisation behaviour. A 200 with wrong data is still a failed test — say that line, interviewers love it.

Organise requests in collections per module, use environments for dev/QA/prod URLs and variables, chain requests by extracting values (token from login → header of next call), write JavaScript tests in the Tests tab (status, body assertions), and run the whole collection with the Collection Runner or Newman in CI.

Logging defects with steps/severity/attachments, linking bugs to the story they break, tracking the defect workflow (Open → In Progress → Resolved → Closed), and working the sprint board in Agile — picking up testing tasks for stories as they reach the QA column. Mention dashboards/filters for defect summaries if asked about reporting.

Cover all dimensions, not just happy path: functional (valid/invalid combos, empty fields, case sensitivity, forgot-password, remember-me), UI (alignment, tab order, password masking), security (SQL injection in fields, password not in URL, account lockout after N attempts, back-button after logout), boundary (max length inputs), compatibility (browsers/mobile). Naming the categories first, then examples, is what separates a trained tester from a guesser.

Reproduce it again and strengthen the report: exact build number, environment, test data, video recording, and logs. Check environment differences (browser version, config, data state). If it still reproduces, discuss with the developer directly — politely, with evidence. If disagreement persists, escalate to the lead with the evidence and let triage decide. The keyword interviewers want: evidence, not ego.

Testing is never "finished" — it stops when exit criteria are met: planned test cases executed, defect arrival rate has flattened, no open critical/high bugs, coverage targets met, or the business deadline/risk acceptance kicks in. The honest framing: stopping is a risk-based business decision, not a proof of zero bugs.