Azure DevOps for QA Engineers: Complete Beginner Guide (2025)

Azure DevOps is Microsoft's end-to-end platform for planning, building, testing, and delivering software. For QA engineers, it's one of the most complete environments available — it combines test case management, CI/CD pipelines, work item tracking, and source control under a single roof. If your team runs on Azure, understanding Azure DevOps isn't optional — it's a core competency.

This guide walks you through everything a QA engineer needs to know to get productive in Azure DevOps from scratch.

---

What Azure DevOps is (and isn't)

Azure DevOps is not a single tool — it's a suite of five integrated services:

Service	What it does
Azure Boards	Work item tracking: user stories, tasks, bugs, epics
Azure Repos	Git repositories for source code
Azure Pipelines	CI/CD automation: build, test, deploy
Azure Test Plans	Manual and exploratory test case management
Azure Artifacts	Package management: NuGet, npm, Maven, PyPI

As a QA engineer, you'll primarily work in Azure Test Plans (writing and running test cases), Azure Boards (logging bugs and tracking requirements), and Azure Pipelines (integrating automated tests into the CI/CD process). Understanding all five helps you see how quality fits into the overall software delivery workflow.

---

Setting up your first Azure DevOps project

1. Create a free account

Go to dev.azure.com and sign in with a Microsoft account. The free tier includes:

• Unlimited private repositories
• 1,800 pipeline minutes per month
• 5 free users for Azure Test Plans
• Unlimited stakeholder access (read-only)

2. Create an organisation and project

When you first sign in, you'll be prompted to create an organisation (your company or team namespace) and a project inside it. Choose:

• Version control: Git (always choose Git for new projects)
• Work item process: Scrum or Agile (Scrum is common for QA-heavy teams)
• Visibility: Private

Your project URL will be: https://dev.azure.com/{organisation}/{project}

3. Configure your team

Go to Project Settings → Teams. Add yourself and your QA colleagues. Teams in Azure DevOps control which backlogs and boards each group sees — having a dedicated QA team lets you customise views around testing work without cluttering the developer board.

---

Understanding the QA workflow in Azure DevOps

Here's how a typical QA workflow maps to Azure DevOps services:

Requirements defined (Boards: User Stories)
        ↓
Test cases written (Test Plans: Test Cases linked to User Stories)
        ↓
Test execution (Test Plans: Run test cases manually or via pipeline)
        ↓
Bugs raised (Boards: Bugs linked to failed test cases)
        ↓
Automated regression (Pipelines: Run test suite on every commit)
        ↓
Reports and metrics (Boards: Dashboards, Test Plans: Test Reports)

Each step lives in a different service, but they're connected: a bug you raise from a failed test case is automatically linked to that test case, the user story it covers, and the pipeline run that triggered it.

---

Azure Boards for QA engineers

Azure Boards is where requirements live and bugs are tracked. As a QA engineer, you'll interact with it in three main ways:

Viewing user stories and acceptance criteria

User stories (in Scrum) or Features (in Agile) contain the requirements you're testing. Always read the acceptance criteria section before writing test cases — this is what you're validating.

Creating bugs

When you find a defect during testing:

1. Click New Work Item → Bug
2. Fill in: Title, Reproduction Steps, Expected Result, Actual Result, System Info
3. Set Priority (1–4) and Severity (1–4)
4. Assign to the developer responsible
5. Link to the test case that found it

Querying work items

Use the Queries section to build saved views. A useful QA query: all bugs in the current sprint assigned to your team, grouped by severity. Save this as a chart on your team dashboard.

---

Azure Test Plans basics

Azure Test Plans is the dedicated test management module. The hierarchy is:

Test Plan (e.g., "Sprint 12 Regression")
  └── Test Suite (e.g., "User Authentication")
        └── Test Case (e.g., "Login with valid credentials")
              └── Test Steps (step-by-step actions)

Creating a test plan

1. Go to Test Plans in the left sidebar
2. Click + New Test Plan
3. Name it (e.g., "Sprint 12 — Payment Module")
4. Select the Area Path and Iteration

Creating test cases

1. Inside a test suite, click + New Test Case
2. Add a title that clearly describes what's being tested
3. Add test steps: Action → Expected Result pairs

Good test step example:

Step 1: Action: Navigate to /checkout and click "Place Order" with an empty cart
        Expected: Error message "Your cart is empty" displayed
Step 2: Action: Add one item to cart, navigate to /checkout, click "Place Order"
        Expected: Order confirmation page displayed with correct order number

---

Running your first manual test

1. Open a test suite, select one or more test cases
2. Click Run → Run for web application
3. The Test Runner opens alongside your application
4. Work through each step, marking Pass ✓ or Fail ✗
5. For failures, click Create Bug — it pre-fills the test case title and steps

The test result is automatically saved against the test case, building a history of pass/fail over time.

---

Common errors and fixes

Error: "You don't have access to Test Plans" Fix: Test Plans requires a Basic + Test Plans licence. Go to Organisation Settings → Users and assign the correct licence to your account.

Error: Test cases not appearing in a pipeline's test results Fix: Your automated test runner must publish results in a format Azure DevOps understands (JUnit XML, NUnit XML, TRX). Add a PublishTestResults task to your pipeline YAML.

Error: Bugs created from Test Runner are not appearing on the sprint board Fix: Check that the bug work item type is included in your team's backlog settings. Go to Project Settings → Team Configuration → Backlog levels.

Error: "No test runs available" on the Test Plans dashboard Fix: Test runs are created when you execute test cases through the Test Runner or pipeline. Running tests locally without reporting to Azure DevOps won't create runs. Use the Test Runner for manual tests and add result publishing tasks for automated tests.

---

What to learn next

Now that you understand the basics, the logical progression is:

1. Test case management — link test cases to requirements for traceability
2. Azure Pipelines — run your automated tests in the CI/CD pipeline
3. Dashboards — build QA metrics views for your team

The following articles in this series cover each topic in depth, with step-by-step examples and YAML configurations for common automation frameworks.