Tests you can trust, because someone checked.
Agents write tests faster than anyone can read them. Verified tests let a person review what a test actually did, from the evidence of its run, and vouch for it. When an agent changes the test, TestChimp marks it stale and asks for another look.
14 days, no credit card. Works with any coding agent.

Problem
Thousands of tests.Nobody has read them.
When agents write the tests, nobody is accountable for them. A test can pass while asserting the wrong thing, skip the step that matters, or be quietly rewritten until it goes green. Reviewing the test’s code doesn’t show what it did in the browser, and nobody reviews every change anyway.
Accountability, one test at a time.
Verification is a person’s sign-off on a specific test, based on what it did, that holds only while the test stays the same.
Evidence
See what the test did.
Every run keeps the steps with screenshots, and failing runs keep the full trace, so review starts from behaviour, not code.
Captured on every run
Verify
A person vouches for it.
A reviewer checks the test does what its scenario intends and marks it verified. The badge names who verified it.
Reviewer sign-off
Stale on change
Re-verify when it changes.
TestChimp watches verified tests. When one changes, the verification goes stale and the verifier is asked to look again.
Watched by TestChimp
Review what the test did, not just its code.
A test file says what should happen. The run shows what did. Verification is based on the run.
Evidence from every run
Every step is captured with a screenshot, and failing runs keep a full trace. A reviewer watches the test do its job, checks that the assertions match the scenario, and verifies it from the same screen.

Verification that stays honest.
A badge is only worth something if it stops meaning “verified” the moment the test changes.
A person vouches for each test
The Verified badge stays with the test and names who verified it. Release views count verified tests, so you can see how much of what you ship a person has vouched for.

Stale the moment it changes
When an agent or a person edits a verified test, the verification goes stale and the original verifier is asked to re-verify. A badge never outlives the test it was given to.
- Stale tests show in the release view.
- The original verifier is asked first.
- Pair it with a policy, such as every payment scenario needing a verified test.

How agent-written tests usually get trusted.
| Unreviewed agent tests | Self-healing tests | Code review of test diffs | Verified tests | |
|---|---|---|---|---|
| Fails when the product breaks, instead of adapting to it | No | No | Partly | Yes |
| Reviewer sees what the test did in the browser | No | No | No | Yes |
| A named person accountable for each test | No | No | Partly | Yes |
| Notices when a reviewed test changes | No | Changes itself | That PR only | Yes |
| Keeps up with agent-written suites | Yes | Yes | No | Yes |
| Verification status per release | No | No | No | Yes |
Self-healing tests repair themselves when the UI changes. When the change is a bug, healing can route the test around it: the product breaks and the test adapts to the broken product.
Questions about verified tests.
What does verifying a test mean?
What makes a verification stale?
Why not use self-healing tests?
Do I have to verify every test?
Where do I see verification status?

Let agents write the tests. Get people to vouch for them.
Every test keeps its evidence. The ones that matter keep a name.
14 days, no credit card.