Environment Strategy & Topology
Most quality problems don’t start in code. They start in environment mismatch — a UAT database running an old schema, a SIT environment pointed at the production payment gateway, a dev environment that hasn’t been refreshed in 6 months. Environment strategy prevents all three.
1 The Hook
A Wellington insurance company runs UAT on an environment cloned from production three months ago. In the interim, the real production environment has had 14 schema migrations applied. UAT passes cleanly against the old schema.
Go-live day. New code deployed against the new schema in production. Day one: 340 API calls fail because UAT validated against a historical snapshot, not the current state. The JSON payloads returning from the database no longer match the field names the front-end expects.
Post-incident root cause: no environment promotion policy. UAT was signed off by the business. The business signed off on behaviour that production had already left behind.
The testers did their jobs. The environment lied to them. That is the problem environment strategy exists to solve.
2 The Rule
Every test environment must be provably representative of the system under test. If the schema, data, or configuration diverges from production, your test results are fiction.
3 The Analogy
A dress rehearsal for a theatre production.
If the rehearsal uses a different stage layout, different props, and different lighting than opening night, the dress rehearsal tells you nothing about whether opening night will work. You have practised the wrong show.
An environment that drifts from production is the same situation. You rehearsed on the wrong stage. The audience on opening night sees something entirely different.
4 Watch Me Do It
Here is an environment topology for a 4-vendor NZ ERP programme. Seven environments, each with a defined purpose and owner.
| Environment | Purpose | Owner | Data | Integrations | Code version |
|---|---|---|---|---|---|
| DEV | Developer unit testing & local debugging | Dev team | Synthetic, local | All stubbed | Feature branches |
| SIT1 | First integration test pass — new features | QA Lead | Masked prod clone, refreshed monthly | Vendor stubs | Release candidate |
| SIT2 | Regression & defect fix verification | QA Lead | Masked prod clone, refreshed monthly | Vendor stubs | Release candidate |
| SIT3 | Multi-vendor integration & performance baseline | QA Lead | Synthetic volume data | Live sandboxes | Release candidate |
| UAT | Business acceptance | Business owner + QA | Masked prod clone, refreshed fortnightly | Live sandboxes | UAT-approved tag |
| Staging | Production-equivalent pre-release validation | Test Lead + Ops | Masked prod clone, schema must match production exactly | All live | Release tag |
| Production | Live service | Ops | Live customer data | All live | Release tag |
The key artefact is the Environment Management Plan — one page per environment covering: purpose, owner, code branch or tag deployed, data refresh schedule, integration stubs vs live, access list, and known issues.
The promotion policy is non-negotiable:
- Code moves left-to-right only. No skipping environments.
- Never promote code with outstanding P1 or P2 defects.
- UAT environment data is refreshed every two weeks, or on demand for major milestones.
- Staging database schema must match production exactly — no exceptions.
5 When to Use It
Environment strategy is not a task you do once. It is an ongoing discipline. Apply it at three points:
- Programme kickoff: Define the full topology before any code is written. Every environment, every owner, every integration decision.
- Drift detection: When teams are unsure what code or schema is in which environment, run an environment audit. Treat the divergence as a defect and fix it.
- Integration failures that are hard to reproduce: The first diagnostic question is always “is the environment representative?” If you cannot answer yes with evidence, the environment is the suspect.
6 Common Mistakes
🚫 “I used to think: the development team manages environments, not QA.”
Actually: QA must own the environment plan and enforce the promotion policy. If environments are wrong, no amount of good testing helps. Developers build software; QA governs the conditions under which it is tested.
🚫 “I used to think: SIT and UAT can share an environment.”
Actually: SIT is for finding defects. UAT is for business acceptance. Combining them means UAT runs on code that is still changing — and the business signs off on the wrong version. They must be separate with a formal promotion gate between them.
🚫 “I used to think: environment drift will sort itself out.”
Actually: Environment drift only gets worse over time. A 2-week-old clone becomes a 3-month-old clone. Monthly refreshes against the production database baseline prevent the Wellington insurance company scenario from ever happening on your programme.
7 Now You Try
Design an environment topology for a new MBIE digital service replacing a legacy licensing system. There are 3 vendors: the development team, a cloud hosting provider, and an identity provider (RealMe). Define the environment stages, what runs in each, who owns them, and what the promotion policy is.
8 Self-Check
Click each question to reveal the answer.
Q1: What is the single most important rule for any test environment?
It must be provably representative of the system under test. If the schema, data, or configuration diverges from production, test results are fiction — the Wellington insurance scenario is the cost of ignoring this.
Q2: Why can’t SIT and UAT share an environment?
SIT is for finding and fixing defects; the code is still changing. UAT is for business acceptance; the code must be stable. Combining them means the business signs off on code that developers may change the next day.
Q3: What does an Environment Management Plan document for each environment?
Purpose, owner, code branch or tag deployed, data refresh schedule, integration stubs vs live, access list, and known issues. One page per environment, maintained throughout the programme.
Q4: What is the code promotion rule?
Code moves left-to-right only (DEV through to Production), never skipping environments, and never with outstanding P1 or P2 defects. Staging database schema must match production exactly before any promotion to production.
Q5: Who owns the environment plan?
QA. Not the development team, not ops alone. QA must own the plan and enforce the promotion policy because the quality of test results depends directly on the quality of the environments.
9 ISTQB Mapping
The ISTQB Test Manager syllabus covers test environment planning, configuration management, and the responsibilities of a test manager in ensuring environments are fit for purpose. Key concepts: environment specification, environment provisioning, and the relationship between environment quality and test result validity. This lesson applies those principles to a realistic NZ multi-vendor programme context.
10 Next Steps
You have the topology. Next: what happens at the gate before code goes to production?