How to Create Test Cases in Azure DevOps, Sprint by Sprint

It's day 8 of a 10-day sprint. Half the stories are "in testing", the test cases don't exist yet, and the acceptance criteria say something like "user can reset password". Someone opens Azure Test Plans for the first time this sprint and starts writing steps from memory.

Most guides on how to create test cases in Azure DevOps show you where the buttons are. That part is easy. The hard part is when: getting test cases written early enough that they shape the work instead of trailing behind it.

In this post I walk through how test plans, suites and test cases fit together, how to create them step by step, and a sprint cadence that ties each testing artifact to a ceremony your team already holds. I'll also show where I use ClearSpecs AI, the extension I build for Azure DevOps, and where I deliberately don't.

Why test cases end up at the back of the sprint

The mini-waterfall inside a two-week sprint

Scrum says "done" includes tested. In practice, a lot of teams run a small waterfall inside every sprint: build for seven days, test for three. Test cases get written when the tester finally picks up the story, which is exactly the moment they are least useful. Bugs found on day 9 either spill into the next sprint or get waved through with a comment.

Untestable acceptance criteria

The root cause usually sits upstream. A test case is only as good as the requirement it verifies. If the acceptance criteria say "the page loads quickly" or "errors are handled properly", nobody can write a pass/fail step against them. So the tester waits for the developer to explain what was built, and the test case ends up describing the implementation instead of the requirement.

Fix the acceptance criteria and writing test cases becomes almost mechanical. Keep that in mind, because the rest of this post depends on it.

How test artifacts fit together in Azure DevOps

Test plans, test suites and test cases

• Test case: a work item with steps, each step an action and an expected result. A test case lives on its own and can appear in many suites.
• Test suite: a group of test cases inside a plan.
• Test plan: the container for a testing effort, scoped to an area path and an iteration.

Because plans reference test cases rather than copying them, editing a test case updates it everywhere it's used. Only clone test cases when you need a frozen baseline, for example for a release audit.

Requirement-based, query-based and static suites

• Requirement-based suites are tied to one user story or product backlog item and pull in every test case linked to it with a Tested By link. This is the suite type that makes sprints work.
• Query-based suites are driven by a work item query, for example every test case tagged smoke.
• Static suites are manual groupings. Useful for regression sets you curate by hand.

Licensing: what Basic can and can't do

Before you design a process, check who can actually do what. According to Microsoft's overview of permissions and access for manual testing, full test case management (creating and managing test plans, suites and test cases) requires Basic + Test Plans or a qualifying Visual Studio subscription. Users with Basic access can run tests and record outcomes. Stakeholders can't open the Test Plans hub at all.

This matters more than it sounds. If only your QA engineer holds the Test Plans license, every test artifact funnels through one person, and that person becomes the sprint's bottleneck. Decide upfront who needs the license, and design the cadence below around that.

Creating test cases step by step

From the backlog with Add test

The fastest route, and the one that fits refinement best: open the context menu on a work item in your backlog, choose Add test, enter a title and add steps. The new test case is linked to the story, so it's ready for a requirement-based suite later. Use this for quick drafts while the story is still fresh in everyone's head.

In the Test Plans hub

Open your test plan, select the requirement-based suite for the story and choose New Test Case. For many test cases at once, switch to Grid view and paste title, action and expected result columns straight from Excel. Only multiline formatting survives the paste, so keep your spreadsheet plain. Microsoft's guide to creating manual test cases covers each screen in detail.

A typical test case for a password reset story looks like this:

1. Open the login page and select "Forgot password". Expected result: Reset form is shown.
2. Enter a registered email address and submit. Expected result: Confirmation message is shown, reset email arrives.
3. Open the reset link after 25 hours. Expected result: Link is rejected as expired.

Shared steps and parameters

Two features that save a lot of rework:

• Shared steps for sequences you repeat everywhere, like "log in as a standard user". Change them once, every test case picks it up.
• Parameters for data-driven tests: the same flow with different inputs, run as separate iterations. The rule of thumb: iterations are for different data, not different workflows. If the flow changes, write a separate test case.

A sprint cadence for test cases

This is the part most guides skip. Here is where each testing artifact gets created, mapped to ceremonies you already run.

Backlog refinement: testable criteria and draft titles

Aim for two outputs per story:

1. Acceptance criteria that are independently verifiable, ideally in Given/When/Then form.
2. Draft test case titles, one or more per criterion.

Titles alone are fine at this stage. "Reset link expires after 24 hours" is both an acceptance criterion and a test case title. If the team can't name a test for a criterion, the story isn't ready. I'd add exactly that to your Definition of Ready.

Sprint planning: one test plan, one suite per story

Create a test plan for the sprint with the iteration set to that sprint. Copy last sprint's plan to skip the setup work, as described in Microsoft's documentation on creating test plans and suites. Then add a requirement-based suite for every story the team commits to.

Now your test plan mirrors the sprint backlog one to one. Any story without test cases shows up as an empty suite, which is a far louder signal than a missing line in a spreadsheet.

During the sprint: run early, log bugs, keep links intact

• Run test cases as soon as a story reaches the test environment, not in a batch at the end.
• When a step fails, create the bug from the test runner so it links back to the test case and the story.
• Protect the Tested By links. A test case that isn't linked to its story is invisible to the requirement-based suite, and invisible test cases don't get run.

Definition of Done and the sprint review

Add "all linked test cases pass" to your Definition of Done, and make it more than a line on a wiki page. With my Checklist extension for Azure DevOps, you can attach a Definition of Done checklist template to every user story and block the transition to Done until the checklist is complete. I wrote more about that setup in Make "Done" Mean Done in Azure DevOps Boards. At the sprint review, the test plan's progress report gives you a per-story view of what was actually verified.

After the sprint: promote to a regression suite

The sprint plan stays behind as a historical record. The living asset is your regression suite. After each sprint, promote the test cases worth keeping into a static regression suite, or tag them regression and use a query-based suite. Be ruthless: a test case that verified a one-time data migration doesn't belong there.

Where ClearSpecs AI fits (and where it doesn't)

I built ClearSpecs AI because I kept running into the same pattern: the tooling in Azure DevOps was fine, the work items were the bottleneck. Test cases are where that hurts most. Here is how I use it in the cadence above.

Tighten acceptance criteria with shared prompt templates

ClearSpecs AI lets you define prompt templates centrally in the Boards area, each with its own instructions and a target field. For this workflow I use one that targets Acceptance Criteria with instructions along these lines: rewrite as Given/When/Then, make each criterion independently verifiable, and list open questions separately instead of guessing.

During refinement, anyone on the team applies the template from the work item form, previews the result and decides whether to keep it. For one-off cases there's a writing mode where you pick the field and type your own prompt. The point isn't prettier text. It's that every story ends up with criteria in the same testable structure, which is what makes the next step reliable.

Bulk-generate Test Case items from the story

Once the criteria are solid, I open the work breakdown tab on the story, choose Test Case as the target work item type and add a short instruction, for example "one test case per acceptance criterion, include the negative paths". ClearSpecs AI proposes a set of test cases based on the story's content. I edit the ones that need it, toggle off the ones I don't want, and create the rest in one go.

The generated test cases are linked to the story with Tested By, so they show up directly in the requirement-based suite you created during sprint planning. No re-linking, no orphaned test cases. The agentic chat can propose test cases too, and it always shows the proposed create actions for review before anything is written to your project.

Use the chat to check sprint items for gaps

Because the agentic chat queries live work items, I use it mid-sprint as a second pair of eyes: ask which stories in the current sprint have thin acceptance criteria, or open a single story and ask which edge cases its criteria don't cover. Treat the answer as a prompt for a conversation, not a verdict. The suites in Test Plans remain the source of truth.

What I still review by hand

An AI that gets a vague story will write confident, plausible and wrong test cases. That's why the order matters: criteria first, test cases second, human review always. Specifically, I check:

• Business rules the model can't know, like a legal retention period or a customer-specific exception.
• Test data and environments, which live outside the work item.
• Overlap with existing regression tests, so the suite doesn't grow duplicates.
• Anything security-related, where a missed negative path is expensive.

If sending work item content to an external model is a problem for your organization, ClearSpecs AI also has an offline tier that runs fully air-gapped with a model of your choice.

Mistakes I keep seeing

• One giant test plan for the whole project. You lose the per-sprint signal. Create one per sprint and keep a separate regression suite.
• Test cases linked the wrong way. Parent/Child or Related links don't feed requirement-based suites. Use Tested By.
• Steps that describe the UI instead of the behavior. "Click the blue button in the top right" breaks every redesign. "Submit the reset form" doesn't.
• Only the licensed tester writes test cases. Drafting titles in refinement is a team activity, even if one person finalizes them in Test Plans.
• Never pruning the regression suite. A suite nobody trusts is a suite nobody runs.

Conclusion

Creating test cases in Azure DevOps is a few clicks. Making them useful is a matter of timing. The cadence that works:

• Refinement: testable acceptance criteria and draft test case titles.
• Planning: a test plan per sprint with a requirement-based suite per story.
• During the sprint: run early, log bugs from the runner, keep Tested By links intact.
• Done: all linked test cases pass, enforced rather than hoped for.
• After: promote what's worth keeping to regression.

The slowest step in that list is almost always the first one: turning a rough story into criteria you can actually test, then into test cases. That's the step ClearSpecs AI was built for. It runs inside Azure Boards, the free tier needs no credit card, and you can try it on a single story in your next refinement session. Install ClearSpecs AI from the Visual Studio Marketplace and see what your acceptance criteria look like after one pass.

Frequently asked questions

Do I need a Test Plans license to create test cases in Azure DevOps?

For full test case management, yes. Creating and managing test plans, suites and test cases requires the Basic + Test Plans access level or a Visual Studio subscription that includes it, while Basic users can run tests and record outcomes. Check Microsoft's manual testing access overview for the exact matrix before deciding who needs a license.

Should we create a new test plan every sprint?

Yes, if you work in sprints. A test plan scoped to the sprint's iteration, with a requirement-based suite per story, shows exactly which committed work has been verified. Copy the previous sprint's plan to save setup time, and keep long-lived tests in a separate regression suite.

What's the difference between acceptance criteria and a test case?

Acceptance criteria state what must be true for a story to be accepted. A test case describes the steps and expected results that prove a criterion holds. Good criteria map almost one to one onto test case titles, which is why fixing the criteria first makes test cases much faster to write.

Can AI write test cases for Azure DevOps?

It can draft them, and it's genuinely fast when the acceptance criteria are clear. With ClearSpecs AI you can generate a set of Test Case items from a user story, review and edit them, and create them in bulk, linked to the story with Tested By. You still need a human review for business rules, test data and security edge cases the model can't know about.

How do I link a test case to a user story in Azure DevOps?

Use a Tested By link from the story to the test case. Creating the test case with Add test from the backlog, from inside a requirement-based suite, or through ClearSpecs AI's child item generation sets this link for you. Avoid Parent/Child or Related links for test cases, because requirement-based suites only pick up Tested By.