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.
Senior engineer insight
The moment that changed how I approach environment strategy was watching a SIT test pass cleanly for three weeks, only to find the environment had been pointing at the old schema the entire time — nobody had run the migration script after the last refresh. We had three weeks of confident, utterly worthless test results. After that I made one rule: every environment has a version badge in the footer that shows database schema version and app build number, visible on every page. If those two numbers don't match what your Environment Management Plan says they should be, you stop testing and fix the environment first.
The most common mistake: treating environment setup as a one-time activity at the start of a sprint, then never verifying again. Environments drift silently — a failed migration, a vendor config change, a data refresh that only partially completed. By the time testers notice something is wrong, they have already logged defects that aren't real defects, and missed real ones that the stale environment masked.
From the field
A NZ government agency was migrating a legacy grants management system to AWS. The team assumed that because both old and new environments were "in the cloud," they were equivalent for testing purposes — same OS family, same database engine, different configuration. What they discovered six weeks into SIT was that the new environment had RDS PostgreSQL with a different collation setting than the on-premises database the legacy system used, causing every name-search query involving macrons (common in NZ given te reo Māori names) to return zero results. UAT nearly passed entirely because the UAT test data didn't include macron characters. The fix was trivial once found — a single collation flag — but the lesson was permanent: cloud environments require the same rigour as physical ones. "Same technology" is not the same as "same configuration." They now include a mandatory environment equivalence checklist that covers collation, timezone, locale, and character encoding before any test cycle begins.
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.
Why teams fail here
- Environment-as-code is declared but never enforced: Teams write Terraform or CloudFormation templates, then manually patch environments mid-sprint "just this once." The IaC drifts from reality and nobody notices until an environment rebuild reveals the drift has been accumulating for months.
- Data refresh is scheduled but not verified: The refresh job runs on a cron, but nobody checks whether it completed successfully. A failed refresh leaves UAT running on data that is weeks older than the schedule implies — and the team has no idea.
- Parity is assumed, not measured: "Our staging environment mirrors production" is stated as fact without a mechanism to verify it. Schema version comparison, configuration diff, and integration endpoint audit should all be automated checks, not assumptions — especially in NZ multi-cloud programmes where a vendor might push a hotfix to their sandbox without telling anyone.
- QA waits for environments instead of owning them: When QA treats environments as something developers hand over, the team loses the ability to call a halt when an environment is unfit for testing. QA must own the environment plan and have the authority — and the habit — to formally reject an environment and refuse to begin a test cycle until parity is restored.
Key takeaway
Your test environment is a hypothesis about what production looks like — treat it like one, verify it constantly, and the moment you can no longer prove it representative, stop testing and fix the environment, because every result after that point is built on a lie.
8 Self-Check
Click each question to reveal the answer.
Interview Questions
What NZ hiring managers ask about environment strategy and topology.
Q1. What environments should a typical NZ enterprise project have and what is each for?
Strong answer: Development (individual developer or shared dev), Integration (first stable shared environment for integration testing), Staging/UAT (production-like for acceptance testing and sign-off), and Production. Larger programmes add Performance (isolated load testing), Security Testing (NZISM-required for government, with synthetic data mirroring production structure), and Sandbox (external partners, third-party integrations). Environments upstream of production must be representative enough that passing tests there predict production behaviour — the closer to production, the higher the confidence.
Q2. How do you manage configuration differences across environments without hard-coding values?
Strong answer: Use environment variables for all configuration that changes between environments: URLs, credentials, feature flags, service endpoints. Manage variable sets in a secrets manager (AWS Secrets Manager, Azure Key Vault) or a .env file in .gitignore. In test frameworks, use a configuration layer that reads from environment variables (playwright.config.ts, cypress.env.json). In CI, inject environment-specific config at pipeline run time. The most common mistake: a test suite that passes in staging and fails in production because an API URL was hard-coded to the staging endpoint.
Q3. What is environment drift and how do you detect and prevent it?
Strong answer: Environment drift is when environments that should match (staging and production) diverge over time — different software versions, configuration, or database schema. It causes staging tests to pass but production deployments to fail. Detect it by comparing deployed versions and running the same smoke test suite against all environments after each deployment. Prevent it by using infrastructure-as-code (Terraform, Ansible) to rebuild environments identically, and promoting artefacts through the pipeline rather than rebuilding in each environment.
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?