Hi Community — I’m Robert at JSoft. I work on Testing tool, a Jira Cloud test-management product. The purpose is to reduce testing effort and keep that work visible to QA and Dev on the Jira issue — not in a TMS only one role opens. It is in beta, and we are looking for feedback. This post is about one workflow: Ask Rovo to draft TestCases. Testing tool is built as a Forge app and is designed to stay Runs on Atlassian eligible.
I am not pitching a separate AI website. The agent lives in Jira. In Rovo Chat the picker may still show Testing Agent. In project navigation the hub is Testing tool. Same product. Compute, storage, and Rovo inference stay on Atlassian — you do not export TestCases to a vendor TMS for this flow.
The problem
A lot of testing effort is not execution — it is rewrite, then invisibility. Someone turns a story into steps in a spreadsheet or a TMS that is not Jira. QA owns that tool. Developers never open it. Coverage on the story goes stale.
Rovo is already in Jira, where QA and Dev already work. The missing piece is an agent that knows TestCase as a work type — not a generic “write me some tests” chat that invents issue keys — so the first draft costs less and stays visible next to the requirement.
What “Ask Rovo” actually opens
On a site with Rovo enabled and Testing tool installed:
- Open a Jira software project and make it TMS-ready (Requirement, TestCase, TestExecution, Bug).
- Open Testing tool from project navigation, or stay on a story.
- Use one of these:
- Ask Rovo on Requirements or Test Design
- Ask Testing tool on the Cycle traceability panel of a story or epic
- Fill steps with Rovo on a Manual TestCase
- Rovo Chat → pick Testing Agent (this is Testing tool)
- If chat has no issue context (opened from the top nav), give a project or issue key. The agent will not guess.
If Rovo is off on the site, those buttons stay hidden on purpose. Design and execution still work without AI.
What you should see in chat
Ask something like:
- Generate TestCase proposals for this issue
- Fill missing steps for this TestCase
Testing Agent should fetch the issue first, then return a proposal set. Each item has a title, optional preconditions, steps (action / data / expected result), and a recommended action:
- create — no matching TestCase yet
- update — fill or replace design on an existing Manual TestCase
- delete — related TestCase is obsolete (hard-delete of the Jira issue, only after confirm, and only if you have Delete issues)
- breakdown — requirement is too large; split into smaller drafts (it will not bulk-create the set)
- needs-context — not enough information; it asks what to paste instead of inventing steps
Nothing is written until you confirm that item in the conversation. One confirmed write at a time in the current version.
What it will not do
This is the part I want to be explicit about, because AI test-case demos often over-promise.
- It will not mark TestExecution steps passed or failed.
- It will not create or delete until you confirm.
- It will not invent Jira keys or steps that were not in the fetched issue, linked issues, or text you pasted.
- It will not read a Confluence page as the requirement in this version. Paste the text, or point it at a Jira issue.
- It does not grant extra AI quota. Each request uses your site’s Rovo credits (on the order of 10 credits per request). Longer chats cost more requests.
The agent also respects your Jira permissions: Browse to read, Create issues to create a TestCase, Edit issues to fill steps, Delete issues to delete. Confirm does not override Jira.
Why this belongs next to Rovo, not instead of it
Default Rovo is a general assistant. Testing tool’s agent is the Forge agent that can call the product’s actions (load work context, then create/update/delete after confirm). If you leave default Rovo selected, you may get advice — you will not get the TestCase write path.
Runs on Atlassian
Testing tool is a Runs on Atlassian Forge app. That is a product constraint, not a slogan.
- AI inference uses the Rovo platform LLM on the customer’s Atlassian site (your Rovo credits). There is no third-party model API for this agent.
- Compute is Forge functions for the agent’s actions.
- Storage is Forge SQL plus Jira issues and issue properties. Core test design does not leave Atlassian for a JSoft database.
- No remotes on the eligible version: no Forge Remote, no external fetch for the agent, static ingest web trigger so eligibility is kept.
Ask Rovo here does not mean “send the story to our cloud and get cases back.” Fetch, propose, and (after you confirm) write all happen in Jira Cloud under your permissions.
Admins can confirm the Marketplace Runs on Atlassian badge on the listing for the version you install. We keep eligibility on every listed version (forge eligibility).
A five-minute walkthrough
- Open a story with a real acceptance-criteria section.
- On the Cycle traceability panel, choose Ask Testing tool (or Chat → Testing Agent).
- Say: “Generate TestCase proposals for this issue.”
- Review the proposal set. If a case already exists, you should see update, not a duplicate create.
- Confirm one create. Open the new TestCase issue. The Test design panel should show the steps.
- If steps are thin, use Fill steps with Rovo on that Manual TestCase, then confirm the update.
If you get a needs-context reply, that is success — the agent refused to hallucinate. Paste the missing rule and try again.
Who this is for
QA who want less rewrite and still own design. Developers who should see TestCases, coverage, and CI results on the story without leaving Jira. PMs who want the same picture on the work item.
Automated results from CI are a different highlight (ingest from Jest, Vitest, Playwright, and so on). That path also aims to cut effort and make status visible to both roles. This article is only the Rovo draft path.
This is a beta — we want your feedback
Testing tool is not a finished GA product. If you install it, please tell us what was useful and what got in the way. Reply on this thread (I will answer) or leave a Marketplace review.
Useful feedback looks like:
- Did Ask Rovo / Testing Agent open the right agent, or did you land on default Rovo?
- Were the proposed steps grounded in the story, or did they invent detail?
- Did confirm-before-write feel safe, or did something persist when you did not expect it?
- Did QA and Dev both see the TestCase and coverage on the Jira issue, or did it stay hidden in chat?
- What was missing before this would actually reduce your testing effort (issue types, permissions, CI, Excel, coverage)?
Please do not paste secrets, ingest tokens, or customer PII in comments.
Marketplace
Testing tool for Jira Cloud is in beta. Purpose: reduce testing effort and keep tests visible to QA and Dev. Search Testing tool on the Atlassian Marketplace. Look for the Runs on Atlassian badge on the listing. After install, open Testing tool in a project, complete TMS-ready issue types, then use Ask Rovo / Testing Agent.
If you try this, say so in the comments — what worked, what did not, what you expected. I will answer.
— Robert, JSoft
