Integration Testing Checklist
Steps a QA engineer or SDET runs before merging a release candidate to validate that services, APIs, and data flows work together end-to-end. Covers environment setup, test data, dependency stubbing, execution, and triage of failures.
Test Environment Setup
-
Provision the integration environment
Spin up the integration cluster (EKS namespace, ECS cluster, or staging VPC) using the Terraform module that mirrors production. Confirm node sizes, autoscaling groups, and IAM roles match prod within one minor version — drift here causes failures that don't reproduce later.
-
Mirror production network configuration
Match VPC peering, security groups, and ALB rules to production. Pay attention to egress rules — many integration failures are services that can reach prod's S3 endpoint but not the integration env's because of a missing VPC endpoint.
-
Apply database schema and seed data
Run the migration suite from a clean baseline against the integration RDS / Postgres instance. Load seed fixtures for tenants, users, and reference data. If a migration takes table-level locks in production, exercise it here at production-like row counts.
Collects file -
Verify observability is wired up
Confirm Datadog / New Relic agents report from each service, Sentry DSN routes to the integration project, and structured logs land in the right index. Without observability you'll be debugging integration failures from kubectl logs alone.
Test Data Preparation
-
Build fixtures for the happy-path scenarios
Create deterministic fixtures for the core user journeys — signup, checkout, subscription change. Use factory libraries (factory_bot, faker) seeded with a fixed value so test runs are reproducible across CI and local.
-
Add edge-case and boundary fixtures
Cover unicode names, timezone boundaries (DST transitions), zero-quantity carts, expired tokens, and tenants with 0 / 1 / 10k records. These are where integration tests catch bugs unit tests don't — interactions between validation layers tend to disagree on edge cases.
-
Confirm PII handling for production-derived data
If any fixture is derived from production exports, scrub or tokenize PII before loading into the integration database. SOC 2 and GDPR auditors will ask whether real customer email addresses live in non-prod — the answer must be no.
Collects list -
Run the PII scrubbing job
Execute the scrubbing pipeline (typically a one-off job that nulls out emails, phones, addresses, and replaces names from a Faker dictionary). Re-import the scrubbed dump into the integration database. Document the scrub commit SHA in the run record.
Collects text
Test Cases and Scripts
-
Audit existing unit and contract test coverage
Pull the coverage report from the last main build. Identify modules where coverage dropped below the team's threshold (commonly 80%) and flag them — integration tests shouldn't be a substitute for missing unit tests.
-
Write integration cases for service boundaries
Focus on the seams — auth service ↔ billing, API gateway ↔ workers, webhook ingest ↔ event bus. Use Postman collections or Playwright API specs that hit real endpoints, not mocked ones. The point of integration testing is the wiring between components.
-
Automate scripts in the CI runner
Wire the suite into GitHub Actions / CircleCI / Buildkite as a required status check on the release branch. Set retry-on-failure to 1 (not 3) — masking flakes with retries is how regressions slip through.
Dependency Management
-
Inventory upstream services and APIs
List every external dependency the suite hits — Stripe sandbox, Auth0 tenant, SendGrid sandbox, internal services from sister teams. For each, note the SLA you can rely on during the test window and the rate limit.
-
Confirm all upstream sandboxes are healthy
Hit each vendor's status page and run a one-call smoke against each sandbox. Stripe and Auth0 sandboxes go down often enough that running a full integration suite against a degraded sandbox is the most common false-positive in this checklist.
Collects list -
Activate WireMock or VCR stubs
For any unhealthy upstream, switch the suite to recorded fixtures (VCR cassettes, WireMock mappings, MSW handlers). Note in the run record which calls were stubbed so the post-deploy verification can re-test them against the real service.
Execution and Monitoring
-
Run the suite against the release candidate
Trigger the full pipeline against the release branch tag (e.g., v2024.45.0-rc.1). Run in dependency order — auth first, then services that depend on auth, then the API layer, then the worker tier. Sequencing surfaces wiring bugs that parallel runs hide.
-
Watch dashboards during the run
Pull up the Datadog APM service map and the error-rate / p99 latency dashboards while the suite runs. A test that passes but doubles p99 against the auth service is still a red flag.
-
Capture the full pipeline artifactCollects list Collects url Collects file
Results Analysis and Reporting
-
Triage each failure to root cause
For each failed test, classify as code defect, environment issue, flaky test, or dependency issue. Avoid the "rerun and merge" reflex — a flaky test that masked a real race condition is the most common path to a Saturday page.
-
File defects in Jira or Linear
Open a ticket per defect with the failing test name, the pipeline link, the suspected commit range (use git bisect on the release branch if needed), and a reproducer. Tag with the release version so the release captain can see the open list.
-
Send the integration test summary
Post a summary to #engineering: pass/fail count, blocking defects, dependencies that were stubbed, recommendation to ship or hold. This is the artifact the release captain reads before flipping the deploy switch.
Collects list
Use this template
Copy it to your account, customize the steps, and run it with your team in minutes.
Browse hundreds of free templates across every team and industry.
Back to template libraryRun Integration Testing Checklist with your team
Customize the steps, assign roles, set a schedule, and keep a complete record for every run.