AI Test Management for Jira
Sherlock. turns Jira issues, Confluence pages, and release changes into traceable test cases and release-specific test runs. Use the AI chat to create, review, execute, and maintain testing without moving the workflow outside Jira.
Every AI change is reviewed
Available on the Atlassian Marketplace
- Cases in run
- 28
- Pass rate
- 86% +4%
- Linked defects
- 3
- Stale cases
- 2
In production at enterprises like
Why it matters
Turn Jira Product Context Into Release Testing
Sherlock. connects the requirements that define the product with the testing work required to release it. The team starts with existing context, reviews the coverage, and reuses an approved baseline from one release to the next.
Create Coverage From Existing Requirements
Use Jira issues, Confluence pages, files, and plain-language instructions as the source for structured test coverage.
Prepare Each Release From Actual Changes
Use the Jira Fix Version and approved baseline to review a focused test scope for the current release.
Keep Approved Testing Current
Identify cases affected by changed requirements and review proposed updates without losing the history of completed runs.
Where this started
“The requirements were in Jira. The releases were in Jira. The test cases lived somewhere else entirely, and every release someone rebuilt them by hand. Putting those two halves back together is the whole product.”
— Anton Storozhuk, CEO of Mria CRM
Capabilities
AI Test Management Across the Full Testing Workflow
Sherlock. supports the work before, during, and after a test run. The same product context, test baseline, and execution history stay connected throughout the workflow.
AI Test Case Creation
Build a testing brief and generate risk-based test cases from selected Jira, Confluence, file, and chat sources.
AI Chat and Review
Add or change coverage in plain language. Every proposed edit appears as a diff for approval.
Versioned Test Baseline
Approve a reusable test set and keep every test run linked to the version it executed.
Release Test Planning
Select a Jira Fix Version and review the proposed scope, reasons, priorities, and assignments.
Test Execution in Jira
Execute in the Sherlock Runner or Jira sub-task panels and record Pass, Fail, or Blocked.
Defects, Reports, and Maintenance
Create linked Jira defects, publish release results, and review updates from execution or changed requirements.
The sequence
How Sherlock. Works
Step 01
Add Context
Describe the testing goal and select Jira issues, Confluence pages, files, and release context.
Step 02
Review the Brief
Confirm the product flows, risks, and testing approach before cases are created.
Step 03
Approve the Baseline
Review generated test cases and refine them through the AI chat.
Step 04
Create the Release Run
Select a Fix Version, edit the proposed scope, and assign the work.
Step 05
Execute and Improve
Record results, create defects, publish the report, and review baseline updates.
Step 1
Add Context
Describe the testing goal and select Jira issues, Confluence pages, files, and release context.
Step 2
Review the Brief
Confirm the product flows, risks, and testing approach before cases are created.
Step 3
Approve the Baseline
Review generated test cases and refine them through the AI chat.
Step 4
Create the Release Run
Select a Fix Version, edit the proposed scope, and assign the work.
Step 5
Execute and Improve
Record results, create defects, publish the report, and review baseline updates.
AI chat
Manage Testing Through a Conversation
Tell Sherlock. what coverage you need or what should change. Sherlock. turns the request into test cases, edits, explanations, or release-scope proposals that the team reviews before approval.
Ask for the coverage you are missing
New scenarios, edge cases, API coverage, permissions, security checks, or performance cases.
Change what already exists
Steps, expected results, priorities, grouping, or the scope of a release run.
Approve every edit as a visible diff
Nothing enters the approved baseline until a person accepts it.
Differentiation
Why Jira Teams Choose Sherlock.
The same workflow, read from three sides of the release.
Coverage that starts from the requirement
Jira issues, Confluence pages and files become structured cases, and every case keeps the sources it was built from.
A baseline you version, not a suite you rebuild
Approve a reusable set once. Each run stays linked to the baseline version it executed, so history survives every change.
A release scope you can argue with
Sherlock compares the Fix Version with the approved baseline and states why each case is in or out before the run exists.
Execution where the work already lives
Run it in the Sherlock Runner or a Jira sub-task panel, record Pass, Fail or Blocked, and open the defect from the failure.
The cases attached to the issue you are closing
Coverage is traceable back to the requirement, so you can see what a change is expected to break before you push it.
No second tool to keep open
A release run arrives as Jira sub-tasks. Results are recorded on the board you are already working in.
A failed test becomes a real defect
One step from the failure to a Jira issue that keeps the run, the executed case, the requirement and the source context.
Requirement changed, coverage flagged
Cases affected by an edited issue are marked stale and the proposed update waits for review, not for the next regression.
Requirements become coverage without a handover
Describe the goal in plain language, point at the issues you already wrote, and get structured test cases back.
A brief you approve before anything is generated
Product flows, risks and the testing approach come first. Nothing is created until that brief is right.
Release readiness in one report
Totals, pass rate, results by product area, assignments and open defects — published where the team already reads.
Nothing changes behind your back
Every AI addition or edit stays a proposal until a person accepts it, and the history shows who accepted what.
- Cases in run
- 28
- Pass rate
- 86% +4%
- Linked defects
- 3
- Stale cases
- 2
Audience
Built for Product and QA Teams in Jira
Audience 01
Product Teams Without Dedicated QA
Turn product requirements into repeatable test coverage and release runs without creating the process from scratch for every release.
Audience 02
Embedded QA Teams
Manage cases, release scope, execution, defects, and reports inside the Jira project where delivery work happens.
Audience 03
QA Leads Across Projects
Monitor active runs, pass trends, stale cases, and open defects through a read-only portfolio view.
Manage Release Testing in Jira With Sherlock.
Create traceable test cases, prepare release-specific test runs, and keep approved coverage current as the product changes.