Search the practice set
275 questions, 991 terms and 600 topics in 30 areas.
49 results for “Chaos as a Test”
Chaos Experiment
A controlled test that injects a specific failure to verify a hypothesis about the system's resilience, with a defined blast radius and abort condition.
Game Day
A scheduled exercise in which a failure is deliberately introduced and the team responds as though it were real, to test the system and the response together.
Steady-State Hypothesis
The measurable statement of normal behaviour that a chaos experiment predicts will hold while a fault is injected, without which the exercise is not a test.
Boundary Volatility Test
Evaluating a proposed service boundary by asking whether the things on either side change for different reasons and at different rates.
Chaos Engineering
Deliberately injecting failure into a system to discover, before an incident does, which of your resilience assumptions are false.
Control Test Automation
Executing a control's test continuously against the whole population rather than sampling it annually, which changes both the detection latency and the strength of the evidence.
Differentiation Test
The question of whether a capability is a source of competitive advantage, used as the primary filter in build-versus-buy decisions.
End-to-End Test Cost Curve
How the cost of a broad end-to-end suite grows with its size while its marginal value falls, and where the two cross.
Refactoring Under Test
Changing internal structure without changing behaviour, with tests as the mechanism that makes the claim verifiable.
Soak Test
Running sustained realistic load for hours or days to expose defects that accumulate over time rather than appearing under peak load.
Stress Test
Driving load beyond expected capacity to observe how the system behaves at and past its breaking point.
Test Data Provisioning
Getting each test the data it needs, in a state it can rely on, without copying production personal data into a weaker environment.
Test Double Boundary
The line inside a test between what is real and what is substituted, which determines exactly what the test can and cannot prove.
Test Pyramid
A distribution of tests weighted towards many fast unit tests, fewer integration tests, and very few slow end-to-end tests.
Test Quarantine
Moving an intermittently failing test out of the blocking suite into a tracked, owned backlog, so a red build keeps meaning something.
Test Strategy Altitude
Deciding which risks are verified at which level, so that each layer tests something the layers below it structurally cannot.
Arrival Rate Model
Driving a load test by requests arriving per second regardless of how the system responds, rather than by a fixed number of virtual users.
Assumption Excavation
Deliberately surfacing the unstated beliefs behind a design or a requirement, to test which are constraints and which are merely habits.
Booking.com's Experimentation Platform
Booking.com runs over a thousand concurrent experiments and treats the ability to test any change safely as a platform capability rather than a product feature.
Developer Portal
The self-service surface where consumers discover APIs, read documentation, obtain credentials and test calls — the main determinant of adoption.
Failure Injection Testing
Deliberately introducing faults into a system under test to verify that timeouts, retries, fallbacks and circuit breakers behave as designed.
Half-Open State
The circuit breaker state that allows a limited number of trial requests through to test whether a failed dependency has recovered.
Mutation Score
The proportion of deliberately introduced faults that the test suite detects — a measure of whether tests would notice a defect, unlike coverage.
Non-Functional Acceptance
Treating quality-attribute targets as acceptance criteria with automated verification, so a release can fail on latency the way it fails on a broken feature.
Prompt Regression Suite
A set of test cases with expected properties, run against a prompt on every change, to detect quality regressions before deployment.
Testability as a Design Property
How cheaply a system's behaviour can be observed and controlled, which is decided by architecture and largely fixed before any test is written.
Testing Trophy
A distribution weighted towards integration tests rather than unit tests, appropriate where most of the risk lives at boundaries rather than in logic.
Workload Model
A description of the traffic mix, arrival pattern and data distribution a load test reproduces, which determines whether the test's results mean anything.
Your SRE team wants to run fault injection in production. Leadership is nervous. How do you make the case and what do you insist on?
The case Failures happen in production whether or not they are injected. The choice is between discovering how the system responds at three in the morning durin
A DR test fails: the secondary region cannot launch enough instances. What happened, and what standing checks prevent it?
What happened Service quotas in the secondary region are far lower than in the primary , because nothing has ever run there at scale. Quotas are per account and
Netflix built its own CDN; Dropbox moved storage off S3. Both are usually wrong. What conditions made them right, and how do you test for those conditions?
What the interviewer is testing Whether you can extract the conditions from a famous decision rather than the decision itself. These two cases are the most comm
Six teams share one integration test environment. Bookings are made a week ahead and releases slip when someone overruns. How do you fix it?
Name the cost first The queue is not an inconvenience; it is lead time. Measure it: for the last twenty changes, how many days elapsed between "ready to test" a
When should a service call another synchronously, and when should it publish an event instead? Give me the deciding test, not a preference.
The deciding test Does this user action succeed or fail based on this callee's response? If yes, the call is synchronous, because you need the answer to decide.
Your test quarantine has grown to 140 tests over a year. What has gone wrong and how do you recover?
What went wrong Quarantine without a cap and without a deadline becomes a graveyard. Each individual decision was reasonable — move the flaky test aside, raise
A team's CI suite fails roughly one run in three for reasons unrelated to the change. Everyone reruns until green. How do you recover the situation?
Recognise what has actually been lost The suite is no longer a gate. Once the team's reflex on red is "rerun", that reflex is applied to genuine failures too, a
An end-to-end suite of 340 tests takes four hours and fails spuriously about half the time. The team wants to parallelise it. Is that the right move?
Parallelising treats the symptom It might halve the runtime. It will not touch the flakiness — in fact parallelisation often worsens it, by exposing shared stat
End-to-end tests fail intermittently and nobody owns them. QA says the developers broke them; developers say the tests are flaky. How do you resolve this?
The ownership gap is the actual problem A test suite owned by nobody is maintained by nobody, and each failure becomes a negotiation rather than a fix. That is
Chaos as a Test
Fault injection with a hypothesis, a blast radius and an abort condition.
Chaos Engineering
Hypothesis-driven failure injection with a bounded blast radius.
End-to-End Test Economics
Why broad end-to-end suites get slow, flaky and abandoned, and what to keep.
Flaky Test Management
Quarantine, detection, and the trust a suite loses once red stops meaning broken.
Integration Test Boundaries
What sits inside a test's boundary, what is faked, and the confidence that follows.
Non-Functional Test Strategy
Testing availability, latency, security and recovery rather than only behaviour.
Performance Test Design
Workload models, warm-up, think time, and the distribution the average hides.
Test Architecture Strategy
Choosing what to verify where, given the failure modes that actually occur.
Test Data Management
Realistic data without copying production personal data into a weaker environment.
Test Pyramid Shapes
Pyramid, trophy and honeycomb, and the system properties that justify each shape.
Continuous Integration Discipline
Integrating to the mainline daily, and the test speed and review culture that requires.