Skip to main content
Get autonomous AI-powered test coverage and reviews on every pull request. The QA.tech GitHub App analyzes code changes, creates missing tests, and posts comprehensive reviews based on test results.
Looking to manually trigger tests from CI/CD workflows? See GitHub Actions instead.

What It Does

FeatureDescription
Autonomous TestingAutomatically detects which tests to run based on PR changes
Test GenerationCreates missing tests for untested functionality
Preview Environment TestingTests against PR preview deployments
Approval/RejectionPosts reviews with pass/fail verdicts
Manual ControlNo control over which tests run (use Actions for that)
Custom WorkflowsNo YAML workflows needed or supported
1

Install GitHub App

Go to Settings → Organization → Connections and add the GitHub App connection. Follow the OAuth flow to grant access to your repositories.
2

Select Repository

Navigate to Settings → Integrations and select the repository you want to enable PR reviews for.PR reviews are enabled automatically once you select a repository.
3

Create a Pull Request

Once enabled, the agent automatically:
  1. Detects code changes when PRs are opened or updated
  2. Determines which tests are relevant
  3. Creates new tests for untested functionality
  4. Runs all relevant tests against the PR preview
  5. Posts a review with approval or decline based on results

Understanding GitHub Deployments

GitHub Deployments are GitHub’s native way of tracking when code is deployed to an environment. When your CI/CD deploys a PR, it can create a deployment record that includes the environment name and URL. Platforms with automatic GitHub deployment integration:
  • Vercel - Creates GitHub deployments automatically for every PR
  • Netlify - Auto-registers deployments when configured
  • Render, Railway, Fly.io - Most modern platforms support this
For other platforms: You’ll need to manually create GitHub deployment records in your CI/CD pipeline. Need help setting this up? Contact us at support@qa.tech.
Without GitHub deployments, QA.tech won’t know which URL to test your PR against. Environment mapping only works when your CI/CD creates these deployment records.

Environment Mapping

Map GitHub deployment environments to QA.tech Applications so tests run against the correct preview URLs. When to use:
  • You have multiple Applications (frontend, backend, etc.)
  • Your CI/CD creates GitHub deployment environments
  • You want tests to run against PR-specific URLs
How it works:
  1. Your CI/CD deploys a PR and creates a GitHub environment (e.g., “Preview” or “pr-123”)
  2. QA.tech detects the deployment
  3. Tests run using the mapped Application’s URL from that environment
Location: Settings → Integrations → GitHub App → Map Environments

How PR Reviews Work

Agent Workflow

PR opened/updated

1. Classify Changes
   → User-facing? Continue
   → Docs/infra only? Skip testing, post info comment

2. Assess Coverage
   → Find relevant existing tests
   → Identify gaps in coverage

3. Create Tests (if needed)
   → Generate tests for untested functionality
   → Configure dependencies (e.g., login tests)

4. Run Tests
   → Execute against PR preview environment
   → Wait for completion

5. Post Review
   → ✅ Approve if all tests pass
   → ❌ Decline if tests fail
   → ℹ️ Informational if untestable

Review Format

The agent posts a review with:
  • Verdict: ✅ Tests passing / ❌ Tests failing / ℹ️ Unable to verify
  • What was tested: Description of coverage in prose
  • Results summary: Patterns and themes from test outcomes
  • Test details: Automatic table with individual test results
What reviews DON’T include:
  • Code quality opinions
  • Implementation suggestions
  • References to other bot comments

Best Practices

Deploy with Vercel or Netlify These platforms automatically create GitHub deployments, making PR testing seamless. No additional configuration needed - just connect your repository and every PR gets tested automatically. Build a regression test suite As your PR tests pass, promote them to a regression test plan. This creates a growing suite of real-world tests that catch regressions automatically on future PRs. Let QA.tech test PRs first Configure PR reviews to run before requesting human code review. This catches functional issues early, so your colleagues can focus on code quality instead of manually testing features. Customize reviews with context Add domain-specific instructions to guide the AI agent’s testing approach. Go to Settings → Integrations → GitHub App and add review context. Example for payment flows:
When testing payment flows, always verify:
- Stripe test mode is active
- Receipt emails are sent
- Transaction appears in admin dashboard
Use cases:
  • Specify areas requiring extra scrutiny
  • Provide domain-specific testing guidelines
  • Add authentication/setup requirements

Troubleshooting

PR reviews aren’t posting

Check:
  • GitHub App installed and granted repository access
  • Repository integration configured in QA.tech
  • PR reviews are enabled for this repository
  • PR has user-facing changes (not docs/infra only)

Tests running against wrong URL

Solutions:
  • Map your GitHub environments to Applications (Settings → Integrations → GitHub App → Map Environments)
  • Verify your CI/CD creates GitHub deployment environments
  • Check that environment names match between GitHub and QA.tech

Agent created irrelevant tests

Solutions:
  • Add review context with specific testing guidelines
  • Update existing tests to cover the functionality better
  • The agent learns from your existing test patterns

Review says “Unable to verify through end-to-end testing”

This is expected for:
  • Documentation-only changes (.md, .txt, README)
  • Infrastructure changes (CI/CD, Docker, deployment scripts)
  • Build configuration (package.json without functional changes)
The agent can only test changes accessible through the UI.

Limitations

  • No manual test selection: Agent autonomously decides which tests to run
  • Requires preview deployments: Cannot test without accessible PR environment
  • UI-testable changes only: Backend-only microservices without UI access can’t be tested
  • No workflow customization: Unlike GitHub Actions, there’s no YAML configuration

Need Manual Control?

If you need to:
  • Choose specific test plans to run
  • Trigger tests from custom CI/CD steps
  • Control test execution timing
  • Run deep exploratory testing on-demand
See GitHub Actions for manual CI/CD integration and on-demand exploratory testing via @qatech mentions. You can use both approaches for comprehensive coverage.
I