Software Testing Basics Interview Questions and Answers (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 cost of change by finding issues early.

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

Primary objectives: (1) find defects, (2) verify the product meets requirements, (3) validate it meets user needs, (4) provide risk information to stakeholders, (5) prevent defects through early involvement, (6) build confidence in a release.

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.

QA is process-oriented and preventive (audits, reviews, standards). QC is product-oriented and corrective (inspection, testing). Testing is one activity inside QC that executes the software to detect defects.

Error = human mistake in code or logic. Defect (bug/fault) = the flaw in the software introduced by the error. Failure = the observable incorrect behavior when the defect is triggered. Not every defect leads to failure (dead code, unreachable paths).

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

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

Testing can prove defects exist, but never that none remain. Even after extensive testing, undiscovered defects may still exist. This is why we use risk-based coverage and continue monitoring in production.

Testing every input, path, and combination is infeasible except for trivial systems. Instead, we use risk analysis, test design techniques (BVA, EP, decision tables), and prioritization to focus effort where impact is highest.

Involve QA from requirements — review specs, add acceptance criteria, and unit-test as code is written. Defects found in requirements cost ~1×; in design ~5×; in coding ~10×; in production ~100× (Boehm's curve).

The Pareto rule applies: ~80% of defects come from ~20% of modules. Track defects per module across releases; concentrate testing effort on hotspot areas rather than spreading uniformly.

Repeating the same tests over time stops finding new defects — the code has been "immunized" against them. Refresh test cases regularly with new inputs, edge cases, and exploratory sessions.

Testing a banking app (regulated, high risk) differs from testing a game (usability-driven). Techniques, coverage, tools, and rigor should match the domain, risk profile, and lifecycle model.

A bug-free product that doesn't meet user needs is still a failure. Testing must validate business value and usability, not just verify against a spec.

Unit — developers test individual functions. Integration — interactions between modules. System — end-to-end product against requirements. Acceptance — business stakeholders / users validate for production. Each level has entry/exit criteria and different owners.

Unit testing validates the smallest testable part of code (function, method) in isolation using stubs/mocks. Owned by developers. Frameworks: JUnit, NUnit, pytest, Jest. Target coverage: 70–80% of business logic.

Integration testing verifies interactions between modules. Approaches: Big Bang (all at once), Top-Down (stubs for lower modules), Bottom-Up (drivers for upper modules), Sandwich (both), Incremental (module-by-module).

System testing validates the complete, integrated system against specified requirements end-to-end. Includes functional + non-functional (performance, security, usability). Owned by QA team.

UAT is the final validation performed by end users or business stakeholders against real-world scenarios. Two flavors: Alpha (in-house users, controlled), Beta (external users, limited release). Sign-off from UAT is typically required before production release.

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

Black-box — tests based on inputs/outputs without knowledge of code (functional QA). White-box — tests based on code structure (unit tests, code coverage). Grey-box — combines both; tester knows internals but tests externally (API + DB validation).

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

BVA tests values at the edges of input ranges — min, min-1, min+1, max, max-1, max+1. For a text field accepting 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 behavior should be identical, then tests one representative per partition. For age 18–60: one value from <18 (invalid), 18–60 (valid), >60 (invalid) — three tests instead of dozens.

A decision table lists all combinations of conditions and their expected actions. For loan approval (age, income, credit score), each row becomes a test case. Guarantees complete logical coverage and exposes missing rules.

Models the system as states and transitions. For login: Logged-Out → Logged-In (correct password), Logged-Out → Locked (3 failed attempts). Tests cover valid transitions, invalid transitions, and state boundaries.

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 charters, heuristics, and domain knowledge to probe the system without scripted steps. Managed via Session-Based Test Management (SBTM).

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. Complements formal techniques.

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.

The Software Development Life Cycle covers all phases of building software: Requirements → Design → Implementation → Testing → Deployment → Maintenance. Common models: Waterfall, V-Model, Iterative, Spiral, 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.

Waterfall is a sequential model where each phase must complete before the next begins. Rigid, easy to manage, but poor at handling changing requirements. Testing happens only after development. Best for well-defined, stable requirements (regulated systems).

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 at requirements — earliest possible defect prevention.

Agile testing is continuous testing embedded in sprints — testers pair with developers on story acceptance, write automated checks each sprint, and rely on 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 coverage ≥ 80% before system testing"). Exit criteria define what must be true before it can end (e.g., "zero P1 open, ≤ 5 P2 open").

Standard flow: New → Assigned → Open → In Progress → Fixed → Retest → Verified → Closed. Alternate states: Rejected, Deferred, Duplicate, Not-Reproducible, Reopened. Tracked in Jira, Azure DevOps, or Bugzilla.

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

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

A test environment is the combination of hardware, software, network, OS, browser, database, and test data configured for running tests. Common environments: DEV, QA, STAGING, UAT, PROD.

Test plan = strategy document (scope, schedule, resources, risks). Test suite = actual collection of test cases grouped by feature or release. One test plan governs many test suites.