Search the practice set
275 questions, 991 terms and 600 topics in 30 areas.
60 results for “Mutation Testing”
Mutation Score
The proportion of deliberately introduced faults that the test suite detects — a measure of whether tests would notice a defect, unlike coverage.
Contract Testing
Verifying that a provider satisfies the expectations each of its consumers actually relies on, without running all the services together.
Failure Injection Testing
Deliberately introducing faults into a system under test to verify that timeouts, retries, fallbacks and circuit breakers behave as designed.
Load Testing
Driving a system with realistic traffic at a target volume to verify it meets its performance targets before real users do.
Testing Strategy Shape
The distribution of tests across levels, chosen so that feedback is fast where it can be and confidence is real where it must be.
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.
Adversarial Evaluation
Deliberately attempting to make a model behave badly, because a probabilistic system with no fixed expected output cannot be verified by conventional testing.
Automated Accessibility Coverage
The proportion of accessibility criteria a tool can decide mechanically — around a third — and the explicit acknowledgement that the rest needs people.
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.
Chaos Engineering
Deliberately injecting failure into a system to discover, before an incident does, which of your resilience assumptions are false.
Consumer-Driven Contract
A contract derived from what consumers actually use, published to the provider, and verified in the provider's own build.
Contract Verification Gate
A provider's pipeline stage that replays every consumer's recorded expectations and fails the build if any would break.
Fitness Function
An automated check that an architectural characteristic still holds, run continuously rather than reviewed occasionally.
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.
LLM Evaluation
A repeatable measurement of whether an AI system's outputs are good enough, on cases that reflect the actual task.
Provider Verification
The provider-side stage that replays every consumer's recorded expectations against the real implementation.
Quality Attribute Scenario
A structured, testable statement of a non-functional requirement: source, stimulus, environment, artefact, response, response measure.
Restore Drill
A scheduled, timed exercise of restoring from backup into a clean environment — the only thing that converts a backup from a hope into a control.
Restore Verification
Periodically performing a real restore from backup and validating the result, as the only evidence that a recovery capability exists.
Service Stub Fidelity
How faithfully a stand-in dependency reproduces the real one's behaviour — including its errors, latency and limits — which bounds what testing against it proves.
Shift-Left Security
Moving security checks earlier so findings arrive while the author still has context, on the condition that the signal-to-noise ratio justifies it.
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.
A serverless API works in testing and fails under load with connection errors. The database is at 5% CPU. Explain and fix.
The mechanism Serverless functions scale by creating independent execution environments , each with its own process and its own connection pool. Two hundred con
Three teams keep breaking each other's services with API changes. Someone proposes contract testing. How do you introduce it without a six-month programme?
Start with one pair, not with the estate Pick the pair of services that has broken each other most recently. Instrument that one relationship end to end: the co
A brief database slowdown caused a two-hour full outage. Explain the likely amplification chain and the fixes at each stage.
The chain Slow database → queries that took 10 ms take 2 s. Thread pool exhaustion. Requests hold threads for 200× longer. A pool of 50 that handled the load ea
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
Integration failures between 30 services are found in a shared staging environment, days after merge. Propose a change.
Why the current model fails A shared staging environment is a serialised, high latency feedback channel . Failures are found late, attribution is ambiguous (who
Peak trading day is six weeks away and expected to be four times normal traffic. What do you do in those six weeks?
What the interviewer is testing Whether you can run a readiness programme rather than just "add servers", and whether you know what fails at peak that does not
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
Six weeks before launch, an accessibility audit returns 200 issues. The team's automated checks were green. Why, and what do you do?
Why the checks were green Automated tooling reliably decides roughly a third of the criteria: missing alternative text, insufficient contrast, absent form label
Mutation Testing
Measuring whether tests would actually notice a defect, not just cover a line.
Accessibility Testing
Automated checks, their ceiling, and the manual testing that has to sit above it.
Contract Testing
Verifying what consumers actually rely on, without a shared environment.
Contract Testing at Scale
Keeping dozens of services compatible without an environment that runs all of them.
DR Testing
Restore drills, timed against the stated RTO, into a clean environment.
Load Testing
Realistic data, realistic mix, and a ramp rather than a step.
Resilience Testing
Exercising retries, breakers and fallbacks that are otherwise never run.
Security Testing in the Pipeline
SAST, DAST, dependency and secret scanning, and what to do with the findings.
Soak Testing
Long runs that surface leaks and slow degradation.
Stress Testing
Pushing past target to learn what breaks first and how it fails.
Testing & Quality Architecture
General material on designing a testing strategy as an architectural concern.
Testing Strategies
The pyramid, and the contract tests distributed systems add to it.
Testing in Production
Synthetic transactions, dark launches and shadow traffic, done deliberately and safely.
Chaos as a Test
Fault injection with a hypothesis, a blast radius and an abort condition.
Consumer-Driven Contracts
Consumers declaring what they rely on, and providers verifying against those declarations.
Continuous Controls Monitoring
Testing controls continuously instead of sampling them once a year.
End-to-End Test Economics
Why broad end-to-end suites get slow, flaky and abandoned, and what to keep.
Environment Parity
The differences between staging and production that decide which bugs survive to release.
Flaky Test Management
Quarantine, detection, and the trust a suite loses once red stops meaning broken.
Game Days
Testing the response — runbooks, access, comms — not only the system.
Integration Test Boundaries
What sits inside a test's boundary, what is faked, and the confidence that follows.
Model Evaluation & Red-Teaming
Adversarial testing of a probabilistic system with no fixed expected output.
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.
Quality Gates
Thresholds that block a release, who may override them, and how they decay.
Service Virtualisation
Standing in for a dependency you cannot call, and keeping the stand-in honest.