If you’re looking to do some QA testing — or “manual testing” as Microsoft likes to call it — with Azure DevOps, you’re going to be spending a lot of time in the Test Plans hub. Since Team Foundation Server 2015, most of the QA/manual testing features have migrated to the web interface (they used to be in a desktop application), and the Test Plans hub is where you’ll find them all. But once you click into the Test Plans feature in Azure DevOps, you start seeing terms like Test Cases, Test Plans, and Test Suites. What are these things?
The Test Plans hub for an Azure DevOps Team Project
Like I said, stepping into the Test Plans for the first time can be a bit overwhelming. There are a lot of terms and a lot of mostly empty screens. You might even see a message that says “You can’t create test cases with a test plan.” Wait, what’s a test case? What’s a test plan? Aren’t they the same thing? Don’t worry, I’m here to clear up the confusion.
Test Plans
An Azure DevOps Test Plan is essentially a container for a testing effort. When you create one, you’ll be asked to choose an Area Path and an Iteration.
The Area Path is a concept that’s used in a lot of places around Azure DevOps and it allows you to keep things organized to specific parts of your Team Project. If you leave the Area Path blank (default value), it means that this Test Plan is available for the whole Team Project. If your Team Project is small or already pretty concentrated, this is probably your best choice.
The Iteration Path is another concept that’s scattered around Azure DevOps. It helps you to scope things to certain time periods and/or to certain releases or Sprints. If you’re using Scrum, this Iteration Path thing makes a LOT of sense because it helps you to connect your testing effort to the work that you’re doing in the current sprint.
Test Suites
Once you’ve created your new Test Plan, you have two options: 1) start creating Test Cases or 2) create one or more Test Suites. A Test Case describes the steps that a QA/manual tester should run (and the expected results) when testing a functional path through the application. The Test Plans hub is perfectly happy to have you create all your Test Cases directly off of your Test Plan…but this’ll get really messy really fast. That’s where Test Suites come in.
There are three types of Test Suite: Requirement-based, Query-based, and Static.
Requirement-based Test Suites
A Requirement-based Test Suite organizes your Test Cases by Product Backlog Item or User Story. If you’re doing Scrum, you’ll probably have a Requirement-based Test Suite for each of the Product Backlog Items (PBIs) that your team is taking on in this Sprint.
Query-based Test Suites
A Query-based Test Suite is driven by a Azure DevOps Work Item Query. This query doesn’t have to be constrained to just the current Team Project — the query can reference any Work Item that is stored in the current Team Project Collection (TPC). This is super helpful because it lets you run test cases that might not be directly related to your development effort.
Static Test Suites
Static Suites are basically just folders for your test cases. They’re fantastic for all the miscellaneous testing you need to do — especially for managing stuff like regression test suites for work that’s not related to new development work in this sprint. Have a bunch of test cases that you want to track that don’t neatly fit into a requirement-based suite or a query-based suite? Create a static suite and then just add the existing test cases in.
Summary
And there you have it! A quick tour of Test Plans, Test Suites, and Test Cases in Azure DevOps Test Plans. I hope this clears things up for you.
Happy testing!
-Ben
Looking for help getting your QA testing process streamlined with Azure DevOps? Need some tips for how to get your developers and testers working together as a team? Got a pile of test cases you need cleaned up and imported into Azure DevOps? We can help. Drop us a line at info@benday.com.
Leave a Reply