Code change
Can run on a triggerPoint Bridge at a pull request and it reads the diff against your existing cases. Attach it to a repository and every PR does it by itself.
TestBridge
Own your test suite without moving house.
Bridge connects to the test management system you already run: an API key, no migration, no import. It reads your suite, your code and the knowledge files you give it, then writes test cases back into the same platform your team opens every morning.
Qase · TestRail · XrayGitHub · GitLabYour case library never moves
Two runners
Start from a code change, or just ask.
Both runners read the same three things: your suite, your repositories, your knowledge files. Both end in proposals against your TMS project. What differs is what starts them.
Prompt
Always manualSay what should change in your own words. A prompt run is always started by a person and always reviewed by one.
Not finished with it? Steer the same run: a follow-up appends proposals, or revises the one case you pinned.
Triggers, per repository
Every repository gets its own contract.
Attach as many repositories as you like to one TMS project. Each one decides on its own what a pull request starts: nothing at all, the analysis only, or the analysis and the proposals that follow it.
| Repository | On a pull request | Who finishes it | Write permission |
|---|---|---|---|
| acme/payments-checkout | Analysis, then Manager | Human in the loop | New cases |
| acme/internal-tools | Analysis, then Manager | Autonomous | New and updates |
| acme/marketing-site | Analysis only | Human in the loop | Not applicable |
| acme/legacy-billing | Nothing, manual only | You start it | Not applicable |
Human in the loop
DefaultNothing reaches your platform until a person says so. Every proposal is read, edited or rejected first.
Autonomous
Full ownerBridge builds, reviews and syncs on its own, so your suite stays current with no one in the middle. You still set how far its pen goes: new cases, or new and updates.
Whole-suite runs
Audit and Gap: twice a year, not twice a day.
The two runners keep up with change. These two look at the whole suite at once, worth doing the week you connect Bridge, then around a release. One of each can be open per TMS project at a time.
Audit
How efficient your suite actually is: cases that duplicate each other, cases that could merge, and cases written so vaguely they prove nothing. It never adds a case.
Gap
What your suite does not cover. Gap reads your cases against your product knowledge and your code, then proposes the cases that are missing. It needs an approved product spec to start, and a connected repository makes it sharper.
What makes it yours
It writes like your team, because you told it how.
Hand Bridge your testing guidelines, your domain glossary, your product specs. They are inlined into every run, so proposals arrive in your format and your vocabulary instead of a generic one. Scope a file to the whole org, one product, or a single test project. The narrowest one wins.
Together with the repositories you attach, that is the whole difference between a suggestion and a test case your reviewers approve without rewriting.
The gate
Bridge proposes. You decide what ships.
Every run ends in staged proposals, never a direct write: new cases, updates, merges, moves, deprecations. Approve them, edit them first, or reject them. Only then does anything land in your platform, under your own case numbering, in the sections you already use.
Set a repository to autonomous and Bridge takes that step over for new cases, and for updates as well if the write permission allows it. Merges, moves and deprecations still wait for a person. That is a choice you make per repository, not a mode the product forces on you.
Keep the TMS. Add the operator.
Connect a project with an API key and run your first audit the same afternoon.