> 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/tool-reference/support-and-migration.md). # Support-to-Fix & Migration {% hint style="info" %} **Who is this for?** SDETs, developers, and DevOps engineers integrating ContextQA with AI coding assistants (Claude, Cursor) or CI/CD pipelines. {% endhint %} This reference covers three groups: support-to-fix tools that turn support tickets and failure evidence into actionable tests, analytics and coverage tools that identify untested high-traffic flows, and migration tools for importing existing test repositories into ContextQA or exporting back to Playwright. *** ## Support-to-Fix *** ## reproduce\_from\_ticket Creates and immediately executes a test case that reproduces the bug described in a support ticket or issue description; use this to verify a reported defect is reproducible before assigning it to an engineer. **Category:** Support-to-Fix | **Authentication required:** Yes ### Parameters | Name | Required | Type | Description | | ------------- | -------- | ------ | ----------------------------------------------------------------------------------------------------------------------------------------------------- | | ticket\_text | ✅ | string | Full text of the support ticket, bug report, or issue description. Include steps to reproduce, expected behaviour, and actual behaviour if available. | | url | ✅ | string | Base URL of the application where the bug should be reproduced. | | name | ❌ | string | Display name for the generated test case. Defaults to a name derived from the ticket text. | | persona\_id | ❌ | string | Custom agent persona to use during reproduction. Obtain from `list_custom_agents`. | | knowledge\_id | ❌ | string | Knowledge base to attach for domain context. Obtain from `list_knowledge_bases`. | ### Returns JSON with the created `test_case_id`, the generated test steps, and an `execution_id` for the immediate run. Use `get_execution_status` to monitor the reproduction result. ### Example ```json { "ticket_text": "User reports they cannot 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.", "url": "https://staging.example.com", "name": "Reproduce: Promo code freezes checkout" } ``` ### Related Tools `investigate_failure`, `create_defect_ticket`, `execute_test_case`, `get_execution_status` *** ## investigate\_failure Collects the complete evidence bundle for a failed test result — step results, console logs, network errors, trace URL, video recording, AI reasoning, and root cause analysis — and returns it as a single investigation report with a `reproduce_prompt` that can be passed back to `reproduce_from_ticket`. **Category:** Support-to-Fix | **Authentication required:** Yes ### Parameters | Name | Required | Type | Description | | ---------- | -------- | ------- | ----------------------------------------------------------------------------------------------------------------------- | | result\_id | ✅ | integer | Numeric ID of the failed test case result to investigate. | | rerun | ❌ | boolean | If `true`, triggers a fresh execution before collecting evidence, ensuring the failure is current. Defaults to `false`. | ### Returns JSON investigation bundle containing: `stepResults`, `consoleLogs`, `networkErrors`, `traceUrl`, `videoUrl`, `aiReasoning`, `rootCause` (from the root cause engine), and a `reproduce_prompt` — a ready-to-use text description of the failure suitable for passing to `reproduce_from_ticket` or `create_defect_ticket`. ### Example ```json { "result_id": 1042, "rerun": false } ``` ### Related Tools `reproduce_from_ticket`, `get_root_cause`, `get_test_step_results`, `get_console_logs`, `get_network_logs`, `get_trace_url`, `get_ai_reasoning`, `create_defect_ticket` *** ## Analytics & Coverage *** ## analyze\_coverage\_gaps Queries a connected product analytics integration to find high-traffic user flows that have no corresponding test coverage, returning a prioritised gap analysis for test creation. **Category:** Analytics & Coverage | **Authentication required:** Yes ### Parameters | Name | Required | Type | Description | | ------------------- | -------- | ------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | analytics\_provider | ✅ | string | Name of the analytics integration to query. Accepted values: `"mixpanel"`, `"amplitude"`. The integration must be configured in ContextQA workspace settings before use. | ### Returns JSON with a `gaps` array ordered by traffic volume. Each item includes `flow_name`, `page_path`, `event_count` (30-day), `suggested_test_description`, and a `coverage_score` (0–100, where 0 means no tests at all). Also includes a `summary` with total uncovered sessions and estimated risk exposure. ### Example ```json { "analytics_provider": "mixpanel" } ``` ### Related Tools `generate_tests_from_analytics_gap`, `get_ai_insights`, `create_test_case` *** ## Migration Platform *** ## analyze\_test\_repo Scans a local test repository to detect its framework, enumerate all test files, and estimate the total test count — without making any ContextQA API calls, making it safe to run as a first step before committing to a full migration. **Category:** Migration Platform | **Authentication required:** Yes > **Note:** This tool performs only local analysis. No test data is sent to ContextQA. Run this before `migrate_repo_to_contextqa` to preview what will be migrated. ### Parameters | Name | Required | Type | Description | | ---------- | -------- | ------ | ------------------------------------------------------- | | repo\_path | ✅ | string | Absolute local path to the root of the test repository. | ### Returns JSON with `detectedFramework` (e.g. `"cypress"`, `"playwright"`, `"selenium"`, `"jest"`), `language`, `testFiles` (array of relative file paths), and `estimatedTestCount` (integer). ### Example ```json { "repo_path": "/home/dev/projects/my-app/e2e" } ``` ### Related Tools `migrate_repo_to_contextqa`, `export_to_playwright`, `query_repository` *** ## migrate\_repo\_to\_contextqa Migrates an existing local test repository into ContextQA by parsing test files and creating equivalent ContextQA test cases. Use `dry_run=true` first to preview what would be created without making any changes. **Category:** Migration Platform | **Authentication required:** Yes ### Parameters | Name | Required | Type | Description | | ---------- | -------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- | | repo\_path | ✅ | string | Absolute local path to the root of the test repository. | | app\_url | ✅ | string | Base URL of the application under test. Used to contextualise migrated steps. | | framework | ❌ | string | Override the auto-detected framework. Useful when detection is ambiguous. Accepted values: `"cypress"`, `"playwright"`, `"selenium"`, `"jest"`. | | dry\_run | ❌ | boolean | If `true`, returns a preview of what would be migrated without creating anything in ContextQA. Defaults to `false`. Always run with `dry_run=true` first. | ### Returns JSON with `migratedCount` (integer), `skippedCount` (integer), `createdTestCaseIds` (array of integers), and a `summary` message. In dry-run mode, `createdTestCaseIds` is empty and `migratedCount` reflects the projected count. ### Example ```json { "repo_path": "/home/dev/projects/my-app/e2e", "app_url": "https://staging.example.com", "dry_run": true } ``` Once the dry-run output looks correct, re-run with `"dry_run": false` to complete the migration. ### Related Tools `analyze_test_repo`, `export_to_playwright`, `get_test_cases` *** ## export\_to\_playwright Exports ContextQA test cases as a complete Playwright TypeScript project to a local directory, including `playwright.config.ts`, `package.json`, `tsconfig.json`, and individual spec files — one per test case. **Category:** Migration Platform | **Authentication required:** Yes ### Parameters | Name | Required | Type | Description | | --------------- | -------- | ----------------- | --------------------------------------------------------------------------------------------------------------------- | | output\_dir | ✅ | string | Absolute local path where the Playwright project will be written. The directory will be created if it does not exist. | | project\_name | ❌ | string | Name used in `package.json` and `playwright.config.ts`. Defaults to `"contextqa-export"`. | | test\_case\_ids | ❌ | array of integers | IDs of specific test cases to export. If omitted, all test cases in the workspace are exported. | ### Returns JSON with `outputPath` (absolute path to the generated project), `exportedCount` (integer), `specFiles` (array of generated file paths), and a `run_command` suggestion (e.g. `npx playwright test`). ### Example ```json { "output_dir": "/home/dev/projects/playwright-export", "project_name": "storefront-tests", "test_case_ids": [10, 11, 12, 45, 46] } ``` ### Related Tools `migrate_repo_to_contextqa`, `analyze_test_repo`, `export_test_case_as_code`, `get_test_cases` *** --- # 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/tool-reference/support-and-migration.md?ask=&goal= ``` `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.