Test Environment Management

Q1. What is "environment drift" and why does it matter?

Environment drift happens when two environments that should be identical diverge over time. Example: QA stays on PostgreSQL 14.x while Staging is upgraded to 15.x. Queries behave differently. Tests that passed in QA fail in Staging. It matters because divergence hides bugs until production. The fix is Infrastructure as Code: Terraform configs that deploy identically across environments, and automated validation checks that alert when environments diverge.

Q2. How do you validate that environments match without manually checking each server?

Write a health check script that queries each environment: database version (e.g., `SELECT version()` in PostgreSQL), microservice versions (e.g., `/health` endpoints), network connectivity to external APIs. Store expected values in a config file. Run the script against each environment and diff the output. If any value mismatches, fail loudly. Publish results to a dashboard so drift is visible to the whole team. Tools: custom bash/Python scripts, or managed solutions like CloudWatch or Prometheus.

Q3. When should you use production data in test environments, and when should you mask it?

Never use unmasked production data in QA or Dev (GDPR, Privacy Act violations). Always mask: names → random strings, addresses → fake addresses, account numbers → fake numbers, email → test@example.com. Staging can use masked production data to simulate realistic volume. QA should use synthetic data (generated or seeded). This keeps tests realistic while protecting privacy and isolating environments from real customer risk.

Q1. Tell me about a time when environment drift caused a test failure that production didn't have.

Good answer: Describe a specific incident. Example: "QA was on MySQL 5.7, production on 8.0. A query with GROUP_CONCAT worked in QA but timed out in production. We resolved it by: (1) documenting database versions in Terraform, (2) writing a health check that compares versions, (3) setting up a weekly drift report, (4) ensuring staging is always upgraded alongside production." Show that you learned from the incident and put guardrails in place.

Q2. How do you manage test data across environments?

I use a tiered approach: Dev has synthetic data generated daily. QA has masked production data (copied weekly, with sensitive columns anonymized). Staging has masked data refreshed before major releases. Production is never copied for testing. For sensitive scenarios, I use data builders or factories to generate synthetic data on demand. This keeps tests realistic while protecting privacy and compliance.

Q3. What would you do if third-party staging APIs are often unavailable?

I would: (1) Document the SLA and notify stakeholders that unavailability impacts testing, (2) Use conditional mocking—mock in Dev/QA where possible, real calls in Staging only, (3) Set up monitoring for third-party staging health and alert the team when it goes down, (4) Build a fallback strategy—if staging is down, promote tests from QA without staging validation or delay release. The goal is not to be blocked by someone else's infrastructure.

Q4. How do you ensure a newly provisioned environment is ready for testing?

I use an environment checklist that runs automatically: (1) Deploy infrastructure with Terraform or CloudFormation, (2) Run a health check script that validates OS, database, services, and external API connectivity, (3) Seed test data via a data provisioning script, (4) Run smoke tests against the environment, (5) Generate and review the "Environment Diff Report" against production, (6) Only mark the environment "Ready for Testing" when all checks pass. No manual verification—automation is the gate.