Azure DevOps Terminology Explained for Testers

Azure DevOps has its own vocabulary. Developers who've worked with CI/CD tools before pick it up quickly. QA engineers coming from dedicated test management tools like TestRail, Zephyr, or Xray often find the terminology confusing — the same concepts have different names, and some Azure DevOps concepts have no direct equivalent in traditional QA tools.

This glossary explains every term you'll encounter as a QA engineer, in the context of testing work.

---

Azure DevOps core concepts

Organisation

The top-level container in Azure DevOps. Usually maps to a company or department. Your organisation URL is https://dev.azure.com/{org-name}. All projects, users, and billing live under an organisation.

Project

A container for a single product or codebase. Contains its own Boards, Repos, Pipelines, Test Plans, and Artifacts. Most companies have one project per product. QA engineers typically work inside one project but may have read access to others.

Area Path

A hierarchical tag that organises work items by product area or team. For example: ShopFlow / Frontend / Checkout. Your team's Area Path filters what appears on your board and dashboards. Make sure your test cases and bugs use the correct Area Path or they won't appear in the right place.

Iteration Path (Sprint)

A time-boxed period (sprint) defined as a path. For example: ShopFlow / Sprint 18. Work items assigned to a sprint use its Iteration Path. This is how the sprint board knows what to show.

Process Template

The schema defining work item types and workflow. Common templates:

• Scrum: User Stories, Tasks, Bugs, Impediments
• Agile: User Stories, Features, Bugs, Issues, Epics
• CMMI: Requirements, Change Requests (formal/enterprise)

Most modern teams use Scrum or Agile. QA engineers work with User Stories (requirements) and Bugs in both.

---

Azure Boards terminology

Work Item

The generic term for any item tracked on a board. Includes: Epics, Features, User Stories, Tasks, Bugs, Test Cases, Test Plans, Test Suites.

Epic

A large body of work spanning multiple sprints. Example: "Payments Module Overhaul". QA rarely creates Epics but may link test plans to them for portfolio-level visibility.

Feature

A deliverable component of an Epic. Example: "Apple Pay Integration". Test Plans can be linked to Features to show coverage at the feature level.

User Story

A requirement expressed as: "As a [role], I want [goal] so that [benefit]." The primary unit of work in a sprint. QA engineers link test cases to User Stories for traceability. Acceptance Criteria is the key field — it defines what "done" means for testing purposes.

Bug

A work item type representing a defect. In Azure DevOps, a Bug can behave either like a Task (on the task board) or like a User Story (on the backlog) depending on your team's settings. QA engineers raise Bugs and verify them after resolution.

State

The current lifecycle position of a work item: New → Active → Resolved → Closed (for Bugs), or New → Active → Closed (for Tasks). QA engineers move Bugs from Active to Resolved to Closed as they verify fixes.

Tag

A free-text label applied to any work item. QA teams often use tags like regression, P1, exploratory, blocked to filter and group work items in queries.

Query

A saved filter that retrieves work items matching specific conditions. Example: Work Item Type = Bug AND Sprint = @CurrentIteration AND Assigned To = Me. Queries can be displayed as charts on dashboards.

---

Azure Test Plans terminology

Test Plan

The container for all test work in a given context (sprint, release, or feature). Each Test Plan has a Name, Area Path, and Iteration. A team typically creates one Test Plan per sprint.

Test Suite

A folder inside a Test Plan that groups related test cases. Three types:

• Static: manually curated collection of test cases
• Requirement-based: automatically populated by linking test cases to a work item
• Query-based: dynamically populated based on a work item query

Test Case

A work item type (unlike in other tools, it's a first-class work item with an ID). Contains title, test steps, expected results, and can be linked to requirements. Test Cases are reusable — the same test case can appear in multiple test suites across multiple test plans.

Test Step

An individual action-expected result pair inside a test case. Steps can be marked Pass or Fail during test execution. Failed steps automatically suggest bug creation.

Shared Step

A reusable block of test steps that can be inserted into multiple test cases. Useful for common actions like login or navigation that appear across many test cases. Updating a Shared Step updates it everywhere it's used.

Shared Parameter

A data table that feeds variable values into test steps. Enables data-driven manual testing — one test case runs with multiple data sets. Example: a login test case using a shared parameter table with 10 username/password combinations.

Test Run

An execution record created when test cases are run through Test Runner or a pipeline. Contains the date, environment, tester, and results for each test case in the run. Stored permanently for historical comparison.

Test Configuration

The environment context for a test run: browser, OS, device type. Allows the same test case to have separate results for Chrome/Windows vs Safari/macOS.

Test Point

The intersection of a Test Case and a Test Configuration within a Test Suite. If you have 10 test cases and 2 configurations, you have 20 test points. This is the unit that Azure DevOps tracks execution status against.

---

Azure Pipelines terminology

Pipeline

An automated workflow defined in YAML (or the classic visual editor). Triggered by events (commits, pull requests, schedules). QA engineers interact with pipelines primarily to monitor test results and investigate failures.

Stage

A major phase of a pipeline. Common stages: Build, Test, Deploy. Stages can run sequentially or in parallel.

Job

A collection of steps that run on a single agent. Multiple jobs can run in parallel within a stage.

Step / Task

The smallest unit of a pipeline. A Task is a pre-built action (like PublishTestResults@2); a Script step runs inline shell or PowerShell commands.

Agent

The machine (virtual or physical) that runs pipeline jobs. Microsoft-hosted agents are ephemeral VMs spun up for each run. Self-hosted agents are machines you manage, useful when tests need a specific environment or local network access.

Trigger

The event that starts a pipeline. Common triggers:

• CI trigger: runs on every push to a branch
• PR trigger: runs when a pull request is opened or updated
• Scheduled trigger: runs on a cron schedule (e.g., nightly regression)

Artifact

The output of a pipeline stage — compiled code, test results, published packages. Pipeline artifacts persist after the run and can be downloaded for investigation.

Service Connection

A stored credential that allows a pipeline to connect to an external service: Azure subscription, Docker registry, Kubernetes cluster, test cloud (BrowserStack, Sauce Labs). QA engineers often need Service Connections for test environment access.

Variable / Variable Group

Named values used in pipeline YAML. Variable Groups are stored in Library and can be shared across multiple pipelines — useful for environment URLs, credentials, and configuration that changes between test environments.

Environment

A named deployment target (Dev, Staging, Production) tracked in Azure Pipelines. Environments support approval gates — a pipeline can be configured to pause before deploying to Production until a QA engineer manually approves.

---

Common errors and fixes

Error: Work items from a different team appear on your board Fix: Check your team's Area Path filter in Team Settings. Your board only shows work items matching your team's area path.

Error: "Test Plan not found" when trying to link a pipeline to Test Plans Fix: The pipeline must have the testPlanId field set in the PublishTestResults task, or the test run title must exactly match an existing test plan name.

Error: Bugs created from Test Runner don't appear on the sprint board Fix: The Bug's Iteration Path must match the current sprint. Test Runner sometimes defaults to the root iteration — check and update after creating the bug.

Error: Shared Steps are greyed out and can't be edited Fix: Shared Steps are separate work items. Open them from Test Plans → Shared Steps (not from inside a test case) to edit.

---

Quick reference card

Term	Azure DevOps equivalent
Test Suite (TestRail)	Test Suite
Test Run (TestRail)	Test Run
Test Cycle (Zephyr)	Test Plan
Test Execution (Xray)	Test Point
Defect (generic)	Bug (work item)
Pipeline (Jenkins)	Pipeline
Job (Jenkins)	Stage → Job
Build Step (Jenkins)	Task
Environment variable	Variable / Variable Group
Credential store	Service Connection