Software Testing & QA Interview Questions and Answers

Test doubles stand in for real collaborators. The common kinds differ in what they verify.

• Dummy: passed but never used, just to satisfy a signature.
• Stub: returns canned answers, for example a repository returning a fixed user.
• Spy: a stub that also records how it was called.
• Mock: pre-programmed with expectations and verified, so it asserts interaction.
• Fake: a working but lightweight implementation, such as an in-memory database.

when(repo.find(1)).thenReturn(new User("a")); // stub
verify(email).send(any());                    // mock, checks interaction

Stubbing is about supplying indirect inputs; mocking is about verifying indirect outputs. Prefer stubs and fakes for state-based tests, because asserting on every call couples tests to implementation and makes refactoring painful. Use mocks when the interaction itself is the contract, such as an event being published exactly once. Overusing mocks produces tests that pass while the real integration is broken.

Test-driven development is a short cycle that drives design from tests.

1. Red: write a failing test for the smallest next behaviour. It must fail, otherwise it proves nothing.
2. Green: write the simplest code that makes it pass, without worrying about elegance.
3. Refactor: improve the code and tests, removing duplication and clarifying names, while keeping the suite green.

red -> green -> refactor -> repeat

Because tests come first, the code is testable by construction, interfaces are designed from the caller's perspective, and each requirement has a test. The tight feedback loop encourages small steps and prevents scope creep.

Criticisms are real: it does not suit exploratory or UI-heavy work well, it can produce fragmented designs if driven mechanically, and it demands discipline. Variants exist, such as behaviour-driven development with Given-When-Then scenarios, and test-first is also common without the strict refactor step. The lasting value is the safety net and incremental design.

Black-box testing treats the system as an opaque component and derives tests from requirements and the interface, without looking at the code. Testers exercise inputs and observe outputs, focusing on behaviour. Techniques include equivalence partitioning, boundary value analysis, decision tables and state transition testing. It benefits from an independent perspective, can find missing or misunderstood requirements, and is how acceptance testing is usually done.

White-box testing uses knowledge of the implementation to design tests. Coverage of statements, branches, paths and conditions guides what to exercise. It can target tricky logic and reveal unreachable or untested code, and it is common in unit tests.

black box: inputs -> [ system ] -> outputs
white box: inspect conditionals, loops, branches

They are complementary. Black-box testing checks that the right thing was built; white-box testing checks that it is built thoroughly. Grey-box testing combines both, for example using schema knowledge to craft API tests.

Most bugs hide at the edges of valid ranges, because off-by-one and comparison mistakes concentrate there. Boundary value analysis tests just inside, on and just outside each boundary.

For a valid range of 1 to 100, test 0, 1, 2, 99, 100 and 101. Equivalence partitioning complements it by dividing the input domain into classes expected to behave the same, then testing one representative from each: any number below 1, any in range, any above 100.

partition: (-inf,0] [1,100] [101,inf)
boundary:     0  1 ... 100  101

Boundaries also apply to collections: empty, one element, many and maximum. And to types: zero, negative, very large, null and empty string. For date logic, test month ends, leap years, year boundaries and time zones.

Combine the two techniques: partitions decide what to test, boundaries decide exactly where. This gives strong coverage with few cases.

A flaky test passes and fails on the same code. Flakiness is corrosive because teams start ignoring failures, which hides real regressions.

Common causes:

• Timing and asynchronous waits: fixed sleeps, race conditions, animations.
• Shared state: tests depending on order, a shared database or global singletons.
• External dependencies: network, third-party APIs, real clocks and random generators.
• Concurrency: parallel test runs colliding on ports, files or data.
• Resource limits: timeouts that fail on slow CI machines.

Fixes:

• Wait for conditions or events, not fixed durations.
• Isolate state, reset the database per test or use transactions and unique data.
• Seed randomness and freeze or inject the clock.
• Quarantine and fix the worst offenders rather than retrying blindly.
• Add retries only as a stopgap and log diagnostics.

Track flake rate over time and treat it as a quality metric, because a suite people trust is worth far more than a large one they ignore.

Code coverage measures which lines, branches or paths tests execute. It is useful for finding untested code and spotting dead code, and it prevents coverage from silently dropping.

Its limits are important. Coverage says nothing about whether assertions are meaningful. A test can execute every line and assert nothing. It does not prove all input partitions or boundary cases are covered, and high coverage can coexist with serious bugs, including security and concurrency defects. Chasing a number also encourages trivial tests that touch code without checking behaviour.

coverage: did we execute it?
tests:    did we verify it?

Use coverage as a diagnostic and a trend, not a target. A common approach is a modest gate, for example 70 to 80 percent on changed code, plus review of whether critical paths and branches are genuinely tested. Branch and mutation coverage give stronger quality signals, and some code such as generated files should be excluded.

Given a pricing function, write focused tests with JUnit and AssertJ.

class PriceCalculator {
    BigDecimal finalPrice(BigDecimal base, int qty, boolean member) {
        if (qty <= 0) throw new IllegalArgumentException("qty");
        BigDecimal total = base.multiply(BigDecimal.valueOf(qty));
        return member ? total.multiply(new BigDecimal("0.9")) : total;
    }
}

class PriceCalculatorTest {
    private final PriceCalculator calc = new PriceCalculator();

    @Test void multipliesByQuantity() {
        assertThat(calc.finalPrice(new BigDecimal("10"), 3, false))
            .isEqualByComparingTo("30");
    }
    @Test void appliesMemberDiscount() {
        assertThat(calc.finalPrice(new BigDecimal("10"), 1, true))
            .isEqualByComparingTo("9");
    }
    @Test void rejectsNonPositiveQuantity() {
        assertThatThrownBy(() -> calc.finalPrice(BigDecimal.TEN, 0, false))
            .isInstanceOf(IllegalArgumentException.class);
    }
}

The tests cover the happy path, a rules branch and an invalid input, use names that state the behaviour, and avoid floating-point equality by comparing BigDecimal values.