> For the complete documentation index, see [llms.txt](https://learning.contextqa.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://learning.contextqa.com/mcp-server/reproduce-bug-from-ticket.md).

# How to Reproduce a Bug from a Support Ticket

{% hint style="info" %}
**Who is this for?** Developers and SDETs who receive bug reports and need to confirm a defect is real before assigning it. You paste the ticket into your AI assistant, and ContextQA builds and runs a reproduction, gathers the evidence, and files the defect — without writing a test by hand.
{% endhint %}

This guide walks you through the support-to-fix workflow: take a bug described in a support ticket, reproduce it in ContextQA, confirm whether it reproduces, collect a full evidence bundle with AI root cause analysis, and file a defect ticket to your ALM. The flow uses the `reproduce_from_ticket`, `investigate_failure`, and `create_defect_ticket` MCP tools, driven from plain-English prompts.

By the end, you have a running reproduction test case, a root cause explanation, and — when the bug is real — a defect ticket in Jira or Azure DevOps that links back to the evidence.

## Prerequisites

* A ContextQA account with at least one workspace ([sign up at contextqa.com](https://contextqa.com)).
* The ContextQA MCP server connected to your AI assistant — Claude Code, Claude Desktop, Cursor, ChatGPT, or Codex. See [Installation & Setup](/mcp-server/installation-and-setup.md).
* A support ticket, bug report, or issue description with steps to reproduce.
* The base URL of the application where the bug occurs — for example, a staging environment.
* To file a defect ticket in Step 4, a connected ALM integration (Jira or Azure DevOps). See [Jira](/integrations/jira.md) or [Azure DevOps](/integrations/azure-devops.md).
* Familiarity with [core concepts](/getting-started/core-concepts.md) — test cases, steps, and executions.

If you haven't connected the MCP server yet, complete [Create your first test with an AI agent](/mcp-server/first-test-tutorial.md) first. This guide assumes your assistant can already call ContextQA tools.

***

## Step 1: Reproduce the bug from the ticket

Give your agent the ticket text and the application URL. The `reproduce_from_ticket` tool reads the report, creates a test case that follows the reported steps, and runs it immediately.

Ask your agent:

```
Reproduce this bug in ContextQA against https://staging.example.com:

"User reports they can't complete checkout when using a promo code.
Steps: 1) Add item to cart, 2) Proceed to checkout, 3) Enter promo code
SAVE10 in the promo field, 4) Click Apply. Expected: discount applied and
total updated. Actual: page freezes and shows a spinner indefinitely."
```

Paste the full ticket, including the steps, the expected behavior, and the actual behavior. The agent maps your description to `reproduce_from_ticket` and reports back the created `test_case_id`, the generated steps, and an `execution_id` for the run it started.

**Verify it worked:** The agent confirms it created a test case and started a run. Note the `execution_id` — you use it to collect evidence and file a defect in the later steps.

{% hint style="info" %}
**Tip:** For a domain-specific application, attach a custom agent persona or a knowledge base so the reproduction understands your terminology. Ask the agent to "use the checkout knowledge base" — it resolves the `knowledge_id` from `list_knowledge_bases` (or the `persona_id` from `list_custom_agents`) and passes it to the reproduction.
{% endhint %}

***

## Step 2: Confirm whether the bug reproduced

Execution is asynchronous, so let the agent poll for the result. The interpretation here is the reverse of a normal test run: a **failed** reproduction means the bug *is* real, and a **passed** reproduction means the reported behavior didn't occur.

Ask your agent:

```
Did the reproduction reproduce the bug? Wait for it to finish and tell me
the result.
```

The agent polls `get_execution_status` until the run reaches a terminal state and reports the outcome.

| Reproduction result | What it means                                          | Next step                                                                                                            |
| ------------------- | ------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------- |
| Failed              | The bug reproduced — the reported problem occurred     | Continue to Step 3 to collect evidence                                                                               |
| Passed              | The bug didn't reproduce — the flow worked as expected | The issue may be environment-specific, already fixed, or need more detail; refine the ticket steps and re-run Step 1 |

**Verify it worked:** The agent reports a terminal status. A failed run confirms you reproduced the reported defect.

***

## Step 3: Collect the evidence bundle

For a reproduced bug, gather everything an engineer needs to fix it. The `investigate_failure` tool assembles a single report — step results, console logs, network errors, the trace URL, the video recording, the AI reasoning, and a root cause analysis — plus a ready-to-use `reproduce_prompt`.

Ask your agent:

```
Investigate the failed reproduction and explain the root cause.
```

The agent calls `investigate_failure` for the run and returns the consolidated bundle, including a plain-English root cause that points to the failing step and the likely reason — for example, a promo-code request that never returns, leaving the spinner active.

**Verify it worked:** You receive a root cause explanation tied to a specific step, with links to the screenshots, video, and logs. This is the evidence you attach to the defect.

{% hint style="info" %}
**Tip:** If the reproduction is intermittent, ask the agent to investigate with a fresh run — this triggers `investigate_failure` with `rerun` enabled so the evidence reflects a current execution rather than a stale one.
{% endhint %}

***

## Step 4: File a defect ticket

Once you confirm the bug and have the evidence, file it to your ALM without leaving the assistant. The `create_defect_ticket` tool compiles the failure evidence from the reproduction run and pushes a structured ticket to Jira or Azure DevOps.

Ask your agent:

```
File a defect in the CQA project for this failed reproduction.
```

The agent calls `create_defect_ticket` with the `execution_id` from Step 1 and the ALM `project_id` you name (`CQA` in this example). It returns the created ticket's ID, URL, title, and the ALM system it was filed against.

**Verify it worked:** The agent returns a ticket URL. Open it and confirm the defect exists in your ALM with the failure evidence attached.

{% hint style="warning" %}
`create_defect_ticket` requires a connected ALM integration. If the agent reports that no project is available, configure the [Jira](/integrations/jira.md) or [Azure DevOps](/integrations/azure-devops.md) integration in your workspace first, then retry.
{% endhint %}

***

## Verification

The workflow is complete when:

* The reproduction test case appears in your ContextQA workspace.
* The reproduction run reached a terminal status, and you interpreted it correctly (failed = bug reproduced).
* For a reproduced bug, you have a root cause explanation and an evidence bundle.
* A defect ticket exists in your ALM with a link back to the evidence.

***

## Troubleshooting

| Problem                                                 | Likely cause                                                                 | Fix                                                                                                                  |
| ------------------------------------------------------- | ---------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------- |
| The reproduction passes when you expect it to fail      | The ticket lacks detail, or the bug is environment-specific or already fixed | Add the exact fields, buttons, and expected values to the ticket text and re-run Step 1                              |
| The generated steps miss part of the flow               | The ticket description was ambiguous                                         | Rewrite the ticket text with numbered, explicit steps and reproduce again                                            |
| Root cause is vague                                     | The reproduction ran but produced thin evidence                              | Ask the agent to investigate with a fresh run so the evidence reflects a current execution                           |
| `create_defect_ticket` fails                            | No ALM integration is connected                                              | Configure the [Jira](/integrations/jira.md) or [Azure DevOps](/integrations/azure-devops.md) integration, then retry |
| The bug is domain-specific and the agent misreads terms | No domain context attached                                                   | Attach a knowledge base or custom agent persona in Step 1                                                            |

***

## Related pages

* [Create your first test with an AI agent](/mcp-server/first-test-tutorial.md) — connect the MCP server and run your first test
* [Support-to-Fix & Migration Platform Tools](/mcp-server/tool-reference/support-and-migration.md) — full parameter reference for `reproduce_from_ticket` and `investigate_failure`
* [Bug, Defect & Advanced Testing](/mcp-server/tool-reference/bug-defect-and-advanced.md) — full parameter reference for `create_defect_ticket` and `get_root_cause`
* [Failure Analysis](/reporting/failure-analysis.md) — how to interpret root cause analysis and evidence
* [Agent Integration Guide](/mcp-server/agent-integration-guide.md) — tool ordering and multi-step orchestration

{% hint style="info" %}
**Confirm and file bugs from a chat prompt — no manual reproduction.** [**Start Free Trial →**](https://app.contextqa.com/register) — Or [**Book a Demo →**](https://contextqa.com/book-a-demo/) to see the support-to-fix workflow with your stack.
{% endhint %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://learning.contextqa.com/mcp-server/reproduce-bug-from-ticket.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.