test-environment-planner v1.0.0A

Immutable. This exact content never changes and is served at /api/v1/blob/af8d308efea96e2d.

---
name: test-environment-planner
description: >-
  Plan test environments and test data needs: environment matrix, browsers and devices,
  integrations, stubs, data refresh, access and a booking schedule. Use when a QA lead
  says "plan our test environments", "what environments and data do we need",
  "set up the env matrix for this release", or describes a system and its integrations.
  Produces an environment plan with risks and open questions, as a draft that stops for
  review.
license: MIT
metadata:
  author: TheTestingAcademy
  stlc-phase: Test Planning
  version: 1.0.0
---

# Test Environment Planner

You make sure **testing is never blocked by a missing environment, account or data set**.
The plan names what is needed, who provides it, and when it must be ready.

## When to use
- A release needs several environments and the team keeps colliding on staging.
- New integrations (payment, SMS, identity) must be reachable, sandboxed or stubbed.
- Testers lose days waiting for accounts, VPN access or fresh test data.

## Workflow
1. **Map the system.** Ask for the architecture: services, databases, third-party
   integrations, feature flags and deployment pipeline. Never invent an integration.
2. **Build the environment matrix.** For each environment give purpose, build source,
   data type, integration mode (real, vendor sandbox, stub) and owner.
3. **Define browser and device coverage.** Base it on usage analytics if available; tier
   as P0/P1/P2 and state where each runs (local, grid, device cloud).
4. **Plan stubs and virtualization.** For every integration that is costly, rate-limited
   or unavailable, decide stub vs sandbox and what behavior the stub must simulate.
5. **Plan test data.** Accounts per role, seed scripts, refresh cadence, masking of
   personal data, and who resets data after destructive tests.
6. **Sort access and booking.** List VPN, SSO groups, secrets and approvals needed, then a
   booking schedule for shared or exclusive slots (performance runs, UAT).
7. **HUMAN REVIEW GATE (mandatory).** Present the plan as a draft. List unconfirmed owners,
   lead times and `<TBD>` items. Ask the lead and DevOps to confirm before booking.

## Output shape
```markdown
# Test Environment Plan - Payments v3 (Sprints 41-43)
### Environment matrix
| Env     | Use             | Build     | Data             | Integrations               | Owner  |
|---------|-----------------|-----------|------------------|----------------------------|--------|
| QA      | functional, API | main      | synthetic v12    | gateway sandbox, SMS stub  | QA     |
| Staging | E2E, perf, UAT  | release/* | masked prod copy | gateway sandbox, mail trap | DevOps |
### Browser / device coverage
| Tier | Platform                   | Where             |
| P0   | Chrome latest, Safari iOS  | grid, real device |
| P1   | Firefox, Edge, Android     | grid, device cloud|
### Stubs
- Fraud API: WireMock stub (vendor sandbox limited to 100 calls/day); simulate approve,
  review and decline responses plus a 5 s timeout.
### Test data
- 20 accounts per role via seed script; nightly refresh 02:00; card and phone data masked
### Access
- VPN + SSO group "qa-payments"; sandbox keys from vault path <TBD>
### Booking schedule
| Week | Env     | Team | Activity                        |
| 42   | Staging | Perf | load test, exclusive Tue-Wed    |
| 43   | Staging | PO   | UAT, shared, no deploys 9-17    |
--- HUMAN REVIEW GATE ---
Unconfirmed: staging owner, vault path, device cloud license. Confirm before booking.
```

## Guardrails
- Never fabricate hostnames, credentials, vault paths or vendor limits; use `<TBD>` and ask.
- Never put real secrets or unmasked personal data in the plan.
- Stubs must be flagged in test reports so stubbed results are not read as end-to-end.
- Record lead times for access and licenses; they are the usual hidden blocker.
- The plan is a draft until the lead and environment owners confirm it.