Fix Azure DevOps Test Plans: Setup & Access Issues
Why This Is Happening
Here's a scenario I see constantly in enterprise teams: a developer or QA engineer opens Azure DevOps, clicks on the Test Plans hub, and gets either a blank screen, a greyed-out button, or a maddening "You don't have access" message. No error code. No explanation. Just a wall. I know how frustrating that is, especially when you're trying to meet a sprint deadline and the entire testing workflow is blocked behind a permission error nobody told you existed.
Azure DevOps Test Plans is a browser-based test management solution that covers manual testing, user acceptance testing (UAT), exploratory testing, and stakeholder feedback collection. It integrates deeply with Azure Pipelines for CI/CD automation. That depth of integration is exactly why things break in so many different ways , it's not just one system, it's half a dozen systems talking to each other.
The most common root causes I encounter break down like this:
- Wrong access level. Azure DevOps uses three access tiers, Stakeholder, Basic, and Basic + Test Plans. Most test plan creation and execution features require the "Basic + Test Plans" level. A user sitting at "Basic" will hit invisible walls constantly without understanding why.
- Missing Test & Feedback browser extension. Exploratory testing through the browser requires the Test & Feedback extension installed from the Visual Studio Marketplace. If it's missing or not connected in the right mode, your exploratory sessions won't save properly.
- Test cases not linked to user stories or requirements. Azure Test Plans depends on proper work item linking for traceability and reporting. If your test suites aren't associated correctly, the Progress Report widget will show incomplete or misleading data.
- Pipeline integration misconfiguration. Teams setting up automated test runs from the Test Hub often miss the step of associating test cases with a build pipeline definition, so automated runs never trigger, and the Results hub stays empty.
- Organisation-level settings overriding project-level permissions. An administrator may have disabled certain Test Plans features at the organisation level, which silently blocks everyone at the project level regardless of what individual permissions say.
Microsoft's error messages in this area are notoriously unhelpful. You'll see generic "access denied" toasts, or features that simply disappear from the UI without any indication of why. The official docs don't always make the connection between access levels and specific features obvious, so teams waste hours wondering if it's a bug rather than a licensing or configuration issue.
The good news: almost every Azure Test Plans problem I've seen is fixable without raising a support ticket. Work through this guide in order and you'll get there. Browse all Microsoft fix guides →
The Quick Fix, Try This First
Before you go deep into configuration, check the access level, it solves about 60% of Azure DevOps Test Plans issues on the first try.
An organisation administrator needs to do this. Ask them to open Organisation Settings (the gear icon at the bottom-left of the Azure DevOps interface), then navigate to Users under the General section. Find the affected user in the list and look at the Access Level column. If it says "Stakeholder" or "Basic", that's your answer right there.
To fix it, click the user's name, select Edit, and change the Access Level dropdown to Basic + Test Plans. Hit Save. The user should log out of Azure DevOps completely (not just refresh), wait about 60 seconds for the permissions to propagate, then log back in.
Here's a quick breakdown of what each access level actually gets you for testing:
- Stakeholder: Can browse test results and export test plans. That's essentially it for testing.
- Basic: Can perform exploratory testing with the Test & Feedback extension and run tests. Cannot create test plans or test suites, cannot manage configurations, cannot do UAT invitations.
- Basic + Test Plans: Full access. Can create test plans, test suites, manage run settings, manage configurations, perform UAT, everything.
If the access level is already "Basic + Test Plans" and the user still can't access features, move to the step-by-step section. You're dealing with a permissions or extension issue, not a licensing one.
If the quick fix above didn't work for a user, or you're dealing with a team-wide problem, do a systematic audit. This is the right starting point before touching anything else.
Navigate to Organisation Settings → Users. In the top-right of the Users page, use the Filter field and filter by "Access level: Basic". Export or screenshot the list. Now cross-reference against who is reporting Azure Test Plans issues. Any match is a confirmed access-level problem.
For bulk updates, Azure DevOps doesn't give you a great bulk-edit UI, so use the Azure DevOps REST API or the az devops CLI:
# Install the Azure DevOps CLI extension if you haven't already
az extension add --name azure-devops
# List users with their access levels
az devops user list --org https://dev.azure.com/YourOrgName --output tableThis outputs every user, their entitlement type, and their assigned licences. You can then use az devops user update to correct individual users programmatically instead of clicking through the UI one by one.
Once you've corrected access levels, have each affected user perform a hard refresh in their browser (Ctrl + Shift + R on Windows). If they're still seeing the old UI, clear browser cookies specifically for dev.azure.com, Azure DevOps caches entitlement data client-side and stale cache is a real gotcha.
You should see the Test Plans hub appear in the left navigation with all sub-sections (Test Plans, Progress Report, Parameters, Configurations, Runs, Test tools) accessible without greyed-out states.
If your team is trying to do exploratory testing and sessions aren't saving, bugs aren't being automatically linked, or the toolbar simply doesn't appear, the Test & Feedback extension is the culprit. This is a browser extension (Chrome and Edge are supported; Firefox is not) that you install from the Visual Studio Marketplace.
First, confirm the extension is actually installed. Open Chrome or Edge and go to the extensions manager (chrome://extensions in Chrome, edge://extensions in Edge). Search for "Test & Feedback". If it's not there, install it from the Visual Studio Marketplace, search for "Test and Feedback" and click the green Install button. You'll need to be signed into the Marketplace with the same Microsoft account used for Azure DevOps.
Installation alone isn't enough. This is the part most guides skip: after installing, click the extension icon in your browser toolbar (it looks like a clipboard with a checkmark). You'll see two modes, Connected and Standalone. You must use Connected mode to get full functionality including session saving, bug linking to test cases, and rich diagnostic data capture like screenshots and screen recordings.
To connect it, click the extension icon → Connected mode → enter your Azure DevOps organisation URL (https://dev.azure.com/YourOrgName) → select the relevant project and team. Once connected, the extension icon turns green. Now when you start an exploratory session, everything you capture, screenshots, action logs, video recordings, automatically attaches to bugs you file and links back to your test cases in the Test Plans hub.
If the extension keeps disconnecting or the icon stays grey after connecting, disable your browser's "block third-party cookies" setting for dev.azure.com, the extension uses session tokens that some privacy settings strip out.
Creating your first Azure Test Plans test plan should be straightforward, but there are a few configuration gotchas that trip teams up. Here's the clean path through it.
In your Azure DevOps project, go to Test Plans in the left navigation. Click the + New Test Plan button. Give it a name that reflects the iteration or feature, something like "Sprint 22, Checkout Feature". Set the Area Path to match your team's area and set the Iteration to the current sprint. These two fields matter for reporting: the Progress Report widget filters by area and iteration, so if you leave them as root defaults, your dashboards will pull data from the wrong scope.
Once the plan is created, you need test suites inside it. There are three types and picking the wrong one causes real problems later:
- Static suites, you manually add test cases. Good for regression packs that don't change sprint to sprint.
- Requirements-based suites, auto-populated from user stories or features linked via Azure Boards. This is the one to use if you want true requirements traceability. Select "Requirements-based suite", pick your user stories, and Azure Test Plans automatically creates corresponding test cases linked to those work items.
- Query-based suites, dynamic, driven by a work item query. Useful when you want a suite that always reflects the current state of "all P1 bugs" or "all test cases tagged regression".
If the + New Test Plan button is greyed out even with Basic + Test Plans access, check your project-level permissions. Go to Project Settings → Permissions, find your user or group, and verify that "Create test runs" and "Manage test plans" are both set to Allow. Organisation-level access is necessary but not sufficient, project-level permissions can still block specific actions.
One of the biggest value-adds of Azure Test Plans is end-to-end traceability, the ability to trace a requirement all the way through testing to a bug and a build. But this only works if your test cases are properly linked to user stories, features, or epics in Azure Boards. Skipping this step means your Progress Report stays empty and your requirement quality tracking is blind.
Here's how to wire it up correctly. Inside a test suite, select a test case and click Edit. Scroll down to the Links tab at the bottom of the work item form. Click Add link → Existing item. Set the link type to Tests (not "Related", the link type matters for traceability reports). Search for your user story by ID or title and add it.
For requirements-based suites, this linking happens automatically when you create the suite from a query of user stories, so use that suite type wherever possible. It saves you manual linking overhead on large test suites.
Once linked, you can verify the traceability chain from the Boards side: open a user story card on your board and look for the Tests tab in the work item detail panel. You'll see all associated test cases and their current pass/fail status directly on the card. This is the feature that lets product owners track quality without leaving the board view.
For automated test cases, there's an additional linking step: you need to associate the test case with the specific test method in your code. Open the test case, go to the Associated Automation tab, and select your build pipeline and the fully qualified test method name (e.g., MyApp.Tests.CheckoutTests.ValidateCouponCodeApplied). Without this association, automated runs triggered from the Test Hub won't map results back to your test cases, they'll just show as disconnected pipeline results.
If your Azure Test Plans setup is clean but automated test results still aren't appearing in the Runs hub or on your dashboard widgets, the pipeline integration is broken somewhere in the chain. Here's how to diagnose and fix it.
First, open your build pipeline definition in Pipelines → Pipelines and look at the task list. You need a Publish Test Results task configured after your test execution step. Without this task, the test runner produces results that live only in the pipeline log, they never get pushed to the Test Plans reporting layer. Add it like this:
- task: PublishTestResults@2
inputs:
testResultsFormat: 'VSTest' # or JUnit, NUnit, XUnit etc.
testResultsFiles: '**/*.trx'
mergeTestResults: true
failTaskOnFailedTests: true
publishRunAttachments: trueSet testResultsFormat to match your test framework. .NET projects produce .trx files (VSTest format). Python projects using pytest produce JUnit XML. Java projects using Maven produce Surefire XML (also JUnit format). Getting this wrong means the parser silently fails and produces zero results.
Second, if you want test runs to appear under a specific test plan in the Test Plans hub, not just floating as anonymous pipeline runs, you need to add the Visual Studio Test task (VSTest@2) configured with the Test Plan option, specifying the exact test plan ID and test suite IDs. Find those IDs in the URL when you have your test plan open: it looks like planId=42&suiteId=87.
After running the pipeline, check Test Plans → Runs. You should see a new run entry with pass/fail counts. If it's still empty after adding the publish task, check the pipeline run logs for any warning starting with "Test results publishing failed", this usually indicates a file path mismatch in the testResultsFiles glob pattern. Adjust the pattern to match where your test runner actually writes its output files.
Advanced Troubleshooting
If you've worked through all five steps and things are still broken, or you're in an enterprise environment with Group Policy and domain-joined machines, here are the deeper fixes I reach for.
Project-Level Permission Overrides
Organisation access levels are necessary but not sufficient. Project-level permissions can silently override them. Go to Project Settings → Permissions. Click on the relevant group (usually "Contributors"). Check these specific permissions are set to Allow and not Deny:
- Create test runs
- Delete test runs
- Manage test plans
- Manage test suites
- View test runs
A single "Deny" on any of these, even inherited through a group, will block the feature silently. Azure DevOps evaluates Deny before Allow in its permission model, so an inherited Deny cannot be overridden by an explicit Allow at a lower level without removing the Deny at the source.
Organisation-Level Test Plans Feature Toggle
Azure DevOps has a preview features and organisation-level feature toggle system. An administrator may have disabled Test Plans features globally. Go to Organisation Settings → Overview and look under Azure DevOps Services for any disabled features. Also check Preview Features (the flag icon in your user menu, top-right), some newer Test Plans capabilities sit behind preview flags and need to be enabled per-user or per-organisation.
Network-Level and Proxy Issues with Test Runner Client
The desktop Test Runner client (used for running tests with rich diagnostic capture outside the browser) communicates with Azure DevOps over HTTPS on port 443 but also uses WebSocket connections for real-time result streaming. Corporate proxies that don't handle WebSocket upgrades correctly will cause the Test Runner to hang on "Connecting..." or drop sessions mid-run. Check with your network team that *.dev.azure.com and *.vsassets.io are whitelisted for WebSocket traffic, not just standard HTTPS.
Analysing Test Run Failures in Event Viewer
When the desktop Test Runner crashes without a clear error, open Event Viewer (Win + R → eventvwr.msc) and navigate to Windows Logs → Application. Filter by source "VSTest" or "Microsoft.TestPlatform". Error IDs in the 8000–8100 range typically indicate .NET runtime version mismatches between the Test Runner client and your test assemblies. Installing the matching .NET SDK version resolves this without any other changes.
Analytics Service Data Delays
The built-in Progress Report and dashboard widgets for Test Plans pull from the Azure DevOps Analytics service, not live data. There's a processing delay, usually 30 seconds to 5 minutes, but in large organisations it can reach 30 minutes after a test run completes. If your dashboard looks stale immediately after a run, wait and refresh before assuming the pipeline integration is broken.
Prevention & Best Practices
Getting Azure DevOps Test Plans working is one thing. Keeping it working as your team grows and your project evolves is the harder challenge. Here's what I recommend teams build into their process from day one.
Establish a Licence Audit Cadence
Licence assignment drift is the #1 reason teams suddenly lose access to Azure Test Plans features. Every time someone leaves the team, their Basic + Test Plans licence should be immediately deallocated and reassigned to the replacement. Set a monthly reminder for an administrator to review Organisation Settings → Billing and compare purchased licences against assigned users. Unused licences sitting on departed employees are money wasted and licences unavailable to active testers.
Use Requirements-Based Suites as Your Default
Static test suites feel easier to set up but they decay quickly. Test cases pile up, nobody knows what's still relevant, and the suite becomes a graveyard of outdated scenarios. Requirements-based suites tied to user stories stay naturally pruned, when a story is closed or removed, its associated suite gets reviewed. This keeps your test coverage aligned with what's actually being built and keeps the Progress Report meaningful rather than noise-filled.
Make Publish Test Results a Non-Negotiable Pipeline Step
Add a pipeline template to your organisation's template library that always includes the Publish Test Results task. When every team inherits from this template, you guarantee that test results flow into Test Plans automatically, nobody has to remember to add it. Azure DevOps pipeline templates stored in a shared repository are the right tool for this kind of organisation-wide enforcement without requiring Group Policy.
Train Users on Connected vs. Standalone Mode
Every new team member who will do exploratory testing should be explicitly shown how to switch the Test & Feedback extension to Connected mode and point it at the right project. This takes 3 minutes. Without this step, new testers run exploratory sessions in Standalone mode, sessions don't save to Azure DevOps, and valuable bug information is lost permanently. Put it in your team onboarding checklist and never lose that data again.
- Set a monthly calendar reminder for your Azure DevOps admin to audit Test Plans licence assignments against active team members.
- Create a pinned wiki page in your Azure DevOps project documenting which test suite type to use for which scenario, reduces the wrong-suite-type mistake by ~80%.
- Add
publishRunAttachments: trueto every Publish Test Results pipeline task, this captures test output logs automatically and makes post-failure diagnosis dramatically faster. - Enable the Requirements Quality widget on your team dashboard to get live visibility into how many requirements have passing test coverage without opening Test Plans at all.
Frequently Asked Questions
What is Azure Test Plans and how does it work with the rest of Azure DevOps?
Azure Test Plans is the browser-based test management layer inside Azure DevOps. It handles planned manual testing, user acceptance testing, exploratory testing, and stakeholder feedback collection, all in one place. It connects directly to Azure Boards for requirements traceability (linking test cases to user stories), to Azure Pipelines for automated test execution and result collection, and to the Analytics service for dashboards and Progress Reports. Think of it as the quality control hub that sits between your backlog and your release pipeline, giving you visibility into exactly how well-tested each requirement actually is before it ships.
Why can't I create a new test plan even though I have access to Azure DevOps?
The most likely cause is your access level. Azure DevOps has three tiers, Stakeholder, Basic, and Basic + Test Plans, and the ability to create test plans requires "Basic + Test Plans". Having a Basic licence gets you into the Azure DevOps portal but silently blocks test plan creation. Ask your organisation administrator to check your access level under Organisation Settings → Users and upgrade it to Basic + Test Plans. If your access level is already correct, check your project-level permissions under Project Settings → Permissions, specifically "Manage test plans" must be set to Allow, not Deny or Not Set.
How do I run Azure Test Plans automated tests from the Test Hub rather than just from the pipeline?
To run automated tests directly from the Test Plans hub, you need to do two things: first, associate each automated test case with a specific test method in your code via the Associated Automation tab on the test case work item; second, configure a release pipeline (not just a build pipeline) that the Test Hub can trigger. Go to your test suite, select the automated test cases, and choose Run → Run with options. Select your release pipeline and stage from the dropdown. Azure Test Plans will queue a pipeline run, execute the tests in that pipeline environment, and report results back to the Test Hub, all without leaving the Test Plans interface. This setup is ideal for running regression packs on demand without writing pipeline trigger logic.
The Test & Feedback extension is installed but my exploratory testing sessions aren't saving, what's wrong?
You're almost certainly running in Standalone mode instead of Connected mode. Click the Test & Feedback extension icon in your browser toolbar and check which mode is active, Standalone sessions save locally only and never reach Azure DevOps. Switch to Connected mode, enter your Azure DevOps organisation URL, and select the correct project and team. If it keeps reverting to Standalone, your browser's cookie settings are blocking the session token that maintains the connection. Go to your browser's privacy settings and allow cookies from dev.azure.com and vsassets.io specifically. After doing that, reconnect the extension and your exploratory sessions will save, link to test cases, and let you file bugs with automatic screenshot attachments.
My Azure Test Plans Progress Report is showing outdated or blank data, how do I fix it?
The Progress Report pulls from the Azure DevOps Analytics service, which processes data asynchronously, not in real time. After completing test runs, give it 5 to 30 minutes before the report reflects the new state. If it's been more than an hour and the report is still blank or stale, check two things: first, verify your test plan's Area Path and Iteration are correctly set, the report filters by these fields and a mismatch means no data appears; second, check that your test results are actually reaching the Test Plans layer by visiting Test Plans → Runs and confirming completed runs appear there. If Runs is also empty, your pipeline's Publish Test Results task is misconfigured or missing entirely.
What's the difference between exploratory testing and manual testing in Azure Test Plans, and which should I use?
Manual testing in Azure Test Plans means running structured, pre-written test cases step by step, you follow a script that says "click this button, verify this outcome." It's ideal for regression testing where you need documented, repeatable coverage. Exploratory testing is unscripted: you use the Test & Feedback browser extension to freely explore the application, capture bugs, take screenshots, and record actions as you discover them. It's best for new features, UX review, and catching issues that scripted tests miss because they can't anticipate every user path. Most mature teams use both: structured manual tests for regression coverage and exploratory sessions for new feature validation. Azure Test Plans handles both in the same hub, which is one of its genuine strengths over standalone testing tools.