Testing Staging & Pre-Production Environments

The problem

Staging is where you want to catch problems — it mirrors production, it's safe to break, and it's usually where a release candidate lands first. But it's also awkward to test: it's often behind auth or on a private network, the data is inconsistent, and pointing a hosted testing tool at it either isn't possible or means poking a hole in your network.

Why the usual approach falls short

• Hosted tools need a reachable URL. If staging is VPN-only or IP-restricted, a cloud runner can't get to it.
• Manual staging checks are ad hoc. Someone logs in, clicks around, and signs off from memory.
• Scripted suites pointed at staging still carry all the usual maintenance — and now with staging's flakier data on top.

How Manta fits

If staging is reachable, point Manta at the URL with a test account and it explores it like any other app.

If it isn't, run the Manta Runner — a lightweight agent inside your own infrastructure. Tests execute from within your network, so staging stays private and never needs a public endpoint or a firewall exception. Either way, you get the same output: a map of what was reached and a list of what's broken, with screenshots and reproduction steps.

For a release candidate, combine the autonomous sweep with plain-English checks for the must-pass journeys — see release testing.

What it looks like in practice

1. Decide the access path: public URL, or the Manta Runner from inside your network.
2. Provide a dedicated staging test account.
3. Run Manta against the release candidate; review findings before promoting to production.

Where it fits

Staging is the natural home for autonomous runs: production-like, safe to exercise fully, and the last checkpoint before release. The end-to-end testing guide covers environment and test-data practices in more detail.