Software Testing & QA Interview Questions and Answers

The test pyramid is a guideline for balancing automated tests by level.

      /\        E2E (few, slow, brittle)
     /  \
    /----\      Integration (some)
   /------\
  /--------\    Unit (many, fast, cheap)

The base is unit tests: numerous, fast, isolated, checking small pieces. The middle is integration or service tests, verifying that components work together, including databases and HTTP boundaries. The top is end-to-end tests through the UI, which give the most confidence that the whole system works but are slow, flaky and expensive to maintain.

The shape matters because tests have different costs and failure signals. A pyramid catches most bugs cheaply, while an inverted shape, the ice cream cone of many E2E tests, leads to slow pipelines and painful maintenance.

The model is a heuristic, not a law. For a data pipeline, integration tests may dominate. Some teams prefer a testing trophy that emphasises integration tests as the best confidence-to-cost ratio.

Unit tests exercise a single function, class or module in isolation, with dependencies replaced by fakes. They run in milliseconds, pinpoint failures and are cheap to write. Their weakness is that they say nothing about how pieces fit together.

Integration tests verify that two or more real components work together: a repository against a real or containerised database, a service against an HTTP client, a queue producer and consumer. They catch wiring, serialisation, transaction and configuration bugs, and are slower but still fast enough for CI.

End-to-end tests drive the whole system through its real interfaces, often via a browser with a tool like Playwright, covering the user journey. They give the strongest confidence that the product works, but they are the slowest and most brittle, and failures are harder to diagnose.

unit < integration < e2e    (speed and count)
unit > integration > e2e    (confidence scope, reversed)

Use all three, with most investment near the bottom.

A good unit test is fast, deterministic, isolated and focused on behaviour.

Characteristics:

• Tests one behaviour, with a clear name such as rejects_negative_amount, so a failure tells you what broke.
• Follows Arrange-Act-Assert, keeping setup, action and verification distinct.
• Has no dependence on execution order, shared mutable state, the clock, the network or random values; inject these as dependencies.
• Asserts on observable outcomes rather than internal implementation, so refactoring does not break it.
• Has a single logical assertion concept; multiple asserts are fine if they describe one behaviour.
• Fails with a message that shows expected versus actual.
• Runs in milliseconds, so the suite can run on every save.

@Test void rejectsNegativeAmount() {
    assertThrows(IllegalArgumentException.class,
        () -> account.deposit(-1));
}

Avoid over-mocking, which couples tests to implementation. A test that never fails, or one that fails for unrelated reasons, costs more than it protects.