> 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/integrations/azure-devops.md). # Azure DevOps ## Quick answer How to connect ContextQA with Azure Boards to create work items from test failures and track bugs with full reproduction context. Use this page to understand when the capability applies, complete its user-facing workflow, and verify the expected result. ## What this page covers {% hint style="info" %} **Who is this for?** SDETs, developers, and engineering managers who use Azure Boards for issue tracking and want to push test failures directly as work items. {% endhint %} The ContextQA Azure DevOps integration connects test failures directly to Azure Boards work items. When a test identifies a bug, you can create an Azure Boards ticket with a single click. The ticket is pre-populated with the test description, reproduction steps, and a link back to the ContextQA result page so developers have everything they need to reproduce and fix the issue. ![ContextQA integrations catalog showing Jira, Slack, Linear, Azure DevOps, GitHub, Figma, test lab, and CI/CD options](/files/Lce3mB1cak8BySB2gEKU) *** ## Setting up the Azure DevOps integration ### Step 1: Generate a Personal Access Token in Azure DevOps 1. Open your Azure DevOps dashboard. 2. Go to your profile menu, select the three-dot menu, and choose **User settings**. 3. Select **Profile**, then navigate to **Personal access tokens**. 4. Click **New token**. 5. Give the token a clear name and set the permissions required — you can use **Full access** or limit permissions to Work Items (read and write) depending on your security policy. 6. Click **Create** and copy the generated token immediately. You will not be able to view it again after closing the dialog. ### Step 2: Enable the Azure DevOps plugin in ContextQA 1. In ContextQA, click the **Settings** icon in the left sidebar. 2. Navigate to the **Plugin** section. 3. Find **Azure DevOps Board** in the plugin list and enable it. ### Step 3: Enter your integration credentials 1. Paste the Personal Access Token copied in Step 1 into the access key field. 2. Enter your Azure DevOps organization URL (copy this from the address bar of your Azure DevOps portal, for example `https://dev.azure.com/your-org`). 3. Click **Create**. ContextQA verifies the credentials and confirms a successful connection. The integration is now active for all projects in your ContextQA workspace. *** ## Creating work items from test failures Once the integration is configured, you can report a bug to Azure Boards directly from any failing test result. ### Step 1: Identify a failed test case Open the execution result page for a failed test run. The failed step is highlighted with a red status badge, a screenshot, and an error message. ### Step 2: Start reporting a bug Click the **Report Bug** option in the test result toolbar. ### Step 3: Select Azure Boards as the destination When the bug reporting dialog opens, select **Azure Board** from the list of available integrations. ### Step 4: Fill in work item details * **Issue type** — select the work item type appropriate for your Azure project (e.g., Bug, Test Case, Shared Step) * **Title** — enter a clear title; ContextQA automatically pre-fills the test description and reproduction steps in the description field to save time ### Step 5: Save and sync Click **Save**. The work item is created immediately in Azure Boards and a direct link appears in the ContextQA result page. ### Step 6: Verify in Azure Boards Follow the generated link to open Azure Boards and confirm the ticket was created. The work item includes the full bug description, test step history, and all context provided by ContextQA. *** ## Managing the work item in Azure Boards Once the ticket is in Azure Boards: * Assign it to the responsible developer using the standard Azure Boards assignment workflow * Use Azure Boards sprint and backlog management to prioritize the fix * Update the ticket status as the fix progresses — the link in ContextQA continues pointing to the same ticket so QA engineers can monitor resolution *** ## Configuring project and area path When creating work items, ContextQA uses the organization and credentials provided during setup. If your Azure DevOps organization contains multiple projects, select the appropriate project in the work item creation dialog each time you report a bug. Azure Boards manages area path and iteration configuration according to your existing project structure. *** ## Azure Pipelines CI/CD integration Use an Azure Pipelines stage to coordinate a ContextQA test-plan run and require its result before deployment. Before configuring the stage: 1. Create and manually validate the test plan. 2. Open its **CI / CD** tab and confirm Azure DevOps is listed. 3. Obtain the current public start and status contract supplied for your workspace. 4. Create a dedicated [API token](/administration/api-tokens.md) with the narrowest required scopes. {% hint style="warning" %} The verified production **CI / CD** tab describes start and status operations but does not display public endpoint paths. Do not use older account-password or `/testplans/{id}/execute` examples, and do not copy internal URLs from portal network traffic. {% endhint %} In **Pipelines → Library → Variable Groups**, add the API token as a secret variable named `CONTEXTQA_API_TOKEN`. Store the test plan ID and the public base URL, when supplied, as non-secret variables. Authorize the variable group only for the pipelines that need it. When the public contract is available, the stage should: 1. Start the plan with the published method, path, and payload. 2. Capture the returned run ID. 3. Poll the published status operation with a bounded timeout. 4. Return a non-zero exit code for every documented non-success result. 5. Include the run ID in the job output so reviewers can find the run in ContextQA. Place the stage after the target environment is ready and before the protected deployment stage. Use environment approvals and checks when production requires an additional human gate. *** ## Traceability With both the Jira and Azure DevOps integrations in use, ContextQA can push bugs to whichever tracker your team uses. Each bug includes: * A link to the ContextQA result page with screenshots, video, and step logs * The reproduction steps generated by the AI * The test case name and ID for lookup in ContextQA This ensures that developers have enough context to reproduce the issue without needing access to ContextQA directly. {% hint style="info" %} **Connect ContextQA to your CI/CD pipeline in 15 minutes.** [**Book a Demo →**](https://contextqa.com/book-a-demo/) — See the full integration walkthrough for your existing toolchain. {% 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/integrations/azure-devops.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.