In this tutorial, I will walk you through the end-to-end process of writing manual test cases in Azure DevOps. We won’t just cover the “clicks”—we will cover the strategy behind them.
How to Write Manual Test Cases in Azure DevOps
Understanding the Azure Test Plans Hierarchy
Before we start typing out test steps, we must understand the container structure. Many QA engineers make the mistake of diving straight into creating test cases without a proper skeleton. In Azure DevOps, the hierarchy is strict and specific.
Think of it like a physical filing cabinet:
- Test Plan: The filing cabinet itself. This usually represents a specific Sprint, a Release, or a major Milestone (e.g., “Sprint 24 Test Plan” or “Release 1.0 Master Plan”).
- Test Suite: The drawers or folders within the cabinet. These group your test cases logically (e.g., “Login Module,” “Payment Gateway,” or “User Story 101”).
- Test Case: The individual documents inside the folder. These contain the actual instructions (steps) to verify a specific behavior.
The Three Types of Test Suites
Understanding the suite types is critical for SEO-friendly organization and reporting. I use different suites for different purposes:
| Suite Type | Description | Best Use Case |
| Requirement-based Suite | Pulls test cases linked to a specific work item (User Story or Epic). | Agile workflows where you need to verify specific acceptance criteria for a story. |
| Query-based Suite | Dynamically pulls test cases based on a query (e.g., “All Priority 1 tests”). | Regression testing or finding all tests with a specific tag (e.g., “SmokeTest”). |
| Static Suite | A manual folder where you drag and drop test cases. | Custom grouping or ad-hoc test runs that don’t fit a specific requirement. |
Prerequisites for Manual Testing in ADO
Before I can write a single case, I always ensure my permissions are correct. You cannot access the “Test Plans” module with a standard “Basic” license alone.
- Access Level: You need Basic + Test Plans access level or a Visual Studio Enterprise subscription.
- Project Permissions: You must have “Edit” permissions in the specific Area Path of your project.
Step 1: Creating Your First Test Plan
The first thing I do is establish the root container.
- I navigate to the Test Plans icon (it looks like a test tube) on the left sidebar.
- I click on New Test Plan.
- I name it clearly. I recommend a naming convention like
[Project Name] - [Sprint/Release] - [Test Type].- Example: “AcmeCorp – Sprint 45 – Functional Testing”
- I select the Area Path and Iteration. This is crucial. If I select “Sprint 45” as the iteration, this plan will show up on the boards for that specific sprint, keeping the developers and product owners aligned with my testing progress.
Check out the screenshot below for your reference.
Step 2: Structuring with Requirement-Based Suites
I rarely use Static Suites for new feature work. In an Agile environment, traceability is king. If a stakeholder asks, “Is the ‘Forgot Password’ story tested?”, I need to show them the link immediately.
To do this, I create a Requirement-based Suite:
- I click the three dots (…) next to my new Test Plan.
- I select New Suite > Requirement based suite.
- A query window pops up. I enter the ID of the User Story I am working on, or I query for all “Active” User Stories in the current iteration.
- I select the stories I want to test and click Create Suites.
Check out the screenshot below for your reference.
