Your one-stop platform to prepare, practice and ace your interviews.
Loading your questions…
24 hand-picked Fundamentals interview questions with detailed answers. Open the interactive version above to search, filter by difficulty, run code, bookmark questions and track your progress.
Testing finds defects before users do, reduces risk, and builds confidence that the product meets requirements. The goal is not to prove the software is perfect — it is to provide information about quality so the team can decide whether to ship.
Verification asks: Are we building the product right? — checks against specs/design (reviews, static analysis, unit tests against requirements).
Validation asks: Are we building the right product? — checks whether it satisfies the real user need (UAT, usability, acceptance testing).
Functional checks what the system does — features, business rules, inputs/outputs (login works, order is created, invoice total is correct).
Non-functional checks how the system behaves — performance, security, usability, reliability, compatibility.
You need all levels; relying only on UI/system tests is slow and brittle.
Shift-left means starting quality activities earlier in the lifecycle — during requirements, design, and development — instead of only testing at the end.
Examples: review requirements for testability, write acceptance criteria with the story, automate unit/API tests in the PR pipeline, pair with developers on edge cases.
Positive testing uses valid inputs and happy-path flows to confirm the system works as expected (correct login, successful order).
Negative testing uses invalid/unexpected inputs to confirm the system handles failure safely (wrong password, missing required field, SQL injection attempt).
STLC is the structured process QA follows from planning to closure. Common phases: Requirement Analysis → Test Planning → Test Case Design → Environment Setup → Test Execution → Defect Reporting/Retest → Test Closure.
In Waterfall, testing is mostly a late phase after development is "done". In Agile, testing happens continuously every sprint — stories are tested as they are built, with automation and frequent regression.
Retesting checks whether a specific defect fix works (run the failed case again). Regression checks that the fix (or any change) did not break existing features.
Static testing finds issues without executing code — reviews of requirements, design, test cases, code walkthroughs. Dynamic testing executes the software — manual/automated functional tests, API calls, UI flows.
Entry criteria = conditions before testing starts (build deployed, smoke passed, test data ready). Exit criteria = conditions to stop/finish (planned cases executed, critical bugs closed, coverage/risk accepted).
Test Strategy is the high-level approach (what types of testing, tools, environments, risk focus) — often organisation/project wide. Test Plan is a concrete document for a release/sprint: scope, schedule, resources, deliverables, entry/exit criteria.
Risk-based testing prioritises test effort where failure would hurt most — high business impact × high likelihood. You test payment/order paths deeper than a rarely used settings tooltip.
Compatibility testing checks the product works across supported combinations — browsers, OS versions, devices, or dependent systems (browser × OS, mobile screen sizes, integrations).
Exploratory testing is simultaneous learning, test design, and execution — you investigate the product with a charter instead of only following scripted cases. Use it for new features, weak requirements, or after major UI changes to find unexpected bugs.
Useful: escaped defects, defect leakage by severity, automation pass rate trends, requirement coverage of critical paths, mean time to detect/fix. Misleading as sole goals: raw case count executed, vanity 100% coverage, "number of bugs found" without context.
A good test environment is stable, versioned, and close enough to production for the risks you care about: correct configs, integrated dependencies (or reliable mocks), known test data, and access to logs/DB for debugging.
An RTM maps requirements/user stories to test cases (and sometimes defects). It shows coverage gaps — every critical requirement should have at least one test, and every test should trace to a need.
Req-Login-01 → TC-01, TC-02, TC-03
Req-Order-05 → TC-40, API-12 (missing UI e2e? → gap)QA is process-oriented — preventing defects (standards, reviews, shift-left, good Definition of Done). QC is product-oriented — detecting defects in the build (test execution, inspections of outputs).
Test-Driven Development: write the test before the code, in a tight loop:
Real benefits: design pressure (hard-to-test code reveals coupling early), executable specs, fearless refactoring, and by construction everything is covered. Costs: slower start, and tests welded to implementation details make refactoring harder — test behavior, not internals.
// 1 RED
@Test void emptyCartTotalsZero() { assertEquals(0, new Cart().total()); }
// 2 GREEN: int total() { return 0; }
// 3 next RED forces real logic:
@Test void totalSumsLinePrices() { cart.add(item(100), item(50)); assertEquals(150, cart.total()); }FIRST:
Plus the structural habits: one behavior per test, Arrange-Act-Assert shape, names that state the scenario (withdraw_insufficientBalance_throws), and asserting behavior not implementation (over-mocked tests that break on every refactor are the classic smell).
The percentage of code executed by tests — line, branch (each if-outcome), and condition coverage; measured by JaCoCo (Java) or Istanbul (JS), usually gated in CI (e.g. 80% on changed code).
100% is not a good goal: coverage proves code ran, not that anything was asserted — a suite with zero assertions can hit 100%. Chasing the last percent produces brittle tests of getters and framework glue, while a covered-but-wrong edge case still ships broken.
Healthy use: coverage as a detector of untested areas (a critical service at 30% is a real signal), branch coverage over line coverage, and mutation testing (PIT) if you want to measure test quality.
Static analysis inspects code without running it:
A quality gate fails the pipeline on thresholds — the sane pattern is gating on new code only ("clean as you code"): no new critical issues, coverage on changed lines ≥ X% — so legacy debt doesn't block today's PR but nothing new rots.