Test cases

In the test case stage, AI drafts structured test cases from the product owner approved story, the analyst reviews each one, and only approved, unchanged cases are published to Jira or Xray. Every case is linked to the acceptance criteria it covers, and the platform shows which criteria are still uncovered.

When generation can start (Demonstrated)

Test case generation is available only after the requirement review gate is passed. Specifically:

• The story has a current product owner approval. If the text changed after approval, generation is blocked until the product owner approves again.
• The analyst role starts generation from the requirement detail page.

The model receives the approved story text, the acceptance criteria, the product owner’s answers to the review questions, and the test data the application provides for testing. All of this is passed as untrusted data inside labelled blocks.

For STORY-142 Order cancellation, the input would be the corrected description, AC1 to AC4, the product owner’s answer that the cancellation window is 12 hours, and test accounts with orders in different states: placed, paid, packed and shipped.

The live model evaluation for test case generation is pending. The current label is listed on the Capabilities page.

What a generated case contains

Each case follows a fixed JSON schema, so every draft has the same shape.

Field	Content
Title	A short name
Type	positive, negative or boundary
Risk	The risk the case addresses
Acceptance criteria	References to criteria that exist in the story
Steps	Up to eight steps, each with an action, optional data and an expected result
Expected result	The overall outcome
Tags	Always includes AI-generated

Output that does not match the schema is rejected. The model is asked again with the validation error a limited number of times; after that, the problem goes to a human. If a case refers to an acceptance criterion that does not exist in the story, it fails validation.

A draft set for STORY-142 might include “Paid order can be cancelled within the window” (positive, AC1), “Shipped order shows Request return instead of Cancel” (negative, AC4) and “Cancellation exactly at the end of the window” (boundary, AC1). The platform also lists any acceptance criterion that no case covers.

Reviewing cases

The analyst reviews every draft. For each case there are three decisions:

• Approve the case as written.
• Edit the case and then approve it. The platform records a field-level diff between the AI draft and the approved version.
• Reject the case, with a reason.

Every decision is a logged human action bound to the case’s content hash. If an approved case is later reopened and edited, it returns to draft and cannot be published or used for code generation on the strength of its old approval.

The platform measures review as it happens: acceptance on first decision, rejection reasons, edit size and review time. These numbers appear in the Control Tower with their source tables. In REPLAY mode there is no model time to measure, so “AI plus review” time is review time only, and the interface says so.

Publishing to Jira or Xray

Publishing writes approved cases to your test management tool. It always starts with a publish preview, a dry run that lists the action for each case (for example, create) without writing anything.

A case is published only when all three conditions hold:

1. Its status is approved.
2. Its current content hash equals the approved hash.
3. The story’s product owner approval is still current.

Two targets are supported:

• Jira Test issues: each case becomes a Test issue, with steps in a table in the description.
• Xray Cloud: each case becomes a manual Xray test with structured steps.

In both cases the test is linked to the story with a Test link type when it exists, and with Relates otherwise. A comment on the story records the publication together with the audit chain hash.

Idempotency and partial failures

Publishing is designed to be safe to repeat.

• Each case carries an external reference. Publishing the same case twice finds the existing issue instead of creating a second one.
• If some cases fail, for example because Jira is briefly unavailable, the result reports which cases succeeded and which did not. Running Publish selected again completes the rest without duplicates.
• Jira Cloud search indexes can lag by a few seconds after an issue is created. The platform does not rely on search to detect its own earlier writes.

The issue type and link types depend on your Jira configuration. In a project where Xray is installed, the Test issue type belongs to Xray. Either target can be used in that project, but the results look different in Xray. See Integrations setup for the details.

Drafting cases from an IDE (Demonstrated)

Teams that already work in an AI coding assistant can draft cases there and still use the same gates. The platform exposes an MCP endpoint with three tools:

• get_requirement returns the product owner approved text, acceptance criteria and test data, together with the approved content hash.
• submit_draft_cases adds drafts to the requirement. Drafts must match the same schema. If the story changed since get_requirement, the submission is rejected. If one case is invalid, none are saved.
• publish_test_cases runs the same publish job as the portal, with the same checks.

The analyst creates a short-lived, single-scope API token in the portal for this channel. Tokens cannot approve. Drafts submitted from an IDE appear in the portal like any other draft, and a human approves them there. Every tool call is logged with the caller.

Existing manual test cases (Roadmap)

Many teams already hold large libraries of manual test cases in Jira, Xray or other tools. Importing those cases and using them as a learning library for generation is on the roadmap. The date is set by pilot demand.

Today the platform generates new cases from stories. Existing cases stay where they are and can be referenced by your team during review. Connectors for other test management tools, such as TestRail or Zephyr, are not available today.

If importing existing cases is a requirement for you, raise it in the pilot conversation so that it can be scoped as a pilot condition.