Testing in Production
also called TIP
Deliberately validating behaviour against real traffic, data and scale, using controls that bound the blast radius.
The phrase is provocative and the underlying argument is simply true: some properties cannot be established anywhere else. Real traffic patterns, real data distributions, real third-party behaviour, real scale, real concurrency — no pre-production environment reproduces these, and pretending otherwise is what produces launches that pass every test and fail on contact.
It is not an excuse for skipping testing. It is a set of specific techniques with specific safeguards: canary releases with automated analysis, feature flags limiting exposure to a cohort, shadow traffic where production requests are duplicated to the new version and its responses discarded, synthetic transactions exercising critical journeys continuously, and dark launches that run new code paths without surfacing results.
The prerequisites are non-negotiable and are what separate this from recklessness: strong observability so you can see the effect quickly, fast automated rollback, blast-radius control so an error affects a bounded population, and clear separation of test data from real financial and regulatory records.
The mindset shift for a review board: reliability comes from limiting the impact and duration of failure, not from an unachievable promise that the change cannot fail.