
Code reviews usually can't catch UI bugs or broken user flows—so issues slip through even when the code looks correct. We added automatic exploratory testing that runs when preview deployments are ready, catching issues before the pull request is merged in.
How It Works
To enable automatic PR testing, install the GitHub App, configure your repository, set up preview deployments, and enable auto-run in your GitHub integration settings. For manual triggers on specific PRs, comment @qa.tech in the PR—perfect for testing draft PRs or when you want immediate feedback.
Checking test health used to require navigating multiple pages and piecing together information. Now we added key metrics directly on your project home page and created a dedicated Insights page for deeper analytics, making it easy to spot problems and trends at a glance.
How It Works
The redesigned dashboard is now your default project view, with the Insights page available via navigation or the "More Insights" link in the metrics widget. Quick health checks happen on the dashboard; deep analysis happens in Insights.
Want to test a new feature or check if something works? Instead of writing test cases manually, just ask the chat assistant - "Explore the checkout flow" or "Test the new search feature" - and watch it creating test cases for you, like an everything-knowing colleague who is on top of everything your app can do, your testing suite and QA strategy.
How It Works
Start exploratory testing from the chat assistant by asking it to explore your application or specific features, and receive comprehensive exploration reports with suggested tests and discovered issues.
Dev and staging environments are commonly protected behind corporate firewalls, making them inaccessible to external testing tools. Now our AI agents can access even those protected environments through SSH tunnel proxies using SSH tunnel proxy.
How It Works
~/.ssh/authorized_keys file.
Configure SSH tunnel proxies in
Project Settings → Network: enable the toggle, generate SSH keys, add the public key to your server
(e.g., your-server.example.com), enter SSH host and user
credentials, test the connection, and save. Your internal applications are now
accessible for testing without exposing them to the public internet.
Manually creating tests through the UI doesn't scale for teams that want to automate test generation from their own tools and workflows—so we built a RESTful API that lets you create tests programmatically with project-specific authentication.
How It Works
/api/projects/{projectUuid}/test-cases with full control over
test names, goals, dependencies, and configurations. Required fields:
name, goal, and
applicationId—everything else is optional.
Authorization: Bearer {your-api-token}.
Create tests via API from your CI/CD pipelines, ticketing systems, or custom scripts. Get your API token from Project Settings → Integrations → API Integration, then use it to programmatically create test cases with full control over names, goals, dependencies, and configurations.
Without visibility into which projects consume the most testing resources, it's hard to optimize costs or plan budgets effectively. Now you can see test case executions broken down by project and time period, making it easy to identify high-cost areas and optimize test efficiency.
How It Works
View usage metrics in Organization Settings → Subscription → Billing Usage. Switch between daily and monthly views, filter by project, and export reports to track testing resource consumption across your organization.
Debugging API issues with limited visibility into request and response data wastes time guessing what went wrong—so we added full network inspection to the test tracer.
How It Works
Find network inspection in your test result tracer, where you can expand any network request to see complete request/response details, headers, and timing data for thorough debugging.
Manually updating URLs and configurations when switching between staging and production environments slows down testing workflows—so we added support for multiple environments per application.
How It Works
Configure environments in your project settings under Applications, where you can add staging, production, and custom environments with their own URLs and configurations for seamless testing across your deployment pipeline.
Managing separate QA.tech projects for each application creates overhead and fragments your testing workflow—so we added support for multiple applications within a single project.
How It Works
Configure multiple applications in your project settings under Applications, where you can add URLs, set base paths, and manage configurations for each application independently.
Catching issues after code is merged to production is too late—so we added automatic testing for preview environments on pull requests.
How It Works
Configure preview environments in your project settings by defining URL patterns and lifecycle rules, then integrate with your GitHub workflow to enable automatic testing on every pull request.