Skip to main content
A change review reads the pull request or merge request, selects existing tests that cover the user-facing changes, creates tests for what is missing, runs them, and posts the result on the request.

​
When the tests run

Pick the timing that matches where the new code is reachable. These are two options, not two steps.

Before merge

Preview environment. The review runs against that request’s own deployment, before the code reaches your main branch.

After merge

No preview environment. Run the review after the merge lands and the deploy finishes. The agent tests the merged diff against staging or production.

​
On a preview environment, before merge

QA.tech gets the target from one of these:

​
After merge, when you have no preview environment

Run the review after the merge lands and the deploy finishes. The agent reads the merged diff and tests against staging or production. The result is posted on the merged request.
A post-merge change review tests the merged code. The post-merge agent is a later step on GitHub: it can promote tests from that review into your regression suite. It does not replace the review.

​
How it works in practice

Here’s what happens when you open a PR that changes your checkout flow: 1. Automatic Detection
2. Change Classification
3. Coverage Assessment
4. Test Generation
5. Execution & Review
This entire workflow runs autonomously - no human intervention required.

​
How a review works

This applies to every CI. The CI guides below cover only how the review starts.

​
What a review does

​
How a review runs

The agent posts reviews with:
  • Verdict: Pass/fail/unable to verify
  • What was tested: Description of coverage
  • Results summary: Patterns and themes
  • Test details: Table with individual test results
Reviews focus on test results only - no code quality opinions, implementation suggestions, or references to other bot comments.

​
Test Selection and Creation

​
How Tests Are Selected

The agent uses AI to semantically match PR changes to test goals - not keyword matching. Example: PR changes checkout payment flow
Selection mechanics:
  • Runs ALL tests it determines are relevant (no arbitrary limits)
  • Only considers tests with status='enabled'
  • More intelligent than running all tests every time

​
When Tests Are Created

Tests are created only when coverage gaps exist, such as when you’re developing a new feature not yet covered by your testing suite.
Writing acceptance criteria? Include test requirements in your Linear/Jira ticket or PR description. The agent reads this context and uses it to create more accurate tests for your new feature. See Recommended Workflow for New Features for details.
Example: PR adds Apple Pay to checkout
Created tests:
  • Stay in your suite labeled ‘ephemeral’
  • Available for future PRs
  • Manage in Settings → Test Cases (filter by ‘ephemeral’ to find them)
Example lifecycle:
The agent prevents duplicates by reading all existing tests first and using semantic deduplication. If one slips through, simply delete it in the UI. Self-limiting: As your test suite grows, fewer tests are created automatically - better coverage means fewer gaps. Most PRs (bug fixes, refactors) create zero new tests.
Mobile and Responsive Testing: When a PR mentions mobile, tablet, or responsive design changes, the AI agent may automatically test with appropriate device presets. The agent detects keywords like “mobile”, “tablet”, “responsive”, or “Safari mobile” and can override device presets when creating or running tests. See Device Presets for configuring device settings.

​
Common questions

Will generated tests clutter my test suite? No. The agent only creates tests for coverage gaps. Most bug fixes and refactors create none, and a large feature usually adds a few focused tests. Better coverage means fewer gaps, so fewer tests are generated over time. The agent created tests I don’t need. What can I do?
  • Add review context with specific guidelines in the integration settings.
  • Update existing tests so they cover the functionality.
  • The agent follows the patterns in your existing tests.
What happens when the organization is out of credits? QA.tech posts one comment on the request with an upgrade link. No tests run, and no review is posted.

​
Pick your CI

Each guide is only the pull request setup. The same CI names under Regression Testing run a test plan instead.

GitHub

App, Change Review Action, after merge, or mobile.

GitLab

Merge request reviews on deploy, comment, CI, or API.

Bitrise

Review the mobile build Bitrise produced.

Envoyer

Not supported. See what to use instead.

API

Bitbucket, Jenkins, CircleCI, or any HTTP client.

Writing PR descriptions

Give the review the context it needs.

​
Give the review enough context

The agent reads the request description, the diff, and linked tickets. A description that states what changed, why, and what to test produces a more relevant review. See Writing PR descriptions.