TestInspector connects to CI/CD pipelines through an HTTP trigger API that starts a test suite run from any pipeline step, shell script, or webhook handler. Combined with cron and interval scheduling for unattended execution and live WebSocket streaming for real-time run visibility, TestInspector provides continuous automated test execution without custom tooling between the test platform and the delivery pipeline. The result is test runs tied directly to code changes, deployments, and scheduled cadences — without shell scripts holding them together.

What CI/CD Integration for Test Automation Actually Requires

Most teams integrating test automation into a CI/CD pipeline end up writing more infrastructure code than test code. A typical pattern: install the testing tool's CLI in the pipeline image, add a YAML step that invokes the CLI with environment-specific flags, write a polling script that checks run status every 30 seconds, and map the final exit code to a pipeline pass or fail. This glue code lives in the pipeline definition, not in the test tool, and it must be updated every time the tool's CLI changes, the authentication model changes, or a new CI system is adopted.

A properly designed trigger API removes this layer. The CI step becomes a single HTTP request: POST to the TestInspector API with suite ID and authentication token, receive a run ID, subscribe to run results via WebSocket or poll the status endpoint. The pipeline requires no tool-specific CLI, no version pinning, and no custom exit-code mapping. Any CI system that can make an HTTP request can run TestInspector tests. For teams building a complete test strategy, Astaqc's test automation services and the complete guide to software testing provide broader context on CI integration within a layered QA program.

The TestInspector CI/CD Trigger API

TestInspector's trigger API accepts an HTTP POST request containing the target suite identifier and optional run parameters. Authentication uses an MCP token — an organization-scoped bearer token generated in the TestInspector settings — passed as a standard Authorization header. The API returns a run ID synchronously. The calling pipeline step can then use the run ID in one of two ways: subscribe to the WebSocket stream for live event delivery as steps execute, or poll the run status endpoint at an interval until the run reaches a terminal state.

The trigger request supports optional override parameters: target environment (which set of organization-level variables to apply), specific browser (Chrome, Firefox, Edge, or Safari), and whether to run the full suite or a subset of tagged tests. This makes the same suite reusable across multiple pipeline stages — the same suite that runs against the staging environment on every pull request can be triggered against production after deployment with a single parameter change, without duplicating test definitions.

MCP tokens also enable direct integration with AI-assisted development tools. TestInspector MCP tokens work in Claude Code, Cursor, and Claude Desktop, allowing test generation and trigger requests from within the development environment itself. For organizations using TestInspector as part of an AI-assisted QA workflow, this means tests can be generated, reviewed, and triggered without leaving the IDE or chat interface. See Astaqc's software testing services for support configuring this workflow.

Scheduling Options: Cron, Interval, and One-Time Runs

CI pipeline triggers handle test execution tied to code changes. For execution independent of commits — nightly regression suites, synthetic monitoring checks, pre-deployment smoke tests at scheduled deployment windows — TestInspector provides three scheduling modes that are configured per suite independently of any CI system.

Cron scheduling uses standard five-field cron expressions, allowing any recurrence pattern: nightly at 02:00, every weekday morning, every hour during business hours. Interval scheduling triggers runs every N minutes or hours, suited for synthetic monitoring where continuous verification of production endpoints is needed. One-time scheduling runs a suite at a specific timestamp, useful for pre-planned deployment verification at a known cutover time.

Live Run Streaming via WebSocket

TestInspector streams test run events in real time over WebSocket. Each step execution — navigate, click, assert, HTTP request — produces an event as it completes, including step result, duration, and any error detail. This stream is consumed by the TestInspector dashboard for the live run view and is also available to external consumers that connect to the stream with the run ID and MCP token.

For CI pipelines, the WebSocket stream provides an alternative to polling. A pipeline step that subscribes to the stream receives the terminal event (run passed or run failed) without repeatedly hitting the status endpoint. In practice, polling every 10 to 30 seconds is adequate for most CI integrations and requires no persistent connection; the WebSocket stream is more useful for dashboard displays and monitoring consoles that want step-by-step progress visibility.

The live stream is also relevant for long-running suites. A regression suite that takes 20 minutes to complete provides earlier signal via stream events: if a critical smoke test step fails in the first two minutes, a CI step monitoring the stream can abort the pipeline immediately rather than waiting for the full suite to finish. This reduces pipeline wait time for blocking failures. For teams running performance testing at scale, Astaqc's performance testing services describe how run streaming applies to load test monitoring.

Connecting TestInspector Results to Pipeline Pass/Fail Gates

The TestInspector run status endpoint returns a terminal state of passed, failed, or errored. A CI step that polls this endpoint maps the result to a pipeline exit code: passed maps to exit 0, failed or errored maps to exit 1. This causes the pipeline stage to succeed or fail based on the TestInspector run result, which can be configured to block the deployment stage in a CD pipeline.

For more nuanced gating, the run result includes per-test outcomes. A CI integration that tolerates failures in a specific tagged test group — for example, tests tagged as known-flaky or in-progress — can retrieve the per-test breakdown, filter out the tolerated failures, and compute a custom pass/fail decision. This is useful during migration periods when new tests are being added to the suite before they are considered stable enough to gate the pipeline.

TestInspector exports test results to Playwright TypeScript, Selenium IDE (.side) format, and Gherkin. These exports allow teams to migrate test definitions to other formats or maintain cross-tool compatibility. They are relevant to CI integration when a team's reporting infrastructure expects a specific format. For teams outsourcing QA or managing distributed QA teams, the guide to outsourcing software testing covers how CI-integrated test automation fits into a managed QA engagement, and Astaqc's hire-a-QA-team service provides embedded engineers experienced with CI pipeline integration.

A Practical CI Integration Pattern

The following pattern describes a TestInspector integration that applies to GitHub Actions, GitLab CI, Jenkins, CircleCI, and Azure DevOps by substituting the step syntax. A dedicated job in the workflow runs after the deployment job completes. The job has a single step that uses curl or an HTTP client to POST the trigger request to the TestInspector API, capturing the run ID from the response. A second step polls the TestInspector run status endpoint every 20 seconds in a loop, checking for a terminal state. When the terminal state is received, the step exits with 0 if the run passed or 1 if the run failed.

Organization-level TestInspector variables handle environment-specific configuration. The staging environment suite and the production suite share the same test definitions but reference different base URL variables and credential sets. The CI step passes the target environment as a trigger parameter rather than hardcoding environment-specific values in the pipeline YAML. This keeps environment configuration inside TestInspector — where it benefits from encrypted storage and the variable hierarchy — rather than scattered across CI environment variable settings in multiple pipeline files.

Browser selection is also a trigger parameter. A smoke test suite might be triggered against Chrome only in a fast pre-merge check, and against Chrome, Firefox, and Edge in a more comprehensive nightly run, without maintaining two separate suite definitions. The testing documentation services Astaqc offers cover CI integration documentation, and manual testing services handle the exploratory and scenario-level coverage that automation at earlier stages does not replace.

Frequently Asked Questions

Does TestInspector work with GitHub Actions specifically?

Yes. Any CI system that can execute an HTTP POST request can trigger a TestInspector suite run. GitHub Actions, GitLab CI, Jenkins, CircleCI, and Azure DevOps all support this natively through their HTTP request step capabilities or through shell steps using curl or a similar HTTP client. No TestInspector-specific plugin or GitHub Action is required.

How do MCP tokens differ from regular API keys?

MCP tokens are organization-scoped bearer tokens that authenticate both CI trigger requests and AI tool integrations such as Claude Code, Cursor, and Claude Desktop. They grant access to trigger runs and stream results on behalf of the organization. Rotating an MCP token requires generating a new one in TestInspector settings and updating the pipeline secret that references it.

Can I run only a subset of tests from a suite via the trigger API?

Yes. The trigger request supports tag-based filtering, which allows running only tests tagged with a specific label. This is useful for smoke test stages that should run faster than the full regression suite, or for feature-flagged tests that should only run when a specific flag is enabled in the target environment.

What happens if the TestInspector API is unreachable when the pipeline tries to trigger a run?

The CI step receives an HTTP error response. The pipeline step should be written to treat a non-2xx trigger response as a pipeline failure, which surfaces the connectivity issue as a visible CI failure rather than silently skipping the test run. Retrying with exponential backoff is a reasonable approach for transient network issues.

How does scheduling work across time zones for distributed teams?

TestInspector cron schedules operate in UTC. Cron expressions should be written relative to UTC. For teams that need schedules to align with local business hours, convert the local time to UTC when writing the cron expression. A 02:00 UTC cron covers 10:00 PM Eastern US time the previous day and 07:30 AM Indian Standard Time.

Can a TestInspector run be used to block a deployment if tests fail?

Yes. This is the standard pattern for post-deploy verification gates. The deployment pipeline triggers the TestInspector suite, waits for the terminal result, and fails the deployment stage if the test run failed. The suite should be scoped to the critical user journeys that must pass before the deployment is considered successful, rather than the full regression suite, to keep the gate time reasonable.