Introduction

Test cases within Azure Dev Ops allow us to document the steps required to complete a set of actions, which prove whether or not an Acceptance Criteria is being successfully delivered.  For more information about User Stories and Acceptance Criteria, please see this article.

The steps in a test case go through the process required to create the fixture (Creating the object in the source silo), the steps to run to process the action (The schedule which processes the sync actions), before an assertion (The test in the target system) at the end to confirm the fixture has being processed correctly.

Some more complex test cases might have multiple fixtures and assertions in them. For example, where a user is a leaver, you might have a fixture to create them, an assertion to confirm they are enabled, another fixture to terminate them, and a final assertion to confirm they are disabled.

Test cases allow us to document these steps, and allow the tester to mark each step as passed or failed during the testing process.

You can create them directly within a test plan.

Or you can create them directly in Work Items: 

Structure

While both of the above approaches work, they make things more complicated in the long run and do not provide any structure. We want to be able to quickly identify test cases associated with a user story. 

Tags

The second approach to structuring Test Cases is to use the Tags feature within Azure Dev Ops. Tags allow us to use queries to filter work, finding items related to each other more efficiently. They become more important when we are creating test cases, as the Test Suites can be query based.  For more information on tags, click here. Example of Tags could be:

• HR
• Contractor
• New Starter
• Leaver
• Manual
• Automated
• Regression

Instructions

The guide below goes through the process of creating Test Cases, ensuring they are linked to a User Story. It also covers how to create a copy of a test case, to reduce time spent documenting similar test cases.

Once we have created our test cases, we can then create our test plans. The test plan creation process is covered further in this article. Click here to view.

Step	Image
Log in to Azure Dev Ops, and find the User Story your adding the test cases for. This can be done from the Backlogs item.
Select the user story, by clicking on it.
On the right hand side, under Related Work, click Add Link
Select New Item
Change the Link type to Tested By.  Work Item Type should change to Test Case (If it does not, update it as well)
Add the title, describing what Test Case is testing. Preifx the name with the number of the acceptance criteria this test is validiating. This makes it easier when the test case is being reviewed for the reviewer to confirm the test case covers the expected acceptance criteria. In our example, we are testing the account is created in AD, so we could call the test: 1,2 - New Starter in HR Created in AD
We can now click Add Link
Before we add the steps, we need to add the tags. The Tags are used to create the Test Plans dynamically.  By creating the test plans dynamically, we can re-use existing test plans in the future, this is mainly used for regression testing. An example of what a Tag might be: HR, New Starter, AD, Regression, Manual, Automated. You can create as many Tags as you like, but it is best to try and avoid duplicates such as NewStarter and New Starter as this will cause issues with the dynamic test plans. As part of the review process, the tags should be reviewed and validated.
We can now add the steps as required. When discussing creating a user in a system, it can be tempting to include a list of all the attributes.  This can look untidy in the reports, and also increase the number of steps that need to be processed, so this can be kept tidier by adding the attributes of the HR record as an attachment.
Once the test steps are added, we can now save the test if we do not require further similar test cases.
If you have similar tests where the attributes vary, but the steps are similar, you can copy this test case by clicking the down arrow, and choosing save.
You can now click on the eclipse button and select Create copy of work item...
Select include existing links, and if you included attachments, tick that checkbox as well.
Now click Copy . This will create a copy of the test case, which can not be edited as required
Click Save and Close (And close any other test cases which are still open) to go back to the User Story. Under related work, we can now see that we have a link from the user story to the test case. (If you created multiple tests, you will need to click the refresh button to see them all appear.)

Once the test case has been completed, there should be a review process which takes place.  It does not have to be someone who understands the solution or has technical knowledge of the solution.  They are looking to review the tags make sense, and the steps in the test plan are clear and easy to follow.  They are also checking that the Acceptance Criteria which the test case is testing, are correctly covered.