Shadow Testing

Shadow testing enables engineers to run testing or a dress rehearsal for your code in production, but without any risk to real users.
You take a new version of a service or feature and run it in parallel with the live version. It gets the same real-world traffic or data, but its results are not shown to users and don’t affect the system, the data can even be excluded from analytics or specific reporting.

Why it’s useful for testers:

Real world example: testing the purchase of consumer finance quotes against cars on eCommerce sites, this enables payments, checks on specified car data and interaction with third parties that will not impact financial reporting, user PII or governance standards. This could be done using a GUI launched from a comms tool or CLI, or feature flag for example.

Definition: Shadowing is a testing in production technique where new code receives real user activity, but users don't see its results. In other words, new code is exposed to users, but users are not exposed to the new code. Engineers then check the health and quality of the new system under real load.

So what? Shadowing lets teams test at real scale and with real behaviour, without risking the user experience. It is especially useful for back-end systems that are hard to load realistically in a lab.

Examples: Users of one product unknowingly triggering status updates in a new back-end service so engineers can assess it. Starting with 1% of traffic and slowly increasing it, combining shadowing with exposure control.