> ## Documentation Index
> Fetch the complete documentation index at: https://docs.qa.tech/llms.txt
> Use this file to discover all available pages before exploring further.

# CI/CD Integration

> Integrate QA.tech into your CI/CD workflows to automatically test your applications on every deployment, pull request, or scheduled run.

## Two Ways to Integrate

QA.tech offers two integration modes for CI/CD:

| Feature            | API-Driven Testing                                                                      | AI Exploratory Testing                  |
| :----------------- | :-------------------------------------------------------------------------------------- | :-------------------------------------- |
| **How it works**   | You define test plans, trigger via API                                                  | AI analyzes PR, creates & runs tests    |
| **CI/CD Support**  | Any system (GitLab, GitHub, Bitrise, Bitbucket, Azure DevOps, CircleCI, Jenkins)        | GitHub App and GitLab integration       |
| **Test Selection** | You choose which test plan to run                                                       | AI selects relevant tests automatically |
| **Test Creation**  | You create tests in QA.tech UI or [via API](/api-reference/test-cases/create-test-case) | AI creates tests for new functionality  |
| **Best For**       | Regression testing, scheduled runs, deployment gates                                    | Exploratory testing of new features     |

<Note>
  **Which mode should you use?** - **API-driven**: Use for regression testing,
  scheduled test runs, or when you want full control over which tests run - **AI
  exploratory**: Use GitHub App or GitLab integration when you want AI to
  discover and test new functionality automatically
</Note>

## API-Driven Testing

Works with any CI/CD system that can make HTTP requests. You create test plans in QA.tech, then trigger them programmatically from your pipeline using a simple REST API call. This approach gives you full control over which tests run, when they run, and which environments to test - perfect for regression testing, deployment gates, and scheduled test suites.

### How It Works

1. **Create test plans** in QA.tech - organize your test cases into logical groups
2. **Trigger via REST API** from your CI/CD pipeline
3. **Test runs execute** against your configured environments
4. **Results available** in QA.tech dashboard and via API

### What You Can Do

* **Test preview/staging environments** - Override application URLs dynamically when testing Vercel, Netlify, or custom preview deployments. See [Preview Environments](/core-concepts/applications-and-environments#preview-environments).

* **Override device configurations** - Test with different device presets per-run via API, allowing you to test mobile, tablet, and desktop configurations without creating separate test plans. See [Start Run API](/api-reference/runs/start-test-run) for `devicePresetShortId` parameter details.

* **Block deployments until tests pass** - Wait for test results before proceeding with your pipeline. The GitHub Action has built-in blocking support; other platforms can poll the [Run Status API](/api-reference/runs/get-run) to wait for completion.

* **Schedule recurring test runs** - Set up nightly regression suites or periodic smoke tests using your CI/CD system's cron functionality.

* **Custom Slack notifications** - Send test results to specific Slack channels per-run, separate from your project's default channel. See [Notifications](/core-concepts/notifications).

* **Run specific test plans** - Target regression suites, smoke tests, or full test suites by specifying the test plan short ID.

* **Custom post-run automation** - Use the [Run Status API](/api-reference/runs/get-run) to trigger webhooks, update status pages, or send custom alerts when runs complete.

### Get Started

QA.tech works with any CI/CD platform that can make HTTP requests. We provide detailed guides for:

* **[GitHub Actions](/configuration/github-actions)** - Official GitHub Action with built-in blocking mode
* **[GitLab CI](/configuration/gitlab)** - GitLab CI/CD pipeline integration via API
* **[Bitrise](/configuration/bitrise)** - Mobile CI/CD: upload Android/iOS builds and run mobile test plans

**Other platforms** (Bitbucket Pipelines, Azure DevOps, CircleCI, Jenkins, and more) can integrate using the REST API directly. See the [Start Run API Reference](/api-reference/runs/start-test-run) for complete API documentation and examples.

## AI Exploratory Testing (GitHub and GitLab)

QA.tech exploratory review integrations automatically analyze pull/merge requests, identify user-facing changes, and create tests for new functionality. They run those tests against your preview deployment context and post results back to the request discussion. This helps catch issues before merge without requiring you to manually write tests for every feature.

### How It Works

1. **Analyzes request changes** - Examines code diff and identifies user-facing changes
2. **Selects relevant tests** - Finds existing tests that apply to the changes
3. **Creates missing tests** - Generates tests for untested functionality
4. **Runs tests** - Executes against PR preview deployment
5. **Posts review** - Comments on the request with test results and approval/rejection

### Ways to trigger a change review

| Trigger                                                                             | Best for                                                                                                       | Posts review to PR/MR?                                                                                                                     |
| :---------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------- | :----------------------------------------------------------------------------------------------------------------------------------------- |
| **[GitHub App](/configuration/github-app)** (automatic)                             | Default for GitHub: every PR open/sync triggers a review, with environments resolved from the App's mapping    | Yes (native PR review)                                                                                                                     |
| **[GitLab MR integration](/configuration/gitlab)** (automatic)                      | GitLab teams with native deployment signals or `@qa.tech` comments                                             | Yes (MR review note)                                                                                                                       |
| **[Change Review Action](/configuration/github-actions#change-review-action)** (CI) | Custom flows on top of the GitHub App: multiple applications per PR, label-gated triggers, deploy-job ordering | Yes (same native PR review the App posts). Creates the **QA.tech / PR Review** check even when auto-run is off.                            |
| **[Start change review chat API](/api-reference/chat/start-change-review-chat)**    | GitLab CI or any pipeline that can make HTTP requests                                                          | Yes when invoked with `mode: "pr"` and a connected GitHub/GitLab repo. Same explicit check behavior as the Change Review Action on GitHub. |

### Requirements

* Connected VCS integration: the [GitHub App](/configuration/github-app) (for GitHub triggers, including the Change Review Action) or the [GitLab integration](/configuration/gitlab) (for GitLab triggers)
* Repository selected in **Settings → Integrations** so the review agent has permission to read the PR/MR
* Preview deployment context available: native deployment signals, a manual `@qa.tech` comment with the preview URL, or `applications_config` supplied to the action/API

<Note>
  All four triggers run the same review agent and post the same native PR/MR
  review. The difference is who detects the PR and what you can customize around
  it. Use the automatic GitHub App or GitLab integration for zero-config reviews
  on every PR/MR; reach for the Change Review Action or API when you need custom
  orchestration on top of that integration (e.g. routing application short IDs
  to specific URLs per PR, or gating reviews behind a deploy job).
</Note>

## Related Documentation

* **[Test Plans](/core-concepts/test-plans)** - Create and organize test plans to run via API
* **[API Reference](/api-reference/runs/start-test-run)** - Complete API documentation with all parameters
* **[Preview Environments](/core-concepts/applications-and-environments#preview-environments)** - Testing dynamic preview deployments