Azure Test Plans: Test Cases

I have helped many clients understand how to use Microsoft Test Manager and now Azure Test Plans over the past 10 years that these tools have been around.

People are often asking for best practices. I thought it might be useful to write a couple of articles that outline some of the basic best practices I follow when integrating the QA team into Azure Devops.

I am going to be referring to User Story a fair bit. When I say User Story I am also referring to Product Backlog Item for those of you using the Scrum Template or Requirement for those using the CMMI template.

Lets start with Test Cases.

Writing a test case is pretty simple, although there are four fields on a Test Case people don’t seem to take seriously in my experience.

• Title: Give it a title that tells people what is being tested.
• Assigned To: Set the Assigned To field to the author so people know who to come to if there are questions.
• State: Set the State properly. The State is different then on other work item types. Work management work items like Epic, Feature, User Story and Task all have a limited life. They start out as New, and Closed or Done mean we did the work and it’s complete. A test case can live for as long as it’s useful. It has 3 states. Design: Not ready, still under construction, Ready: Ready to be executed as part of a test plan, Closed: Obsolete, don’t run me, the app has changed and I am no longer useful. I am here for history only.
• Steps: Fill out the steps as you would in any tool. Writing a good test case is not the focus of this article so I will trust you know how to write a good test case.

Now what to do with the test case once it’s written. We need to attach it to the work item that is being tested. Generally this would be at the Feature or User Story level. My preference is the User Story. Assuming you follow the rules that a Feature is a business or stakeholder view of a change to the system. User Stories are how we break that down. One Story should be testable, fit into a sprint and be assigned to only one team. However if it makes more sense to execute manual tests at the feature level when they are delivered then so be it, you can attach them to the feature and what I am about to tell you will still work fine. However for the purpose of this article lets assume we are attaching them to the User Story.

The Test Case must be attached using the Tests/Tested by relationship. If you open a User Story and click on add link, make sure you select the Link type: Tested By. I see a lot of people adding Test Cases as children, this does nothing for you.

Anyone who looks at the work item can see how we are validating it in the related work section. See how important a good title is now?

Conversly if you look at the Test case you can see what it tests.

An even easier way to do this is from the KANBAN board. Go to your teams KANBAN board click on the ellipsis on the work item you want to add a test case to, and you will see a menu item called Add Test. This will add a test with the correct relationship quickly and easily by only entering the title. The “Assigned To” will be set to you and the state will be Design. You can then come back later fill in the steps and change the state to Ready.

Think of a grooming session where the team is going over the Stories in the backlog. You can quickly and easily start adding thoughts of what manual tests will need to be written for this Story.

As the Story moves along the board and you begin executing the tests Azure Devops will report test results right here also.

In the next article we’ll talk about creating a test plan to execute and report results for the tests we have added to our User Stories.