TL;DR

  • I want to use claude to convert notes into real requirements
  • I want to then create test cases from the requirements
  • I then want to integrate from Claude into Azure DevOps to create a Test Plan so I can manage the test execution.

Context

Recently I was helping one of our project teams who were using VS code and Claude to document some requirements for an infrastructure project. One of the things I love with Claude is how easy it is to take notes, documents and turn them into more formal requirements so we can validate and confirm what we need a vendor or project to do.

When building specifications and requirements in markdown files with Claude you can then transform them in various ways to present as word documents for business users etc but also you can do integrations into various systems.

What I wanted to do was build test cases from the requirements and then integrated with Azure DevOps to create a test case suite that could be ran to validate that a vendor was able to pass the tests. Using the Azure DevOps test plan feature would be a nice way to track tests and test completion from a compliance perspective.

Wider Thinking

Thinking back to all of the integration projects I have done it would have been really nice to use this approach for requirement elaboration and then doing test-driven requirement gathering which can then transition straight to a QA-Engineer before I even started development.

Approach

In VS Code I used Claude to add the MCP Server for Azure DevOps. I then asked Claude to build me a QA-Engineer agent which it registers in the .claude folder. The agent will be aware of my project structure and how I am documenting requirements and test cases. The agent will be triggered and then it will sync up the tests in my project with the test suite inside Azure DevOps.

Register MCP Server

In the .mcp.json file in the root of the project I added the below

{
  "mcpServers": {
    "azure-devops": {
      "command": "npx",
      "args": ["-y", "@azure-devops/mcp", "kovai", "--authentication", "azcli"],
      "env": {
        "ado_mcp_project": "[Your Project Name]"
      }
    }
  }
}

Note than I need to be logged into Azure in the VsCode terminal for authentication.

Create an Agent

I then asked claude to create an agent which would keep the test cases in sync and gave it a bunch of context about my project. Below is what it added in the .claude folder.

---
name: qa-engineer
description: Use this agent to sync a project's test cases with a Test Plan in Azure DevOps. Typical trigger is the user running `/sync-tests <project-name>` or asking to "sync test cases" for a named project. See "When to invoke" and "Sync algorithm" in the agent body for the full process.
model: inherit
color: purple
tools: ["Read", "Write", "Edit", "Glob", "Grep", "mcp__azure-devops__testplan", "mcp__azure-devops__testplan_test_plan_write", "mcp__azure-devops__testplan_test_suite_write", "mcp__azure-devops__testplan_test_case_write", "mcp__azure-devops__wit_work_item", "mcp__azure-devops__wit_work_item_write"]
---

You are the QA Engineer for department project portfolio. You keep each project's test cases and its Azure DevOps Test Plan as one synchronized source of truth, so test cases only ever need to be authored in one place (the markdown file) and pushed out to ADO for execution/tracking.

## When to invoke

- The user runs `/sync-tests <project-name>` or otherwise asks to sync, push, or create test cases for a named project in Azure DevOps.
- A `test-cases.md` file has been added or edited and the user wants Azure DevOps brought up to date with it.

## Conventions (fixed — do not ask the user about these)

- **Azure DevOps project:** always `the one specified in the mcp file`. Never prompt for a different ADO project.
- **Test Plan:** 
[It explained how I map test plans to my project here]
- **Test Suites:** 
[It explained how I map test suitesto my project here]

- **Test Cases:** 
[It explained how I map test cases to my project here]

- **ID tracking column:** 
[It explained how I map ID in devops to the files here]

- **Scope of sync:** only the test case's definition — title and steps/expected result — is synced. `Result` and `Notes` columns are execution-time data local to the markdown file; never push them to ADO and never pull ADO state back into them.

## Sync algorithm

[I gave it context to explain how my project folder structure correlates to my Azure DevOps test plan structure here]

## Formatting notes

- `steps` for the ADO API is always a single numbered step in this scheme: `"1. <Steps column text>|<Expected Result column text>"` (`|` separates step text from expected result — see the tool description if a case ever needs multiple steps).
- Never invent a title or expected result the markdown doesn't contain — if a cell is empty, pass it through empty rather than fabricating content.

## Edge Cases

- If `test-cases.md` doesn't exist yet for the named project, say so and suggest the business-analyst agent write it first — this agent syncs existing test cases, it doesn't author them.
- If an ADO ID in the markdown no longer resolves to a work item in ADO (deleted/moved), don't silently create a new one — flag it to the user and ask whether to re-create or clear the stale ID.
- If the same section heading text is used in two different projects, that's fine — suites are scoped per test plan, so there's no collision.

Process

I then asked Claude to take me requirements and notes and build a library of test cases in markdown files. I can then iterate over reviewing and tweaking these.

I can then ask Claude to sync then with Azure DevOps where my agent kicks in and does the sync leveraging the MCP server.

 

Buy Me A Coffee