How to Reproduce a Bug from a Support Ticket
Turn a support ticket into a running reproduction in ContextQA using the MCP support-to-fix tools — reproduce the bug, confirm it, collect the evidence bundle with AI root cause, and file a defect tic
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.
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).
The ContextQA MCP server connected to your AI assistant — Claude Code, Claude Desktop, Cursor, ChatGPT, or Codex. See Installation & Setup.
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 or Azure DevOps.
Familiarity with core concepts — test cases, steps, and executions.
If you haven't connected the MCP server yet, complete Create your first test with an AI agent 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.
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.
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:
The agent polls get_execution_status until the run reaches a terminal state and reports the outcome.
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:
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.
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.
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:
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.
create_defect_ticket requires a connected ALM integration. If the agent reports that no project is available, configure the Jira or Azure DevOps integration in your workspace first, then retry.
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
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 or Azure DevOps 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 — connect the MCP server and run your first test
Support-to-Fix & Migration Platform Tools — full parameter reference for
reproduce_from_ticketandinvestigate_failureBug, Defect & Advanced Testing — full parameter reference for
create_defect_ticketandget_root_causeFailure Analysis — how to interpret root cause analysis and evidence
Agent Integration Guide — tool ordering and multi-step orchestration
Confirm and file bugs from a chat prompt — no manual reproduction. Start Free Trial → — Or Book a Demo → to see the support-to-fix workflow with your stack.
Last updated
Was this helpful?