How to Create and Manage Test Cases in Azure DevOps

Test cases in Azure DevOps are more powerful than a simple checklist — they're full work items with history, links, parameters, and reuse across multiple suites. This guide covers everything from writing your first test case to managing a suite of hundreds.

---

Test case anatomy

A test case work item has these key fields:

Field	Purpose
Title	Short, descriptive name of what's being tested
Steps	Action → Expected Result pairs
Priority	1 (highest) to 4 (lowest) — controls execution order
State	Design → Ready → Closed
Assigned To	The tester responsible for execution
Area Path	The product area this test case belongs to
Tags	Free-text labels for filtering and grouping
Parameters	Variables for data-driven testing
Links	User stories, bugs, other test cases
Attachments	Wireframes, spec docs, reference screenshots

---

Writing effective test cases

The title formula

A good test case title follows this pattern:

[Context] — [Action] — [Expected outcome]

Examples:

✓ Checkout — Apply expired discount code — Shows "Code has expired" error
✓ Login — Submit with empty password — Password field validation message shown
✓ Profile — Upload 5MB image file — Rejected with "Maximum file size is 2MB"

✗ Test discount code    (too vague)
✗ Login test 1         (no information)
✗ Check if upload works (doesn't state the expected result)

Step quality

Each step must be independently executable with no assumed knowledge:

Bad step:
Action: Test the login
Expected: Works correctly

Good steps:
Step 1:
Action: Navigate to https://staging.app.com/login
Expected: Login page displayed with email field, password field, and Sign In button

Step 2:
Action: Leave both fields empty and click Sign In
Expected: Validation messages appear: "Email is required" and "Password is required"

Step 3:
Action: Enter "not-an-email" in the email field and click Sign In
Expected: Validation message: "Please enter a valid email address"

---

Parameterised test cases

Parameters let one test case run with multiple data sets. This is Azure DevOps's equivalent of data-driven testing for manual tests.

Creating parameters

In the test case, click Parameters tab and add:

Parameter	Values
email	admin@test.com, member@test.com, viewer@test.com
expectedRole	Admin, Member, Viewer

In the test steps, reference parameters with @parameter_name:

Step 1: Navigate to /login
Step 2: Enter @email and password "Test@2025!" and click Sign In
        Expected: Dashboard displayed with role indicator showing @expectedRole

When you run this test case, the Test Runner will prompt you to choose which parameter row to use, or run all rows in sequence.

Shared parameters

If the same parameter set is used across multiple test cases:

1. Go to Test Plans → Parameters
2. Create a shared parameter set: Login Credentials
3. Reference it from any test case

This is especially useful for login credentials, test data IDs, and environment URLs.

---

Shared steps

Shared Steps are reusable blocks of steps. Common candidates:

• Login as specific user type
• Navigate to a specific page
• Set up test data (create an order, add to cart)
• Clean up after test (delete created records)

Creating a shared step

1. Test Plans → Shared Steps → + New Shared Step
2. Add steps as normal

Shared Step: Add item to cart

Step 1: Search for "Laptop Pro X" in the search bar
        Expected: Product appears in results

Step 2: Click on the product and click "Add to Cart"
        Expected: Cart count increments by 1

Inserting a shared step into a test case

1. In test case step editor, click Insert shared steps
2. Search by title
3. The steps expand inline during editing but run as a single unit in Test Runner

---

Bulk operations

When managing large test suites, bulk operations save significant time.

Bulk edit

1. In a test suite, select multiple test cases using checkboxes
2. Click Edit in the toolbar
3. Update fields (Priority, Assigned To, Area Path, Tags) for all selected

Bulk add to a suite

1. In a test suite, click Add test cases using query
2. Write a query: Type = Test Case AND Tags CONTAINS "checkout"
3. All matching test cases are added to the suite

Export to Excel/CSV

1. In a test suite, click Export → Export to Excel
2. Test cases export with all fields — useful for offline review or sharing with stakeholders who don't have Azure DevOps access

---

Test case versioning

Every time you save a test case, Azure DevOps creates a new version. This is crucial for auditing:

• When the test case was last changed
• What changed (steps, expected results)
• Who changed it
• Whether the change happened before or after a particular test run

Access version history: open a test case → History tab.

If a test run from last month used an older version of a test case, the run's results reflect the steps as they existed then — not the current version. This is important for compliance and audit trails.

---

Organising large test suites

For projects with hundreds or thousands of test cases:

Use consistent tagging

Establish a tag taxonomy:

By type:    regression, smoke, exploratory, performance
By area:    checkout, auth, search, profile, admin
By sprint:  sprint-7, sprint-8 (when first written)
By status:  needs-update, deprecated, high-risk

Requirement-based suites for traceability

Instead of manually curating suites, use requirement-based suites. Link test cases to user stories. Create a suite for each Epic or Feature using a query:

Test Case linked to Feature #245 (Checkout Redesign)

As user stories under that feature are written, their linked test cases appear automatically.

Archive instead of delete

When a test case becomes obsolete (feature removed, replaced by automation):

1. Set State to Closed
2. Add tag deprecated
3. Add a comment explaining why

Don't delete — the test case's history and links to past bugs are valuable for regression analysis and audit.

---

Common errors and fixes

Error: "Cannot edit test case — read only" Fix: You need at least Basic + Test Plans licence to edit test cases. Stakeholder licence is read-only for Test Plans.

Error: Shared steps not updating across test cases after editing Fix: Changes to shared steps are immediate. If test cases show old steps, try refreshing. If Test Runner shows old steps, close and reopen the runner.

Error: Test case appears in the wrong suite Fix: Test cases can belong to multiple suites. If a test case appears in an unexpected suite, it was added there explicitly. Remove it from the suite — this doesn't delete the work item, only removes it from that suite.

Error: Parameter values not available in Test Runner Fix: Parameters must be set in the Parameters tab of the test case, and the test must be run with "Run with options → Select data rows" to choose which parameter set to execute.