Selenium tells you what passed. Arcus tells you what’s covered.
Sprint 24: Release Readiness
Coverage compared against what actually shipped this sprint.
COVERAGE
74%
8 of 11 modules
PASS RATE
87%
148 tests run
CONFIDENCE
92%
Priority-weighted
READINESS
81%
5 gaps flagged
COVERAGE GAPS FOUND
THE REPORTING GAP
Selenium doesn’t answer “are we covered?”
Results expire
Your CI clears artifacts on a schedule. Ask what failed six weeks ago and there’s nothing left to open.
Failure triaging is still manual
Your retry analyzer catches the obvious flake. The rest of last night’s failures cost someone a morning.
Coverage lives nowhere
Your repo holds test code. The requirements it’s meant to prove sit in Jira, and nothing joins the two.
WHAT ARCUS ADDS
The coverage layer Selenium leaves to you
You’re adding one layer, and it’s for reporting test coverage. Everything underneath it stays exactly as it is.
One report, every run
Runs land somewhere permanent on a retention window you set, with manual and automated execution in one view. Send a link instead of hunting an artifact.
Failures already sorted
Atto, Testsigma’s AI engine, reads the run before you do. Atto’s Analyzer weighs the error class, retry pattern and failure history, then labels the flaky ones.
Coverage against requirements
Two-way Jira sync brings your stories in. Each test points at what it proves, so you can see which stories in this release have nothing against them.
New tests without the queue
Atto’s Generator drafts test cases from a story, a PRD or a description, and your team approves them. This part is additive: those tests live in Arcus and grow into a second suite, on your timeline.
COMPARISON
Three ways to add AI to Selenium
GitHub Copilot, Claude Code and Codex made writing and fixing tests genuinely faster. They work one test at a time, in your editor, when you ask.
| Selenium on its own | Selenium + an AI coding assistant | Arcus by Testsigma | |
|---|---|---|---|
| Writing a test | You hand-code it | Drafted from a prompt, in your repo | Drafted from a Jira story or PRD, by anyone on the team |
| Fixing a broken locator | You edit the page object | Ask it, one test at a time | Proposed on the run, you approve |
| Triaging a full nightly run | Manual | Manual, or paste the logs in per failure | Every failure classified: bug, flake or environment |
| Run history and trends | Until your artifacts expire | No | Kept on your terms |
| Coverage against requirements | No | No | Mapped through Jira |
| Manual and exploratory tests | Nowhere | Nowhere | Same list as the automated ones |
What’s left is everything that has to stay true across the whole suite, over time, without anyone asking for it.
NO MIGRATION
Your Selenium suite
doesn’t move
Turn Testsigma off and your suite runs the way it always did.
What you’d lose is the record.
YOUR PIPELINE TODAY
Specs in your repo
tests/*.spec.js · reviewed in PRs
Runs in your CI
JenkinsGitHub ActionsAzure DevOpsTestsigma reads the runs
Coverage mapped to modules
Run history & flake trends
Release readiness evidence
COVERAGE EXPLAINED
Code coverage and test coverage are different
Selenium drives a browser as well as anything you’d pick instead. Run history, manual tests and requirements were never in its scope.
Code coverage
Which lines of your application ran. JaCoCo, Istanbul, Coverage.py. Testsigma doesn’t measure it, and there’s no reason to replace those tools.
Test coverage
Which requirements your tests prove.
A test that loads your checkout page and checks the title lights up plenty of code coverage while proving nothing about whether a customer can pay you. Execution isn’t assertion.
When someone asks whether you’re covered for this release, they mean requirements. Code coverage knows about lines.
Frequently Asked Questions
See what your suite covers