Review a locator change
like a code change.
A selector edit changes what your tests assert, so it deserves the same review a pull request gets. Branch it, diff it, approve it — with the quality score and failure history sitting next to the change.
One repo, reviewed like code.
Capture flows straight in.
Every locator captured with the extension lands in Studio automatically — graded, named, saved to a branch. One dedicated repo for locators, not a selector buried in a page object file three folders deep.
Review it like a pull request.
Merge requests run a three-way merge and show a diff before anything lands on main. If the same locator changed on two branches, it’s flagged as a conflict to resolve — not silently overwritten.
See what’s actually failing.
Every resolution — resolved, failed, or used — is recorded. Studio surfaces the locators failing most across a project, so you know where to look instead of scrolling a static list.
A repo for locators, not one buried in your POM.
Every locator is a versioned object, not a row.
Locators are stored the same way git stores code — commits, trees, and content-addressed objects. Nothing gets mutated in place; a change is a new commit, so there’s always a full history to look back through.
Role-based access for the whole team.
Every org member has a role — owner, admin, member, or viewer — each with a different level of control over projects, merges, and settings. Nobody has to share one login to capture and review locators.
Metrics on every resolution, not just captures.
Resolved, failed, and used events are recorded per locator and rolled up per page, so failure rate reflects what actually happened in test runs — not how the locator looked when it was captured. Each one carries a trend — degrading, stable, or improving — over a rolling window, so a locator sliding toward flaky shows up before it goes red.
Common questions.
Can I sign up today?
Not yet — Studio is invite-only while it rolls out in phases. The browser extension is free and live now, and locators you capture with it are what Studio organises later. Join the waitlist to get an invite.
Why version locators like code instead of just storing them?
Because a locator change is a change to test behaviour, and it deserves the same review a code change gets. Branching lets you update selectors for an unreleased UI without breaking the suite running against production, and merge requests mean a risky selector edit is seen by someone before it lands.
What happens when two people edit the same locator?
You get a merge conflict, surfaced the way a code conflict is: both versions side by side with their quality scores and history, so you resolve it on evidence rather than by whoever pushed last. Committed locator objects are never mutated in place — resolving writes a new commit.
How is the failure rate calculated?
From resolution events reported by real test runs, not from how the locator looked when captured. Resolved, failed, and used events roll up per page over a rolling window, which is why a locator can score well and still show as degrading.
Do I need Studio to use the extension or the SDK?
No. The extension works standalone with nothing uploaded anywhere, and the SDK can resolve from a local locator file. Studio is for teams who want shared history, review, and metrics across a suite.
Who can see and change what?
Access is role-based across an organisation — owner, admin, member, and viewer — so reviewers can approve locator changes without everyone holding write access to the whole repo.