How does chaos engineering differ from other testing?

WHAT THIS TESTS Whether you can articulate that chaos engineering is a discipline of experimentation aimed at discovering unknown weaknesses, distinct from tests that confirm known requirements.

A GOOD ANSWER COVERS Chaos engineering is the practice of running thoughtful, controlled experiments on a system by injecting real-world faults, such as a dependency failing, network latency, packet loss, or instance termination, to test a steady-state hypothesis that user-facing behavior stays healthy. The goal is to surface emergent, systemic weaknesses, especially in distributed systems where component interactions produce surprising failure modes that unit and integration tests never exercise. Contrast with other testing: integration testing verifies that components work together as specified, and load testing verifies the system meets performance targets under expected or peak demand. Both check expected behaviors against known requirements in controlled paths. Chaos engineering instead explores the unknown unknowns, often in or near production with real traffic, and emphasizes minimizing blast radius and learning over pass or fail. It is empirical and hypothesis-driven, building justified confidence that the system tolerates turbulent conditions.

COMMON WRONG ANSWERS Calling it randomly breaking things, which ignores the hypothesis and safety controls. Equating it with load testing, which only stresses capacity. Saying it replaces integration tests rather than complementing them. Claiming it can only run in staging, missing the value of realistic production conditions.

LIKELY FOLLOW-UPS What is a steady-state hypothesis. Why run it in production. How do you limit blast radius. How does it complement load and integration testing.

ONE CONCRETE EXAMPLE A load test confirms checkout handles 10,000 requests per minute, and integration tests confirm checkout calls inventory correctly. A chaos experiment then asks a different question: if the inventory service suddenly adds 300ms latency, does checkout completion rate stay above its steady-state threshold. The answer reveals a missing timeout that the other tests, focused on expected behavior, never could have exposed.