MCP tools for failing tests, PR list redesign, and check-run controls

Highlight
Featured this release
Investigate failing tests through the API and MCP tools
Three new tools let AI coding agents fully investigate any failing test – detail, step-by-step trace, and pass/fail history – without touching the dashboard.
get_run_test_case returns per-test detail for any result ID from a qa.tech/results/test/ URL: goal, success criteria, evaluator reasoning, error classification, durations, and a durable deep link. get_run_test_case_trace gives a paginated step-by-step agent trace – reasoning, tool calls, observations, and screenshots – so large test suites don't overflow context. get_test_case_history shows the recent pass/fail trend and durations across runs, making it straightforward to tell a flake from a regression.

All three are available as MCP tools and via the REST API under /v1/run-test-case. Pasting a /results/test/ URL directly into the chat assistant now resolves to the correct run and test, with a cross-project hint shown when the URL points to a project other than the one currently in scope.
# Direct link
Update 02 of 05
Automatic reruns now reach large failing runs
Flaky-test analysis and automatic reruns now apply to runs of any size.
Every failing run – no matter how many tests failed – now flows through the same batched flaky-test classifier that smaller runs use. Per-test rerun budgets and pass limits still bound how many reruns fire, so the analysis stays bounded on very large suites too.
# Direct link
Update 03 of 05
Inconclusive PR reviews now resolve as a passing GitHub check
When QA.tech can't complete a PR review, the GitHub Check Run now shows green instead of grey.
If QA.tech reviewed your PR but couldn't reach a verdict – because the diff was outside the configured scope or the PR couldn't be assessed – the resulting GitHub Check Run previously appeared as "skipped" (grey dash). It now resolves as "success" (green tick), so branches protected by required-status checks or auto-merge rules continue unblocked. The "Review inconclusive" indicator on the QA.tech dashboard still reflects the actual verdict; only the GitHub merge gate changes.
# Direct link
Update 04 of 05
Pull Requests page redesigned as a table
The Pull Requests page now displays as a clean table and defaults to showing open PRs when any exist.
The PR list has been replaced with a table layout that matches the Results page – white background, aligned headers, and compact review-count badges. When you open Pull Requests for a project, it now defaults to "Open" if there are open PRs, so you land on what's active rather than the full history. If there are no open PRs, it falls back to "All". The repository column and filter picker are removed; the search box still finds PRs by repo name.
# Direct link
Update 05 of 05
Skip the GitHub check run for PR reviews
A new per-repository toggle lets you run QA.tech PR reviews without posting a GitHub check run.
Under Settings → Integrations → GitHub App, each repository's "Pull Request Testing" section now has a "Register a commit check" switch, on by default. Turn it off and QA.tech still runs the review, posts its sticky comment, and records the result in the dashboard – but it won't create or update the QA.tech / PR Review check in GitHub. Useful when you want automated reviews without affecting branch protection or merge-gating rules. The "Block merges when a review fails" option is hidden when the toggle is off, since that workflow requires a check.
# Direct link

Investigate failing tests through the API and MCP tools

Automatic reruns now reach large failing runs

Inconclusive PR reviews now resolve as a passing GitHub check

Pull Requests page redesigned as a table

Skip the GitHub check run for PR reviews

Your team moves fast. Can your testing keep up?