AutoTest AI Engine reads your requirements from Jira and your implementation from GitHub, designs the tests that are missing, runs them on Web and Android, and reports coverage you can defend — because it counts executions, not intentions.
Free workspace, no card required · Bring your own Jira, GitHub and LLM provider
A reassuring number that is wrong is worth less than an uncomfortable number that is right.
From requirement to defect, each stage produces evidence the next stage can rely on.
The engine reads your Jira backlog and your GitHub repository, then proposes a test for each requirement it finds. Every suggestion carries the issue key it came from, so nothing is generated without a reason.
492 requirements read in a single analysisCoverage separates three states: no test, a test designed but never executed, and a requirement proven by a passing run. A test that has never run proves nothing, and the figure says so.
Three coverage states, never conflatedPlaywright drives web applications, Maestro drives Android builds. Upload an APK or point at a URL, add a YAML case or let the engine write it, then run it on our infrastructure.
Playwright · Maestro · your APK or URLFollow execution step by step with live screenshots, or request a full animated stream. Read-only by design: viewers observe, they never take control of the session.
Step-by-step evidence, retained per runA failure opens a defect that leads with user impact, states the expectation recovered from the assertion that failed, and closes with a remediation path. It escalates to Jira or GitHub in one click.
Impact → Expected behaviour → MitigationEvery artefact is linked in both directions: requirement, project, test case revision, test plan, execution, report, defect. Open any one of them and walk the chain to the others — and in Jira, the defect links back to the Story its test was designed from.
Requirement to defect, navigable end to endEvery result can be traced back to the build it ran on and the requirement it came from, because the modules are linked rather than merely coexisting.
Web, Android or both. Holds its environments, its Android releases and the accounts tests sign in with.
A case is a reusable YAML definition. A set groups cases — imported from a file, or designed from your requirements.
The structural module of a project: sets and cases arranged in categories, executed category by category.
Each run of a plan or a selection. Duplicate it to repeat a campaign on a new build, with results reset.
Every execution produces a report per category and one for the whole plan; failures raise linked defects.
No runner to install, no pipeline to rewrite, no CI minutes to budget.
Register a web URL or upload an Android build, then connect Jira and GitHub at workspace level. OAuth tokens are encrypted at rest.
The analysis walks your requirements and your source inventory, reports what is covered and what is not, and proposes the missing tests.
Select the proposals worth keeping — or all of them — and create them in the library as a named test set, ready to plan and schedule.
Run a plan, watch it live, then read the report. Failures raise defects with the evidence attached and escalate to your tracker.
Connect Jira and GitHub once, then run an analysis that answers two separate questions without mixing them: what the repository actually shipped, and what a passing test actually proves.
Authorise Jira Cloud and GitHub over OAuth, then pick the scope: up to two repositories and two Jira projects per workspace. Tokens are encrypted at rest and never returned by the API, and only an owner or admin can change a connection — everyone else reads the results.
OAuth · 2 repositories · 2 Jira projectsChoose the project, restrict the run to the Jira statuses and issue types that actually carry requirements, and pick which configured AI agent executes it. Agents whose last call failed are labelled as such, so you never send a long analysis to a broken provider.
Status, issue type and model chosen per runEvery Jira requirement is compared against GitHub commits, pull requests and source evidence. You get requirements with delivery evidence, an implementation rate, and claim accuracy — how many delivery claims actually hold up against the code. The gap lists are complete, not a truncated preview.
Delivery evidence · implementation rate · claim accuracyThe coverage tab answers a different question from the implementation tab, and never conflates the two: which requirements are verified by a passing execution, which have a test that has never run, and which have no test at all — with a traceability table behind each figure.
Verified · awaiting execution · uncoveredFor the requirements left uncovered, the analysis designs a case each. You read them, keep the ones worth keeping, and create those in the Test Library as independent reusable cases — each carrying the Jira key it was designed from.
Reviewed first, then created as reusable casesCompleted assessments are retained: reopen one from the history instead of spending another analysis. Export the sections you choose as a PDF laid out like the screen, or download the coverage matrix for your own reporting.
History reuse · sectioned PDF · coverage matrixThe platform never claims code coverage without instrumentation, and it never presents a generated test without the requirement that justified it. When the evidence is insufficient to reach a conclusion, it says so instead of guessing — a confident wrong answer costs more engineering time than an admitted unknown.
Cross-references what the backlog promised against what the repository actually ships, and reports the requirements whose delivery cannot be evidenced in the code.
Separates an application fault from an out-of-date check, and says which the evidence supports — or which evidence would settle it. A defect caused by the test’s own locator is filed as maintenance, not as a fault in your product, so the backlog stays worth reading.
Administrators choose the provider and model per capability across eleven providers, including self-hosted Ollama. Every capability runs on the agent you picked — nothing is hardcoded behind your back. If one agent errors mid-analysis, the next configured agent takes over and the report says so.
When the engine repairs a test, the previous file is kept and the change is summarised. A repair that makes the test pass by checking less — a dropped assertion or step — is flagged as exactly that, because a green run then proves nothing. One click puts the test back.
Ask any test case which scenarios it leaves uncovered, then turn a suggestion into a runnable case in the same project — tagged, and traced to the same requirement.
Running a scenario is the easy half. What decides whether a team keeps trusting its suite is the other half: the same fault filed forty times, the unstable test nobody dares delete, the page that got slower without failing, the layout that broke without breaking an assertion.
A fault hit by twenty executions is one defect with an occurrence count, not twenty tickets. It is keyed on the test, the failing step and the error, with ids, timings and run counters normalised away — so the same fault matches itself tomorrow. A fault that returns after being resolved opens a new defect, because that is news.
A test that both passes and fails across several runs is unstable, and a release gate can measure the pass rate without it. A test that always fails is not flaky — it is a finding, and it stays counted, so setting noise aside can never hide a regression.
The suites your CI already runs on every push are read back from GitHub Actions and can gate a release beside the end-to-end tests. They are read, never executed: they cost you no credits and never flatter this platform’s pass rate.
Every web run records Web Vitals per page and flags the steps that got materially slower than their own history — reported on the worst page, because an average buries the one slow screen. The first sign of a regression is usually a step that slowed down without failing.
Each screen is compared with its own baseline: a button that moved behind a banner, a table that lost its columns, a modal rendered off-screen. None of those fail an assertion, and all of them are obvious in a picture.
A plan runs nightly, every weekday, or on the schedule you set, on Central European Time — the hour you set is the hour it runs. If the platform was down at the hour, the run starts when it comes back instead of skipping the night.
Isolation, revision history and an audit trail are properties of the platform, not add-ons.
Owner, admin, member and viewer — plus custom roles you define yourself, on an editable permission matrix. Strict data isolation between workspaces.
Editing a case creates a revision; historical executions keep the definition they actually ran.
Every mutation recorded in readable language, filterable and exportable to CSV.
Test logins and OAuth tokens are encrypted at rest and never returned by the API. Each login states whether it signs into Web, Android or both, so a run never uses the wrong account.
Any report downloads as Markdown for review or as a paginated PDF for distribution.
No runner to install and no CI minutes to budget; executions are queued and isolated.
Members, executions and AI analyses each scale with the plan. When an allowance runs out, credits keep you moving instead of blocking the work.
Beyond a plan allowance, additional executions and analyses are charged in credits — never silently blocked.
Connect a project, run one analysis, and read the coverage figure you can take into a release review.