Software Testing & QA Interview Questions and Answers

Legacy code is often defined as code without tests, which makes changing it risky. The core technique is to introduce a seam, a place where behaviour can be substituted without editing the code under test.

Michael Feathers' approach:

1. Identify a change point and find the smallest behaviour to pin down.
2. Break dependencies by extracting interfaces, wrapping static or global calls, and injecting collaborators through constructors or parameters.
3. Write characterisation tests that capture current behaviour, even if it looks wrong, so you know when you change it.
4. Refactor under that safety net in small steps, then add tests for the new behaviour.

class Report {
    Report(Clock clock, Mailer mailer) { ... } // seams injected
}

Tools help: approval or golden-master tests capture output for comparison, and dependency-breaking tools can substitute calls at link time. The risk is over-mocking, so prefer real fakes where feasible. Do not aim for full coverage first; cover the areas you are about to change.

Testing a distributed system needs a layered strategy, because full end-to-end coverage does not scale.

• Unit tests per service for domain logic, run on every commit.
• Component tests that start one service with its dependencies faked, to test its API and data layer.
• Contract tests, using consumer-driven contracts such as Pact, to verify that a provider still satisfies what consumers expect. This catches integration breaks without a full environment.
• Integration tests against real infrastructure for databases, queues and external gateways, ideally with testcontainers.
• A small number of end-to-end journeys, run against staging, for critical flows.
• Non-functional tests: load, resilience and chaos, to check behaviour under failure.

unit -> component -> contract -> integration -> e2e

Support this with test data management, environment parity, observability in CI and fast feedback. Prefer testing at the lowest layer that can catch a given bug, and make failures easy to localise, because debugging a red pipeline across ten services is the real cost.