Software Testing Interview Questions and Answers for Freshers (1970)

Software testing is the process of evaluating a software application to detect defects, verify it meets specified requirements, and validate it satisfies real user needs. It reduces production risk, protects brand reputation, and lowers the cost of change by finding issues early.

It combines verification (are we building it right?) and validation (are we building the right thing?).

Testing prevents costly production failures, ensures compliance in regulated industries (banking, healthcare), protects user data, and validates that features match business intent. Studies (IBM Systems Sciences Institute) show a defect found in production costs 100× more to fix than one caught during design.

Verification checks the product is built to specification — reviews, walkthroughs, inspections, static analysis. Validation checks the product meets user needs — functional testing, UAT, beta testing. Verification = right process; validation = right product.

QA is process-focused and preventive (standards, audits, methodology). QC is product-focused and corrective (inspection, defect identification). Testing is one activity inside QC that executes the software to uncover defects.

A test case is a documented set of steps, inputs, preconditions, and expected results used to verify a specific feature or requirement. A well-written test case is atomic, repeatable, traceable to a requirement, and independent of other cases.

A test scenario is a high-level description of what to test — one sentence per business flow (e.g., "verify a user can add an item to cart"). One scenario expands into many test cases covering positive, negative, and edge inputs.

A test plan is a formal document that defines scope, approach, resources, schedule, entry/exit criteria, risks, and deliverables for a testing project. IEEE 829 is the classic template; modern teams condense it into a one-page Confluence brief.

Static testing examines artifacts without executing code — reviews, walkthroughs, static analysis (SonarQube). Dynamic testing executes the code with inputs and observes behavior — unit, integration, system, UAT.

The Software Development Life Cycle covers all phases of building software: Requirements → Design → Implementation → Testing → Deployment → Maintenance. Common models include Waterfall, V-Model, Iterative, Spiral, and Agile.

The Software Testing Life Cycle is the sequence of QA activities: Requirement Analysis → Test Planning → Test Case Design → Test Environment Setup → Test Execution → Test Closure. Each phase has entry and exit criteria.

SDLC covers the full software build, of which testing is one phase. STLC zooms into only the QA activities and runs in parallel with the SDLC's test phase, but with its own planning, design, execution, and closure steps.

The V-Model pairs each development phase with a corresponding test level: requirements ↔ acceptance testing, system design ↔ system testing, architecture ↔ integration testing, module design ↔ unit testing. Testing activities begin as early as requirements are written.

Agile testing is continuous testing embedded in sprints — testers pair with developers on story acceptance, write automated checks each sprint, and rely on techniques like BDD (Given-When-Then), TDD, and exploratory testing. There is no separate "test phase."

Entry criteria define what must be true before a phase can start (e.g., "unit test coverage ≥ 80% before system testing"). Exit criteria define what must be true before it can end (e.g., "zero P1 open, ≤ 5 P2 open").

Boundary Value Analysis (BVA) tests values at the edges of valid ranges — the minimum, maximum, just-below-min, and just-above-max. For an age field accepting 18–60, tests use 17, 18, 60, 61. Bugs cluster at boundaries.

Equivalence Partitioning (EP) divides input data into partitions where the system is expected to behave the same, then tests one representative from each. For age 18–60: one value from <18 (invalid), 18–60 (valid), >60 (invalid) — three tests instead of 100.

A decision table captures combinations of inputs and expected outputs in a matrix — used when business rules have multiple conditions (e.g., loan approval based on age, income, credit score). Every column becomes one test case, guaranteeing full logical coverage.

State transition testing models the system as states (Logged-Out, Logged-In, Locked) and transitions (login, logout, 3 failed attempts). Tests cover valid paths, invalid transitions, and boundary states — ideal for authentication, workflows, and finite state machines.

Use case testing derives test cases from actor-system interactions. Each use case has a main flow and alternate/exception flows; each flow becomes at least one test. Useful for validating end-to-end business scenarios during UAT.

Exploratory testing is simultaneous learning, test design, and execution — the tester uses domain knowledge and heuristics to probe the system without scripted steps. Structured via session-based test management (SBTM) with charters and time-boxed sessions.

Ad-hoc testing is informal, unscripted testing without a plan or documentation — the tester randomly explores the app to find defects. Unlike exploratory testing, it has no charter and is not reproducible.

Error guessing is an experience-based technique where testers use domain knowledge to predict likely defect locations — empty fields, zero values, special characters, session timeouts. It complements formal techniques like BVA and EP.

A defect is any deviation of the software from expected behavior — a missing feature, wrong result, crash, or usability issue. Formally: a variance between actual and expected result.

Standard flow: New → Assigned → Open → Fixed → Retest → Verified → Closed. Alternate states: Rejected (not a defect), Deferred (fix later), Duplicate, Reopened (regression after fix). Tracked in Jira, Azure DevOps, or Bugzilla.

Severity = impact on the system (Critical → Cosmetic). Priority = urgency of fix (P1 → P4). A company logo missing on the homepage is low severity but high priority; a crash on a rarely used admin screen is high severity but low priority.

A quality bug report includes: title, environment (browser, OS, build), preconditions, exact reproduction steps, actual result, expected result, severity, priority, screenshots/videos, console/network logs, and reproducibility rate. Assume the developer has never seen the feature.

A blocker stops further testing (login broken, environment down). A critical defect causes major functionality failure or data loss but testing can continue on other modules. Blockers get immediate escalation.

Defect leakage is a defect that escapes to a later stage — for example, a bug missed in system testing found by the customer in UAT or production. QA metrics track leakage % to measure test effectiveness.

Smoke testing is a shallow, wide check on a new build — do the core flows work? Runs first, before regression. Sanity testing is a narrow, deep check on a specific area after a bug fix or small change. Both are subsets of regression testing.

Regression testing re-runs existing test cases after a code change to confirm nothing that used to work is now broken. It is the primary use case for automation because it repeats every release.

Functional testing verifies what the system does — features, business rules, error handling. Non-functional testing verifies how well it does it — performance, security, usability, reliability, compatibility.

Black-box tests based on inputs and outputs without seeing code (functional QA). White-box tests based on code structure (unit tests, code coverage). Grey-box combines both — tester knows internals but tests from the outside (API + DB testing).

UAT is the final phase where actual end users or business stakeholders validate the product against real-world scenarios and business requirements. Two forms: Alpha (in-house users) and Beta (external users in production-like environment).

Performance testing measures response time, throughput, and stability under load. Sub-types: Load (expected load), Stress (beyond capacity), Spike (sudden burst), Endurance/Soak (sustained load over hours). Tools: JMeter, k6, Gatling.

Security testing uncovers vulnerabilities that could allow unauthorized access, data theft, or service disruption. Covers OWASP Top 10 (SQL injection, XSS, CSRF, broken auth), penetration testing, and static/dynamic analysis (SAST/DAST).

Automation testing uses scripts and tools to execute tests automatically, compare actual vs expected results, and report outcomes. Best for regression suites, data-driven scenarios, and load testing. Not a replacement for exploratory or usability testing.

Manual testing is human-driven, slow but flexible — ideal for exploratory, UX, and one-off validation. Automation is script-driven, fast and repeatable — ideal for regression, smoke, and load. Modern teams use both: automate stable flows, manually explore new features.

Automate: stable and frequently-repeated tests (regression), data-driven tests, load and performance tests, smoke and sanity suites, and tests hard to do manually (concurrency, precise timing). Don't automate one-off tests, UX/look-and-feel checks, or tests for unstable features.

Selenium is an open-source suite (WebDriver, Grid, IDE) for automating web browsers. Supports Java, Python, C#, JavaScript. Selenium 4 added relative locators, Chrome DevTools Protocol access, and Grid 4 with Docker-native scaling.

Playwright is Microsoft's modern browser automation framework (TypeScript, JS, Python, .NET, Java). Ships with auto-waiting, network interception, trace viewer, and parallel execution out of the box — no separate Grid needed.