It is a testing problem in the sense that testing cannot happen properly. It is not automatically the test team’s fault.
A broken environment can destroy more testing time than any poorly written test case. Builds fail. Data vanishes. Services point to the wrong place. Overnight jobs reset everything. By lunchtime nobody knows whether the defect belongs to the product or the laboratory.
This is the sort of mess where an independent look at environments, data and ownership often finds the real bottleneck much faster than another meeting about test productivity.
Treat environment stability as delivery capability
Track environment failures separately from product defects. Measure lost test time. Identify recurring causes. Give somebody clear ownership. If the same database restore breaks testing every Tuesday, that is not an exciting mystery requiring another retrospective. If the programme calls all this ‘testing delay’, investigate where the programme’s real bottleneck lies before blaming the testers.
Make the environment representative where representation matters. It does not need to be an exact production clone for every test, but differences that affect behaviour should be understood rather than waved away with ‘production will be better’. Production is a terrible place to validate that theory.
Do not hide bad evidence
If testing was repeatedly blocked or results were produced in an environment known to behave differently, the release report should say so. ‘Testing complete’ is not true just because the deadline arrived.
Build an environment failure backlog
Treat recurring environment problems like product problems. Record them, prioritise them and fix the causes. If nobody owns them because they sit between infrastructure, application teams and suppliers, give them an owner. ‘Shared responsibility’ too often means ‘shared ability to ignore it’.
Good teams also make environment differences visible. Which integrations are stubbed? What data volumes are smaller? Which security controls differ? Which scheduled jobs are absent? That context lets testers interpret results rather than discovering differences one incident at a time.
And when production reveals a failure the test environment could never reproduce, decide whether that gap matters enough to close. Not every environment needs everything. Important differences need conscious decisions.
Do not chase a perfect production clone either. That can become another expensive hobby. Identify the differences that can change test results – integrations, data volumes, configuration, scheduled jobs, security controls, caching, queues – and make those differences deliberate and visible. The problem is not that test and production differ. The problem is discovering the important difference after launch.
If your environment is wrecking delivery and everyone has got used to it, speak to us. We can review the failures, ownership, data and deployment setup and tell you what is genuinely preventing useful testing rather than suggesting the testers write more detailed status reports about being blocked.