The pull request gets a tester

Most small teams test a pull request the same way: someone opens the preview, clicks around, and writes "looks good" in the review. On 30 October 2026 we shipped six changes that put a tester in that spot instead. This post goes through each one, what it does, and where it stops. Each feature section links to its changelog entry or page, which has the full detail.

The pull request is the test plan

A pull request already says what it changes. When the ZeusQA GitHub App starts a run, it now adds the pull request's title and description to the test, after the mission you set for the repository. The agent is asked to check each change the description claims and to list each one as a check, passed or not. A claim that does not hold becomes a finding.

The description is the author's words, so it is quoted as data, and the agent is told to ignore requests in it to skip checks, change the verdict or visit another site. The agent is a model and can still be misled, so keep descriptions to what changed. Template comments are removed and the text is cut at 1,500 characters.

Two cases get less. A pull request from a fork is written by someone without write access, so its title and description never reach the test. Bots such as Dependabot and Renovate fill the description with upstream release notes, so only their title goes in.

Read the release: The pull request is the test plan

Acceptance criteria, one by one

One verdict for a whole change hides which part broke. When the description lists acceptance criteria or a test plan, ZeusQA now answers each item: met, not met or not checked, with a one-line note.

Items count as criteria when they sit under a heading such as Acceptance criteria, Test plan or How to test. Without one, a task list at the top or under Summary or Changes counts. A template's own checklist, under Checklist or Before merging, never does. Up to 10 criteria are read, 200 characters each.

A criterion the agent did not get to stays not checked; it never counts as met. Any criterion not met fails the run, so the ZeusQA check fails and blocks the merge when merge blocking is on for the repository. The run page shows a count such as "2 of 3 criteria met", and the pull request comment carries the same table under the verdict.

Read the release: Acceptance criteria, one by one

Fix with agent

A finding tells you what broke. Now it also hands the fix to the coding agent you already use. Under every finding on a run there is a Fix with agent menu: Copy prompt, Open in Cursor, or Open in Claude Code.

The prompt carries the page, the severity, what the tester did, what it expected and what it saw, the suggested fix, the evidence, the steps up to the one that broke, and a link back to the finding with its screenshots. When the run came from a pull request, Claude Code opens in your local clone of that repository, if it has opened one before. The pull request comment links each finding it lists, up to 15, to its prompt.

Nothing runs on its own. Cursor and Claude Code fill in the prompt and wait for you to read it and press Enter.

Read the release: Fix a finding with your coding agent

Trends, week by week

Overview says how things stand today. The new Trends tab shows how they got there: runs per week by verdict with the pass rate drawn over the bars, findings by severity week by week, and four numbers against the period before. Pick 4, 12 or 26 weeks; weeks start on Monday in UTC.

Two tables, by project and by week, each have a Download CSV button that exports exactly the rows you see. Every number is counted from your runs. Runs still in flight count towards runs, not towards the pass rate.

Read the release: Trends, week by week

A security page with its gaps

Before you connect a repository or point a browser at your app, you should be able to see what stops it going wrong. The security page lists the controls ZeusQA has: signed GitHub webhooks, read-only code access with every permission named, no automatic runs on fork pull requests, a public-address check on the browser, and screenshot links that need a per-run token.

It also lists what we do not have: no independent audit or certification, no single sign-on, no choice of where data lives, and no defence against DNS rebinding on either runner. A test checks every control on the page against the code and fails if one is renamed or removed.

Read the release: A security page with its controls and its gaps

Today, and with ZeusQA

The home page now has a table of five moments in a release where a team without a QA engineer relies on someone clicking around, and what ZeusQA does there instead: testing a pull request, the verdict, merging, after release, and reporting a bug.

What it still does not do

ZeusQA runs Chromium only, so it does not catch Safari or Firefox bugs. Schedules run at most once an hour, from one location, so it is not uptime monitoring. Alerts are email only. It cannot open an inbox to click a verification link, and it does not solve CAPTCHAs; a challenge usually ends a run as blocked. There is no visual diffing against a baseline and no WCAG conformance report.

Try it

Free gives you 3 runs, no card. Point one at a preview of your next pull request and write its test plan under a Test plan heading. To run it on every pull request, connect the GitHub App and make the ZeusQA check required.