Azure Test Plans Tutorial with Real Project Example

Azure Test Plans is Microsoft's test management solution inside Azure DevOps. It handles the full manual testing lifecycle: writing test cases, organising them into suites, executing them through a guided Test Runner, tracking results over time, and generating reports. This tutorial walks through a complete test management setup for a real project.

---

Project context

Project: BookingHub — a hotel reservation SaaS application Team: 2 QA engineers, 5 developers Sprint length: 2 weeks Current sprint: Sprint 7 — New Features: Multi-room booking, Guest profiles

---

Creating the test plan

Navigate to Test Plans → + New Test Plan.

Name:      Sprint 7 — Multi-room Booking + Guest Profiles
Area:      BookingHub / QA
Iteration: BookingHub / Sprint 7
Start date: 2025-07-15
End date:   2025-07-28

A single test plan per sprint is the most common pattern. Some teams create separate test plans for regression vs new features — both approaches work, but one plan is simpler to manage.

---

Creating test suites

Inside the test plan, create three suites:

Sprint 7 Test Plan
  ├── Multi-room Booking (new feature)
  ├── Guest Profiles (new feature)
  └── Core Regression (existing functionality)

Multi-room Booking and Guest Profiles are Static Suites — you manually add test cases as you create them.

Core Regression is a Query-based Suite. Create it with this query:

Work Item Type = Test Case
AND Tags CONTAINS "regression"
AND Priority <= 2

This automatically pulls all regression test cases tagged as priority 1 or 2, keeping the regression suite current without manual maintenance.

---

Writing test cases for Multi-room Booking

User story: "As a travel agent, I want to book multiple rooms in a single transaction so that I can handle group reservations efficiently."

Test case 1 — happy path:

TC-301: Book 3 rooms of the same type in one transaction

Preconditions: Logged in as travel agent, hotel with 3+ available rooms selected

Steps:
1. Action: Set room count selector to 3
   Expected: UI shows 3 room configuration panels

2. Action: Fill check-in date (2025-08-01), check-out date (2025-08-03) for all rooms
   Expected: Price calculator shows: 3 rooms × 2 nights × £120 = £720

3. Action: Click "Book All Rooms"
   Expected: Single booking confirmation with booking reference BK-XXXXX,
             containing 3 room entries

4. Action: Check email
   Expected: Confirmation email sent with all 3 room details in one message

Test case 2 — negative/boundary:

TC-302: Attempt to book more rooms than available

Steps:
1. Action: Search for a hotel with 2 rooms available for selected dates
   Expected: Availability shows 2 rooms

2. Action: Set room count to 3 and click Book
   Expected: Error: "Only 2 rooms available for these dates"
             Room count selector resets to 2

Tag both test cases: multi-room, Sprint-7, regression (after the sprint closes).

---

Linking test cases to user stories

1. Open TC-301
2. Click the Links tab
3. Click Add link → Existing item
4. Link type: Tests
5. Search: type the user story number or title
6. Click OK

Repeat for TC-302. The user story now shows "2 test cases" in its Tests tab.

---

Executing tests with Test Runner

When development marks the multi-room feature as ready for testing:

1. In the test plan, select TC-301 and TC-302
2. Click Run → Run for web application (or "Run with options" to specify browser/device)
3. Test Runner opens in a side panel

In the Test Runner:

• Each step is displayed with its expected result
• Mark each step ✓ Pass or ✗ Fail
• Capture screenshots with the camera button (attached to the step)
• Add notes for context

When TC-302 step 2 fails (error message appears but room count does NOT reset):

1. Click Create bug in Test Runner
2. Azure DevOps pre-fills:
   • Title (from test case)
   • Repro steps (from failed step)
   • System info
3. Add: screenshot, actual behaviour description, environment (Chrome 125, Staging v2.3.1)
4. Set Priority: P2, Severity: 2
5. Assign to: dev responsible for the booking module
6. Click Save

The bug is automatically linked to TC-302 and the user story.

---

Using shared steps

The login sequence appears in 90% of test cases. Create a shared step:

1. Go to Test Plans → Shared Steps → + New Shared Step

Shared Step: Standard Login — Travel Agent

Step 1: Navigate to /login
        Expected: Login page displayed

Step 2: Enter email "travelagent@test.com", password "Test@2025!"
        Expected: Fields accept input

Step 3: Click Sign In
        Expected: Redirected to /dashboard with "Travel Agent" role indicator

In any test case, insert this shared step instead of rewriting the login steps. When the login flow changes, update the shared step once — all test cases update automatically.

---

Generating test reports

At sprint end, generate the test report:

1. Go to Test Plans → Progress Report (or specific plan → Progress tab)
2. Select the Sprint 7 test plan

The report shows:

Sprint 7 Test Plan Progress

Multi-room Booking:
  Total test cases:  8
  Executed:         8
  Passed:           7
  Failed:           1 (bug logged, P2, assigned)

Guest Profiles:
  Total test cases: 10
  Executed:         10
  Passed:           10

Core Regression:
  Total test cases: 24
  Executed:         24
  Passed:           24

Overall:            41/42 passed (97.6%)
Open bugs:          1 (P2)

Share this with stakeholders for sprint review. The 1 failing test case has a linked P2 bug — QA recommendation is to release with known defect, schedule fix for Sprint 8.

---

Common errors and fixes

Error: Test Runner doesn't open or opens but shows no steps Fix: Ensure test cases have steps added. An empty test case opens an empty Test Runner. Also check browser pop-up blockers — Test Runner may open in a blocked popup.

Error: "Access denied" when trying to create or edit test cases Fix: Requires Basic + Test Plans licence. Check licence assignment in Organisation Settings → Users.

Error: Shared steps not available in the "Insert Shared Step" dropdown Fix: Shared Steps are project-scoped. Ensure you're in the correct project and have created the shared steps in Test Plans → Shared Steps (not just as a work item).

Error: Bug created from Test Runner has wrong Area Path Fix: Set the default Area Path for bugs in your team's settings. The Test Runner inherits the work item defaults from your team configuration.

Error: Progress Report shows 0% even after running tests Fix: You must run tests through the Test Runner (not just mark them in the grid). Test Runner execution creates an official Test Run record that the Progress Report reads from.