Build Test Configurations

Configurations determine how a scenario executes: load profile, geography, browsers, environment variables, schedules, and success criteria. Think of them as reusable “run blueprints” that you can execute repeatedly across environments.

Configuration workflow

  1. Select the scenario you want to run plus the version/branch to pin.
  2. Define load & timing – total users, arrival rates, ramp stages, pacing, duration, soak periods, and warmups.
  3. Choose regions & infrastructure – Testable-managed cloud, your own AWS/Azure/GCP accounts, or self-hosted agents.
  4. Pick browsers & channels (for UI tests) or protocol settings (for API/load tests).
  5. Attach data & parameters – map scenario parameters, upload CSV/JSON, or inject secrets.
  6. Add success criteria – thresholds, breaking points, or webhooks.
  7. Schedule or trigger – run on demand, set a schedule, expose trigger URLs, or connect CI.

Walk through the UI in Create a Test Configuration or automate everything through the Configuration API.

Test runner options

Test runners are the machines that execute your workload. Mix and match per configuration:

  • Testable shared grid – fastest path to running browser or protocol tests without provisioning anything.
  • Per-test cloud provisioning – let Testable spin up ephemeral infrastructure in its VPC or yours across AWS, Azure, or GCP. See Test Runners for region lists and quotas.
  • Self-hosted agents – keep traffic inside your network or comply with data residency requirements by deploying Testable agents on Docker-capable hosts.
  • Private regions / hybrid – connect on-prem runners to cloud control plane for low-latency scenarios.

Use the self-hosted guides to provision runners in your own accounts:

Advanced configuration tools

  • Parameters & secrets: map scenario parameters, override defaults per environment, and encrypt sensitive values. See Scenario Parameters and Security.
  • Data files: upload CSV/JSON/ZIP assets via Upload Data.
  • Custom metrics: instrument your code with custom metrics and traces.
  • Network shaping: throttle bandwidth, inject latency, or block hosts using configuration-level network controls.
  • Success criteria: define pass/fail rules, alert thresholds, or auto-stop logic in Success Criteria.
  • Schedules & triggers: create recurring runs or expose trigger URLs for CI/CD and monitoring use cases. Pair with Continuous Integration & Triggers.

Browser and runtime options

  • Pin exact browser versions or channels (e.g., chrome, chrome-beta, msedge) for Playwright/Puppeteer/Selenium scenarios; Testable installs matching binaries automatically.
  • Configure device emulation, viewport sizes, video/screenshot capture, and proxy options per configuration.
  • For API/protocol tests, select protocols (HTTP, WebSocket, TCP) and enable SSL stores or custom DNS.

Observability & governance

  • Tag configurations with services, release trains, or environments for better filtering.
  • Share or lock configurations via project-level permissions and organizations.
  • All edits are audited—use the activity stream or API to trace who changed what.

Next steps

After saving a configuration, you can: