> 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/bug-defect-and-advanced.md).

# Bug, Defect & Advanced Testing

MCP tool reference for defect management, performance and security testing, code export, and AI-powered impact analysis in ContextQA.

## Quick answer

MCP tool reference for defect management, performance and security testing, code export, and AI-powered impact analysis in ContextQA. Use this reference to choose the appropriate tools, understand their required inputs, and interpret their user-visible outputs.

## Key takeaways

* MCP tool reference for defect management, performance and security testing, code export, and AI-powered impact analysis in ContextQA.
* Compiles failure evidence from an execution and pushes a structured defect ticket to the connected ALM (Jira or Azure DevOps); use this immediately after a failed execution to file a bug without leaving your AI assistant.
* Retrieves AI-generated proposals for repairing broken locators detected in a failed execution; review suggestions before applying them with approveautohealing.

## What this page covers

{% 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 capability groups: defect lifecycle tools that bridge test failures to your ALM, advanced testing tools for performance and security, and AI analysis tools that surface test impact and code context.

***

## Bug & Defect

***

## create\_defect\_ticket

Compiles failure evidence from an execution and pushes a structured defect ticket to the connected ALM (Jira or Azure DevOps); use this immediately after a failed execution to file a bug without leaving your AI assistant.

**Category:** Bug & Defect | **Authentication required:** Yes

### Parameters

| Name          | Required | Type   | Description                                     |
| ------------- | -------- | ------ | ----------------------------------------------- |
| execution\_id | ✅        | string | ID of the failed test execution to report.      |
| project\_id   | ✅        | string | ALM project identifier to create the ticket in. |

### Returns

JSON with the created ticket's `id`, `url`, `title`, and the ALM system it was filed against.

### Example

```json
{
  "execution_id": "exec_4d8f1a",
  "project_id": "CQA"
}
```

### Related Tools

`get_test_case_results`, `investigate_failure`, `get_root_cause`

***

## get\_auto\_healing\_suggestions

Retrieves AI-generated proposals for repairing broken locators detected in a failed execution; review suggestions before applying them with `approve_auto_healing`.

**Category:** Bug & Defect | **Authentication required:** Yes

### Parameters

| Name          | Required | Type   | Description                                        |
| ------------- | -------- | ------ | -------------------------------------------------- |
| execution\_id | ✅        | string | ID of the execution that produced broken locators. |

### Returns

JSON array of healing proposals. Each item includes `healing_id`, the original broken locator, the proposed replacement locator, a confidence score, and the affected test step.

### Example

```json
{
  "execution_id": "exec_4d8f1a"
}
```

### Related Tools

`approve_auto_healing`, `get_test_step_results`, `investigate_failure`

***

## approve\_auto\_healing

Applies a specific auto-healing patch to update the broken locator in the test case definition; always review the suggestion from `get_auto_healing_suggestions` first.

**Category:** Bug & Defect | **Authentication required:** Yes

### Parameters

| Name          | Required | Type   | Description                                                                            |
| ------------- | -------- | ------ | -------------------------------------------------------------------------------------- |
| healing\_id   | ✅        | string | ID of the healing proposal to apply. Obtained from `get_auto_healing_suggestions`.     |
| execution\_id | ❌        | string | Execution context for the heal. Helps the engine track which run triggered the repair. |

### Returns

JSON confirmation with `status`, the updated locator value, and the test step that was modified.

### Example

```json
{
  "healing_id": "heal_7c3b2e",
  "execution_id": "exec_4d8f1a"
}
```

### Related Tools

`get_auto_healing_suggestions`, `get_test_case_steps`, `update_test_case_step`

***

## Advanced Testing

***

## execute\_performance\_test

Runs a load test against the flows covered by a test case using a configurable virtual user count, duration, and ramp-up period.

**Category:** Advanced Testing | **Authentication required:** Yes

### Parameters

| Name           | Required | Type    | Description                                                |
| -------------- | -------- | ------- | ---------------------------------------------------------- |
| test\_case\_id | ✅        | integer | Numeric ID of the test case to use as the load scenario.   |
| virtual\_users | ✅        | integer | Number of concurrent virtual users to simulate.            |
| duration       | ✅        | integer | Total test duration in seconds.                            |
| ramp\_up       | ✅        | integer | Time in seconds to ramp up to the full virtual user count. |

### Returns

JSON with a performance execution ID, configuration echo, and a link to the live results dashboard.

### Example

```json
{
  "test_case_id": 88,
  "virtual_users": 100,
  "duration": 300,
  "ramp_up": 60
}
```

### Related Tools

`get_test_cases`, `get_execution_status`, `execute_test_case`

***

## execute\_security\_dast\_scan

Launches a DAST (Dynamic Application Security Testing) scan against the application exercised by a test case, using the specified scan profile to control scan depth and aggression.

{% hint style="danger" %}
Run a DAST scan only against an application you are authorized to test, preferably a non-production environment with disposable data. An active scan can submit forms, create records, or trigger other state-changing behavior; an aggressive profile increases that risk.
{% endhint %}

**Category:** Advanced Testing | **Authentication required:** Yes

### Parameters

| Name           | Required | Type    | Description                                                                                                                                           |
| -------------- | -------- | ------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- |
| test\_case\_id | ✅        | integer | Numeric ID of the test case whose flows define the scan target.                                                                                       |
| scan\_profile  | ✅        | string  | Scan intensity profile. Accepted values: `"standard"`, `"aggressive"`. Use `"standard"` for CI pipelines; `"aggressive"` for dedicated security runs. |

### Returns

JSON with a DAST scan execution ID, scan profile confirmation, and a link to the vulnerability report once the scan completes.

### Coverage boundary

This scan assesses the reachable surface exercised by the selected test flow and scan profile. It is not, by itself, a complete penetration test, source-code review, threat model, or compliance certification. Review the reported findings, validate their impact, and use a qualified security assessment when full application assurance is required.

### Example

```json
{
  "test_case_id": 88,
  "scan_profile": "standard"
}
```

### Related Tools

`get_test_cases`, `get_execution_status`, `execute_test_case`

***

## export\_test\_case\_as\_code

Requests code for one test case in a supported framework and language. This tool differs from the manifest-based Playwright project export: its destination path belongs to the MCP server's execution environment.

**Category:** Advanced Testing | **Authentication required:** Yes

### Parameters

| Name              | Required | Type   | Description                                                                              |
| ----------------- | -------- | ------ | ---------------------------------------------------------------------------------------- |
| test\_case\_id    | ✅        | string | Case identifier; verify the type in your current manifest.                               |
| framework\_type   | ✅        | string | Requested framework. Verify a supported value and usable output in your workspace.       |
| language          | ✅        | string | Requested language supported by the selected export path.                                |
| destination\_path | ✅        | string | Approved path on the MCP server's filesystem, not automatically the developer's machine. |

### Returns

The current implementation returns a status string that can include a download URL, and writes returned snippets under the server-side destination path. Inspect the actual response and verify file retrieval; do not infer local delivery from a success message. Framework or language acceptance is not proof of assertion parity.

### Example

```
Inspect the current single-case code export schema and confirm whether
our requested framework and language are supported. Identify where the
server writes files and how I can retrieve them before exporting case 55.
Do not assume a path on my laptop is accessible to the hosted server.
```

For local client delivery of a Playwright project, use the [manifest-based export reference](/mcp-server/tool-reference/support-and-migration.md#export_to_playwright) and [portability acceptance guide](/testing-with-ai-coding-agents/export-and-portability.md).

### Related Tools

`export_to_playwright`, `get_test_cases`, `migrate_repo_to_contextqa`

***

## AI-Powered Analysis

***

## get\_root\_cause

Sends failed step data, screenshots, and the session recording to the ContextQA root cause engine and returns a structured AI root cause analysis; use this as the first step in any failure investigation.

**Category:** AI Analysis | **Authentication required:** Yes

### Parameters

| Name          | Required | Type   | Description                            |
| ------------- | -------- | ------ | -------------------------------------- |
| execution\_id | ✅        | string | ID of the failed execution to analyse. |

### Returns

JSON with `rootCause` (a plain-English summary), `affectedStep`, `errorType`, `evidenceLinks` (screenshots, recording), and suggested remediation.

### Example

```json
{
  "execution_id": "exec_4d8f1a"
}
```

### Related Tools

`investigate_failure`, `get_ai_reasoning`, `get_test_step_results`, `create_defect_ticket`

***

## query\_repository

Queries a connected source code repository with a natural-language question and returns the most relevant code context and file references; use this to understand how the application under test is implemented before writing or debugging tests.

**Category:** AI Analysis | **Authentication required:** Yes

### Parameters

| Name         | Required | Type    | Description                                                  |
| ------------ | -------- | ------- | ------------------------------------------------------------ |
| question     | ✅        | string  | Natural-language question about the codebase.                |
| repo\_url    | ✅        | string  | URL of the Git repository to query (HTTPS or SSH).           |
| limit\_files | ❌        | integer | Maximum number of file references to return. Defaults to 10. |

### Returns

JSON with a `answer` string, a `files` array of relevant file paths with matched snippets, and a `confidence` score.

### Example

```json
{
  "question": "How does the checkout flow calculate shipping costs?",
  "repo_url": "https://github.com/example-org/storefront",
  "limit_files": 5
}
```

### Related Tools

`analyze_test_impact`, `generate_tests_from_code_change`, `analyze_test_repo`

***

## analyze\_test\_impact

Determines which existing test cases are affected by a set of changed files (and optionally changed functions), and returns a prioritised list of tests to rerun; use this in CI after a PR diff is known.

**Category:** AI Analysis | **Authentication required:** Yes

### Parameters

| Name               | Required | Type             | Description                                                                           |
| ------------------ | -------- | ---------------- | ------------------------------------------------------------------------------------- |
| changed\_files     | ✅        | array of strings | List of file paths that changed in the current diff, relative to repo root.           |
| changed\_functions | ❌        | array of strings | List of function or method names that changed. Improves precision of impact analysis. |

### Returns

JSON with `affectedTestCases` (array of test case objects with IDs and names) and `recommendedRerunIds` (array of integers ready to pass to `execute_test_case`).

### Example

```json
{
  "changed_files": [
    "src/checkout/ShippingCalculator.ts",
    "src/cart/CartSummary.tsx"
  ],
  "changed_functions": [
    "calculateShipping",
    "applyDiscount"
  ]
}
```

### Related Tools

`query_repository`, `generate_tests_from_code_change`, `execute_test_case`, `get_test_cases`

***

## Related documentation

[MCP tool reference overview](/mcp-server/tool-reference.md) · [Execution and results tools](/mcp-server/tool-reference/execution-and-results.md)


---

# 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/tool-reference/bug-defect-and-advanced.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.