How to Use ACCELQ Autopilot Converse: Jira Story to Running Test Suite in 6 Steps

Which Converse Task Do You Need?

Before You Start

• An ACCELQ account with Autopilot enabled. Start a 14-day free trial.
• A requirements tool connected under Project Admin → Requirements Traceability. Jira, Azure DevOps, Rally Cloud, Spira, ClickUp, and Agile Accelerator are supported. This guide uses Jira.
• An Application in App Hub for the system under test, ideally with its key screens attached. Converse asks you to pick one in most tasks.
• For Step 3: a Swagger/OpenAPI (version 2 or 3) URL or file.

2. Select Build Test Plan & Automate. The menu expands to the BUILD, DISCOVER, and ANALYZE actions.

3. Choose a source: Description/intent, Gherkin .feature file, or Work item(s). Select Work item(s).

4. Type AT-121 and press Enter. If you only know the title, use Search by Title, then Apply. When you add several items, keep them in one shared context, because Converse interprets them against the same screens.

6. Select Proceed. The Strategy Planner and Test Builder agents return a plan in seconds.

7. Review the plan. For AT-121, Converse produced six data-driven scenarios with 10 test cases (1.7x per scenario). Each scenario carries its variations, so one scenario can cover several invalid inputs, each with its expected result.

Open a scenario and check three things:

• Steps: They should follow your Salesforce flow: App Launcher, Sales, New Lead, fill fields.
• Variants: Expect at least one positive case and one negative case, such as a required field missing. If you only see positive cases, add data coverage hints and regenerate.
• Priorities: P1 should be what blocks the story from shipping.

8. Pick the next action:

• Automate now builds each scenario in your Project and reuses matching Actions, such as an existing “Login to Salesforce”. Steps without a match become direct statements in the Scenario.
• Export to Excel gives you an offline copy in the Manual Scenario Import format.
• Create manual tests needs the ACCELQ Manual module.

To adjust a plan, export it to Excel or create manual tests, edit there, then automate. Automation builds the full Scenario logic. Add parameters and Test Cases afterward, using the plan’s variations, the Excel export, or the data you generate in Step 4.

3. Attach the screens the manual steps walk through, then let Converse generate the automation.

6. Review the plan, select Proceed, and confirm. It has two parts: User Journey Scenarios (multi-endpoint business flows that carry values from one response into the next call) and Unit Test Scenarios (one per endpoint, with authentication resolved and declared responses verified).

7. Open each generated Scenario and run Playback against your API. Start with the journeys, since they hold the most assumptions.

What Converse does for you in this step

1. Modularizes: Scenarios are built from reusable Actions, which are added to your Project for future automation against the same API.
2. Parameterizes: Values that need to vary become parameters, linked at the Scenario level so one value flows to every place it belongs.
3. Verifies: Validations cover the responses and status codes your specification declares.
4. Resolves authentication and dependencies: Calls a request depends on are chained ahead of it, so each Scenario stands on its own.
5. Chains output data: Values a later call needs are captured from earlier responses and carried forward.
6. Designs Test Case variations: Data is chosen for maximum coverage from the fewest permutations, with no exhaustive cross-product.
7. Generates global properties: Shared values such as endpoint URLs make the assets self-contained and portable across environments.

Scope the selection to endpoints you intend to maintain. A large specification can produce a great deal of automation in one run, and a coherent group is easier to review.

You should see API scenarios in the Navigator, each with parameterized test cases.

3. Set the record count.

4. Check the Fields tab and the Patterns & Constraints tab. Use Refine Requirements to edit any rule (one field_name: description per line), then select Generate Data.

5. Preview the records and download as CSV, Excel, JSON, or XML. To use the data, open a parameterized scenario’s Test Cases tab and import it. Each row becomes a Test Case.

Be specific. “Employee ID in the format E-12345” works better than “employee ID with numbers”, and stating that salary depends on department gives more coherent data than describing the two fields separately. The data is synthetic, so there is no production data to mask.

Or run from the Scenarios or Test Suites view: select the scenarios, click Run, then choose the agent, Environment Profile, and browser. The Run dialog works the same for generated and hand-built scenarios (see Steps 7 and 8 of the first-test walkthrough for scheduling and CI jobs).

ACCELQ starts the job and generates a job ID. Copy it, because you will use it in Step 6 to check status.

You should see the job in the Results sidebar.

Step 6: Check Status and Summarize Runs

1. Under DISCOVER, select Check Job Status and enter the job ID.

2. Under ANALYZE, select Summarize Runs and give it job IDs or a scope in plain English, such as last two weeks on Chrome. You can also start from the Results grid (select jobs, click Summarize) or the Summarize button on a Test Suite page.

3. Read the report. In this example, it shows:

• Scope: 8 executions across 2 jobs, 4 unique tests.
• Failure classification: Each failure lands in Persistent, Regression, Flaky, Inconclusive, or Now Passing. Both failures here are Flaky, meaning results alternate between pass and fail.
• Requirements at risk: AT-120 and AT-121. One linked test in a failing state puts a requirement at risk.
• Defects: AT-122 and AT-123, linked to the failing tests. A callout flags failing tests with no linked defect.
• Analysis: An AI-written narrative covering trends and coverage patterns.

4. Download the report as a PDF for release sign-off.

Use the report to decide where to investigate first. It classifies patterns across runs and leaves root-cause analysis to your team.

To get the most from it:

• Summarize several jobs: Failure classification builds on run history. With a single job, failures show as Inconclusive until more runs add context.
• Scope the request: A suite, a release, or a time range keeps the AI narrative specific. Very broad scopes (more than 100 unique failing tests or 50,000 executions) return the full data without the narrative.
• Connect your trackers: The Defects and Requirements tabs appear when those integrations are connected.
• Define execution parameters and custom fields: Release, sprint, and region, plus test case fields such as module and priority, make the coverage breakdown specific to your team.

How the report reads

You should see: a Release Readiness report with a verdict, failure classification, and linked Jira items.

Common Issues

• Converse stops or returns no output: Check that your account has enough Autopilot credits. Large reference files, large Swagger specs, and very broad scopes use more credits, so attach focused files and scope each request.
• Too few scenarios or a generic plan: Add data coverage hints, pick the right App Hub application, and attach the screens the story walks through.
• Swagger URL rejected: Confirm it returns a valid OpenAPI 2 or 3 definition and is reachable from your network. If it needs authentication, download the file and upload it.
• Run by Intent finds nothing: Use the exact scenario or suite name, including any rename, or run from the Scenarios view.

Next Steps

The assets Converse generates use the same Context, Action, Scenario structure you would build by hand, so you can edit, extend, and reuse them like any other ACCELQ asset. Start a 14-day free trial (no credit card required), schedule a demo, or talk to a specialist.