interviewDeck

Your one-stop platform to prepare, practice and ace your interviews.

Loading your questions…

interviewDeck

All Questions

Filters & tools

Fundamentals Interview Questions and Answers

30 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.

Why do we test software? What is the goal of testing?

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.

  • Catch bugs early (cheaper to fix).
  • Verify behaviour against requirements.
  • Prevent regressions when code changes.
  • Improve trust for release decisions.

Verification vs Validation?

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 vs non-functional 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.

Explain the main test levels: unit, integration, system, acceptance.

  • Unit — smallest piece of code (method/class) in isolation; fast; usually by developers.
  • Integration — modules/services working together (API + DB, service A calling service B).
  • System — the full application as a whole against requirements.
  • Acceptance (UAT) — business/users confirm it is ready for real use.

You need all levels; relying only on UI/system tests is slow and brittle.

What is shift-left testing?

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 vs negative testing?

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).

What is STLC (Software Testing Life Cycle)?

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.

How does testing differ in Waterfall vs Agile?

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 vs Regression testing?

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 vs Dynamic testing?

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.

Black-box vs White-box vs Grey-box testing?

  • Black-box — test using requirements/UI/API behaviour only; no code knowledge.
  • White-box — test with code knowledge (branches, paths, unit tests).
  • Grey-box — mix: know architecture/DB/API contracts while testing like a user (common for SDETs).

What are entry and exit criteria in testing?

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 Plan vs Test Strategy?

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.

What is risk-based testing?

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.

What is compatibility testing?

Compatibility testing checks the product works across supported combinations — browsers, OS versions, devices, or dependent systems (browser × OS, mobile screen sizes, integrations).

What is exploratory testing? When do you use it?

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.

Which quality/testing metrics are useful? Which are misleading?

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.

What makes a good test environment?

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.

What is a Requirements Traceability Matrix (RTM)?

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)

Quality Assurance (QA) vs Quality Control (QC)?

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).

What is TDD? Explain red-green-refactor.

Test-Driven Development: write the test before the code, in a tight loop:

  1. Red — write a small failing test for the next behavior (failing proves the test can fail).
  2. Green — write the minimum code to pass.
  3. Refactor — clean up with the tests as a safety net; repeat.

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()); }

What makes a good unit test? (FIRST principles)

FIRST:

  • Fast — milliseconds; slow suites stop being run.
  • Independent — any order, no shared mutable state between tests.
  • Repeatable — same result everywhere: no real clock, network, or randomness (inject them).
  • Self-validating — asserts pass/fail by itself; no reading logs.
  • Timely — written with (or before) the code.

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).

What is code coverage? Is 100% coverage a good goal?

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.

What do SonarQube and ESLint give you? How do quality gates work?

Static analysis inspects code without running it:

  • ESLint (JS/TS, + Angular rules) — bugs and style at lint speed: unused vars, unsafe any, missing lifecycle interfaces; auto-fixable, runs in the editor and CI.
  • SonarQube — deeper multi-language analysis: bug patterns (possible NPEs, resource leaks), security hotspots (injection, weak crypto), code smells, duplication, complexity — tracked over time per branch/PR.

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.

What are the seven principles of testing (ISTQB)?

  1. Testing shows presence of defects, not their absence — passing tests never prove bug-free.
  2. Exhaustive testing is impossible — you can't test every input/path; use risk and prioritisation.
  3. Early testing (shift-left) — the earlier a defect is found, the cheaper.
  4. Defect clustering — a few modules hold most bugs (Pareto); focus there.
  5. Pesticide paradox — the same tests stop finding new bugs; review and refresh them.
  6. Testing is context-dependent — a banking app and a game are tested differently.
  7. Absence-of-errors fallacy — a bug-free product that solves the wrong problem is still useless.

Explain the test automation pyramid. What is the ice-cream-cone anti-pattern?

The test pyramid describes the ideal shape of an automated suite:

  • Base — many unit tests: fast, cheap, isolated, pinpoint failures.
  • Middle — fewer integration/API tests: verify wiring between modules/services.
  • Top — few end-to-end/UI tests: slow, brittle, expensive — reserve for critical journeys.

The ice-cream cone is the inverted anti-pattern: lots of manual + UI E2E tests and almost no unit tests. The suite becomes slow, flaky, and hard to debug — every failure means launching the whole app.

Mock vs Stub vs Spy vs Fake vs Dummy — what's the difference?

All are test doubles — stand-ins for real dependencies. They differ by what they replace and what you assert:

  • Dummy — passed to satisfy a signature but never used (e.g. a null logger).
  • Stub — returns canned data so the test can proceed (repo returns a fixed user). You assert on state/output.
  • Spy — a real or stub object that also records how it was called, so you can verify afterwards.
  • Mock — pre-programmed with expectations; it fails the test if the interaction doesn't happen. You assert on behaviour/interaction.
  • Fake — a working lightweight implementation (in-memory DB, fake payment gateway) — real logic, not production-grade.
// Stub — canned return, assert on result
when(userRepo.findById(1)).thenReturn(new User("Ana"));
assertEquals("Ana", service.getName(1));

// Mock — assert the interaction happened
verify(emailSender, times(1)).send(eq("ana@x.com"), any());

// Fake — real in-memory implementation
UserRepository repo = new InMemoryUserRepository();

What is BDD? How does Given-When-Then work and how is it different from TDD?

Behaviour-Driven Development extends TDD by writing tests as business-readable scenarios first, so developers, testers, and product owners share one language. Scenarios use Gherkin:

  • Given — the starting context/precondition.
  • When — the action/event.
  • Then — the expected outcome.

Tools like Cucumber/SpecFlow map each step to code (step definitions). The difference: TDD tests units in developer language; BDD tests behaviour in business language and doubles as living documentation.

Feature: Coupon at checkout

  Scenario: Valid percentage coupon reduces total
    Given a cart with items totalling 100
    When the customer applies coupon "SAVE10"
    Then the order total should be 90

What is a flaky test? What causes flakiness and how do you handle it?

A flaky test passes and fails on the same code with no changes — non-deterministic. Flakiness is dangerous because it erodes trust: once a suite "sometimes fails", people start ignoring real failures.

Common causes:

  • Timing/async — fixed sleeps or races instead of waiting for a condition.
  • Test order / shared state — one test leaks data another depends on.
  • Time & randomness — real clock, time zones, Math.random, unstable ordering.
  • Environment — network, third-party APIs, flaky test data.
// ❌ Flaky: guessing how long the async op takes
await sleep(2000);
expect(el.text()).toBe("Loaded");

// ✅ Deterministic: wait for the actual condition
await waitFor(() => expect(el.text()).toBe("Loaded"));

Load vs Stress vs Soak vs Spike testing — what's the difference?

These are non-functional performance tests, each answering a different question:

  • Load testing — behaviour at expected peak load (e.g. 1,000 concurrent users). Verifies response time / throughput meet SLAs.
  • Stress testing — push beyond capacity until it breaks, to find the breaking point and check it fails gracefully (and recovers).
  • Soak / endurance testing — sustained normal load for hours/days to expose slow leaks — memory leaks, connection-pool exhaustion, disk fill.
  • Spike testing — a sudden sharp jump in load (flash sale, viral event) and back down; checks auto-scaling and recovery.