> 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

Use ContextQA MCP support-to-fix tools to create a reproduction, distinguish a matching defect from a blocked run, review evidence, and file a supported report.

## Quick answer

Use `reproduce_from_ticket` to create and run a reproduction, then compare the execution evidence with the behavior described in the ticket. **A failed run alone does not confirm the reported bug.** A timeout, authentication problem or unrelated assertion failure may prevent the reproduction from reaching the relevant step.

Use `investigate_failure` to inspect the available evidence. When it supports the reported defect, use `create_defect_ticket` to file the report in your connected ALM. Keep the observed behavior separate from any root-cause hypothesis.

## What this page covers

{% hint style="info" %}
**Who is this for?** Developers and SDETs who receive bug reports and need a reproducible, evidence-backed handoff. The assistant can help prepare and run a reproduction; a reviewer still checks that the steps, assertions and evidence match the report.
{% endhint %}

This guide takes a support ticket through reproduction, evidence review and defect filing using ContextQA MCP tools. Its result is a test-case reference, an interpreted execution result and, when appropriate, a defect ticket linked to the supporting evidence.

“Not reproduced,” “blocked” and “inconclusive” are useful outcomes. None means that the bug is fixed.

## Prerequisites

* A ContextQA account with at least one workspace ([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, expected behavior and observed behavior.
* The base URL of the application where the bug occurs, preferably an isolated test or staging environment.
* Authorized test access, the correct user role and repeatable test data. Use synthetic data where possible; do not paste passwords, session cookies or access tokens into the ticket or prompt.
* To file a defect in Step 4, a connected ALM integration: [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 have not connected the MCP server yet, complete [Create your first test with an AI agent](/mcp-server/first-test-tutorial.md). This guide assumes your assistant can already call ContextQA tools.

Record the application build, environment, relevant feature flags, user role and data setup before running the reproduction. If you cannot match the reporter's conditions, record the differences.

***

## Step 1: Create and run the reproduction

Give your assistant the ticket text and application URL. The `reproduce_from_ticket` tool creates a test case from the reported steps and starts an execution.

Ask your agent:

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

"Using the authorized test shopper and a reset synthetic cart:
1) Add the test item to the cart.
2) Proceed to checkout.
3) Enter the test promo code SAVE10.
4) Click Apply.

Expected: the discount is applied and the displayed and stored totals
match the agreed promotion rule.
Reported behavior: the page keeps showing a spinner and the total
does not update. The original report did not include network evidence."

Return the created test_case_id, generated steps and assertions,
and the execution_id. State any missing prerequisite or assumption.
```

Include the full report and distinguish the reporter's observation from your own hypothesis. If a timeout matters, use the timeout defined by the product requirement or test protocol; do not invent one to force a failure.

Review the generated steps and assertions. They must check the expected business outcome, not simply repeat the application's current response. Correct a missing role, fixture or assertion before relying on the result; retain the original run as an unverified attempt if it already started.

**Verify it worked:** a test case was created and an execution started. Save the `test_case_id` and `execution_id`. Those identifiers establish that a run exists, not that the bug reproduced.

{% hint style="info" %}
**Domain context:** If needed, ask the agent to use a relevant knowledge base or custom agent persona. It can resolve `knowledge_id` through `list_knowledge_bases`, or `persona_id` through `list_custom_agents`, for the reproduction. Review the resulting steps against the ticket even when this context is supplied.
{% endhint %}

***

## Step 2: Interpret the result against the reported behavior

Executions are asynchronous. Ask the agent to poll `get_execution_status` until the run reaches a terminal state, then inspect the relevant step and assertion.

```
Wait for the reproduction to finish. Report the terminal execution status
separately from the reproduction conclusion.

Did the run reach the reported step under the recorded conditions?
Which assertion checked the expected behavior, and what did it observe?
Classify the conclusion as reproduced, not reproduced, blocked,
or inconclusive, with evidence and any missing information.
```

| Evidence from this attempt                                                                        | Reproduction conclusion                      | Next step                                                                            |
| ------------------------------------------------------------------------------------------------- | -------------------------------------------- | ------------------------------------------------------------------------------------ |
| The relevant assertion failed, and evidence shows the same behavior described in the report       | **Reproduced** under the recorded conditions | Collect and review the evidence in Step 3                                            |
| The relevant assertion ran and passed, with evidence that the expected outcome occurred           | **Not reproduced** in this attempt           | Preserve the run, compare conditions and refine or repeat the reproduction if needed |
| Authentication, access, test data or environment failure prevented the relevant step from running | **Blocked**                                  | Record the blocker and owner; restore the prerequisite before rerunning              |
| A timeout, cancellation, missing artifact or unrelated failure prevents a reliable interpretation | **Inconclusive**                             | Identify the missing evidence or failed prerequisite; do not claim confirmation      |

A timeout can be evidence for a reported hang **only when** the run reached the relevant action and the retained evidence matches the reported symptom under the agreed conditions. An authentication timeout before checkout does not reproduce a checkout bug. A network error may be relevant evidence, but it does not by itself establish which component caused the problem.

A negative test can pass correctly: if a viewer must be denied a change, the passing outcome is that the change was denied. Interpret the assertion, not the color of the run.

**Verify it worked:** the report contains both the execution's terminal state and a supported reproduction conclusion. If the assistant provides only “Failed” or “Passed,” ask for the assertion and evidence before proceeding.

***

## Step 3: Review the available evidence and investigate the failure

Use `investigate_failure` to inspect the failed run. Depending on the execution, the returned bundle may include step results, console or network details, trace and recording links, AI analysis and a `reproduce_prompt`. Check which artifacts are actually present and accessible rather than assuming the bundle is complete.

Ask your agent:

```
Investigate this execution. Separate observed facts from possible causes.
Identify the relevant failed assertion, expected and actual outcome,
available evidence links, and missing evidence.

If you propose a root cause, label it as a hypothesis and state what
would confirm or contradict it. Do not infer a cause from status alone.
```

For the checkout example, an unanswered promo-code request and a persistent spinner may support the reported behavior. They do not alone establish why the request failed. A backend defect, configuration problem and dependency failure may require different follow-up checks.

Review the evidence packet before sharing it:

* Confirm the artifacts belong to the recorded `execution_id` and application build.
* Check that the screenshots, recording and logs support the stated symptom.
* Preserve first-attempt results and list retries separately.
* Remove secrets and personal or confidential data from the sharing copy. Network captures and logs may contain credentials even when screenshots do not.
* Mark missing or inaccessible evidence explicitly.

**Verify it worked:** an engineer can trace the conclusion to the relevant step, assertion and observed outcome. A root-cause explanation generated by the tool remains a hypothesis until supporting investigation establishes it.

{% hint style="info" %}
**Intermittent behavior:** A fresh investigation can use `investigate_failure` with `rerun` enabled. Preserve the original execution ID and record the new run separately. A passing rerun does not erase the original failure or prove a fix.
{% endhint %}

***

## Step 4: File or update the defect report

Before creating a new ticket, check whether the source ticket or an existing engineering issue already tracks the defect. Keep a link to the original report and avoid creating duplicates for the same evidence.

When the reproduction supports the reported defect, ask the agent to use `create_defect_ticket` with the reviewed execution and the intended ALM project:

```
Create a defect in the CQA project for this reviewed reproduction.
Use the recorded execution_id. Include the observed behavior, expected
assertion, environment/build, evidence links and reproduction conclusion.
Label the proposed root cause as unconfirmed unless separately verified.
Return the created ticket ID and URL.
```

The `create_defect_ticket` tool uses the `execution_id` and ALM `project_id` to create the report in the connected system. Review the proposed project and issue content before filing. If the result is blocked or inconclusive, keep it as an investigation with those limits; do not describe it as a confirmed defect.

**Verify it worked:** open the returned ticket URL and check the project, identifiers, evidence links, source-ticket association and wording. A returned URL is not a substitute for inspecting the created record.

{% hint style="warning" %}
`create_defect_ticket` requires a connected ALM integration. If no project is available, configure [Jira](/integrations/jira.md) or [Azure DevOps](/integrations/azure-devops.md) in the workspace before retrying. Check for an existing ticket first if a previous creation attempt had an uncertain result.
{% endhint %}

***

## Use a complete support-to-engineering handoff

Copy this record into the issue before assigning it:

```
Reported behavior and source ticket:
Expected behavior and acceptance-condition reference:
Application build / commit:
Environment, browser, role, and relevant configuration:
Preconditions, synthetic fixture, and reset procedure:
Exact reproduction steps:
ContextQA test_case_id and execution_id:
Terminal execution status:
Relevant assertion, expected value, and observed value:
Reproduction conclusion: reproduced / not reproduced / blocked / inconclusive
Evidence links and redactions:
Attempts and retries, each with a result reference:
Differences from the reporter's conditions:
Root-cause hypothesis and supporting evidence:
What would confirm or contradict the hypothesis:
Missing evidence or blocker:
Owner and next action:
Repair acceptance test:
```

Ask a reviewer who did not prepare the environment to follow the recorded prerequisites and steps. Add any missing setup they discover. This checks whether the reproduction is portable beyond the original session.

## Verify a repair without weakening the test

Preserve the original failing artifact. Run the unchanged reproduction against the proposed repair build with the same role, fixture and relevant configuration. Record both build identifiers and retain the failing and verification runs.

Check adjacent allowed and denied behaviors where relevant. A permission repair should not merely disable the entire workflow. If the requirement itself changed, record that as a separate product decision before changing the assertion.

“Not reproduced” does not mean “fixed.” A repair is verified only for the scope and acceptance conditions actually tested. Keep unresolved conditions visible.

## Verification

The handoff is complete when:

* The test case and execution references are available in the workspace.
* The relevant assertion was reviewed against the report.
* The execution status and reproduction conclusion are recorded separately.
* Available evidence supports the conclusion, and missing evidence is stated.
* Proposed causes are distinguished from established causes.
* When a defect was filed, its ALM record and evidence links were inspected.
* A blocked or inconclusive attempt has an owner and a next action.

***

## Troubleshooting

| Problem                                                 | What to check                                                                      | Next action                                                                                            |
| ------------------------------------------------------- | ---------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------ |
| The run fails before the reported action                | Authentication, access, fixture or environment prerequisites                       | Mark blocked or inconclusive; restore the prerequisite and rerun                                       |
| The reproduction passes when a failure was expected     | Whether the assertion ran, data/build differences and report completeness          | Preserve the result and refine the conditions; do not conclude that the issue is fixed                 |
| The generated steps omit part of the flow               | Ambiguous ticket text or missing domain context                                    | Add explicit steps and acceptance conditions; review the revised test                                  |
| A timeout is reported as confirmation                   | Whether the relevant action was reached and the evidence matches the reported hang | Inspect the relevant step and agreed timeout; keep the result inconclusive if evidence is insufficient |
| Root cause is vague                                     | Whether the evidence supports a mechanism or only a symptom                        | Record a hypothesis and the next discriminating check; rerun only when useful                          |
| A rerun passes after the original failure               | Differences in build, data, environment, timing and retries                        | Preserve both attempts and investigate variability                                                     |
| `create_defect_ticket` fails or its result is uncertain | Connected integration, project selection and existing issues                       | Inspect the ALM before retrying to avoid a duplicate                                                   |
| Domain terms are misinterpreted                         | Missing knowledge-base or persona context                                          | Supply relevant context and review the generated steps again                                           |

***

## Related pages

* [Create your first test with an AI agent](/mcp-server/first-test-tutorial.md)
* [Support-to-Fix & Migration Platform Tools](/mcp-server/tool-reference/support-and-migration.md)
* [Bug, Defect & Advanced Testing](/mcp-server/tool-reference/bug-defect-and-advanced.md)
* [Failure Analysis](/reporting/failure-analysis.md)
* [AI testing pilot scorecard: interpret control outcomes](/evaluation-and-governance/ai-testing-pilot-scorecard.md#interpret-control-outcomes-before-scoring)
* [Agent Integration Guide](/mcp-server/agent-integration-guide.md)

{% hint style="info" %}
**Evaluate the workflow with one useful example.** [Book a demo](https://contextqa.com/book-a-demo/?utm_source=learning.contextqa.com\&utm_medium=referral\&utm_campaign=docs_demand_gen\&utm_content=bug_reproduction) and bring a sanitized bug report with its expected behavior and a difficult failure to investigate.
{% 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 by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

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

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

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.