Stop 03 · Test Planning & StrategyTopics · 7/9

Test Environment Management

In short

Lots of 'flaky' test failures aren't the app's fault at all. The test server had old data, a wrong config or a dead dependency. Managing environments well saves days.

Ensuring the environment tests run in is stable, representative, and properly configured — a huge share of 'flaky test' problems actually trace back to environment issues, not the tests themselves.

The purple blob taps a microphone on a small wooden stage beside a spotlight before a show.

Think of it like this

Rehearsing on the real stage

For the college annual day, you rehearse on the actual stage with the same mic and lights, not in a classroom. Otherwise the mic squeals on the big night. Test environments should match production as closely as you can.

Watch it happen

A build moving through environments

Local

Dev/QA

Staging

Production

1/4The developer runs the app and unit tests on their own laptop.

The big ideas

What you need to know

Match production

Same database version, same config style, similar data size. Differences hide bugs.

Know what's deployed

Always record which build is on which server. 'Works on QA' means nothing without a build number.

Reset data reliably

Seed scripts that rebuild clean test data stop tests failing because of yesterday's leftovers.

Use sandboxes for third parties

Payment and SMS providers offer test modes. Never send real money or messages from a test server.

See it in code

Walk through the code

yaml

1services:2  app:3    image: shop-api:2.3.1        # the exact build under test4    environment:5      DATABASE_URL: postgres://qa:qa@db:5432/shop6      PAYMENTS_MODE: sandbox     # never real money7  db:8    image: postgres:16           # same major version as prod

1/3Pin the build tag. Everyone knows exactly what they're testing.

A Docker Compose file pins exact versions, so every tester's environment is the same and matches production.

Save yourself the pain

Common mistakes

Oops

Reporting a bug without saying which environment and build.

Do this instead

Always include environment and build number. The bug may already be fixed elsewhere.

Oops

Several testers changing shared test data at the same time.

Do this instead

Give each tester or test its own data, or reset data before runs.

Your mission

Spot environment differences

~20 min

Quick check

A test passes on the QA server but the same flow fails in production. What's a likely cause to check first?

Go deeper

1List 3 environment-related issues that could cause a test to fail even when the feature works correctly.
2Learn why environment parity with production reduces 'works in test, fails in prod' surprises.
3Understand test data and environment configuration should be version-controlled where possible.