How to Reuse Test Steps and Test Cases in Azure DevOps

Do you know how many times you changed a test case in Azure DevOps and did not know that there were 2 other test cases with the same steps (so called “clones”), that you should have changed, too? Do you know how many false test executions and bugs in production were caused by these inconsistencies? 

And even worse: There was no way for you to avoid this, because you were not aware of those clones a colleague of you introduced one year before. And even if you knew, you would have had to adapt every single occurence of the test step in multiple test cases. 

Without tools such as the Qualicen Scout, there is only one way to avoid these quality and maintenance issues in manual test suites: You have to avoid clones in Azure DevOps before they become a problem. 

But Andreas, how do I do this? Keep calm, grab a cup of coffee or – in my case tea – and open Azure DevOps. 😉

Avoid clones in these 4 scenarios

There are 4 different scenarios where clones arise. Let’s have a look at the scenarios before I will give you a step-by-step guide on how to avoid these clones in Azure DevOps.

Scenario 1: Cloning a test plan for a new release

This is the first scenario and also the most common one: Let’s say you released the previous release and now you want to create a new test plan in Azure DevOps for the new release. So far so good, but please: Do not copy the old test plan with all the test cases! This would create a clone of each test case in your Azure DevOps project. 

Why is this a problem? You would have now multiplied the number of test cases that you need to manage. And so, what happens when 2 years from now a colleague wants to reuse a test case regarding your great search function and searches Azure DevOps for “Search bar”? He will find 2, 3 or even 10 results all with the same name. How would he know what is the most recent version of this test case? Or even worse, the newest version of the test case has a new name and won’t show up in the search results at all. This is only one situation, where this lack of overview through cloning is really a problem.

How to avoid 1:1 clones

When you want to create a new test plan form the basis of an old test plan, be careful which cloning option you choose.

Instead of the option “Duplicate existing test cases” please use the option “Reference existing test cases”. Now, each test case exists only once, which is less confusing, easier to maintain and less error-prone. This is how easy it is. Okay, let’s have a look at the next situation:

Scenario 2: Different Test Data

The second most common situation: You want to test your login functionality for different accounts and you write your first test case. For example this one:

Now, you want to test the tester account and you write a second test case which looks like this:

But wait, know we have nearly a 1:1 clone of the test case, except for the test data. Why is this a problem? Let’s say your login form now also has a required checkbox to agree with the data policy, before the login. You would have to adapt this in both test cases :/. Wait, there must be a better way to do this! Don’t worry, I will show you how in the next section.

Use Parameters

I bet, when you started to create the second test case, you began to duplicate the Admin-Test Case and just change the test data or you copied the steps into your new test case.
Everytime you duplicate or copy & paste, you should ask yourself: “Is there a better solution for that?”
There is! In Azure DevOps you can use parameters to create placeholders, which can be filled with different test data.

So let’s start with our ‘Admin Login’ test case:

We know that every test step is the same for the ‘Tester Login’ test case except the username ‘admin’ and the password ‘test’. These are the points, where we have to insert parameters as placeholders for different test data. To create a parameter start typing ‘@’ or use the ‘[@]’ button at the top of the test case:

Give the parameter a meaningful name. In my case, I named the parameter ‘username’. Now, we have to remove the value from the test step and add this to the parameter table, which is showing up below the test case:

Now, we replace each occurrence of the username value ‘tester’ with the parameter. In this case, this happens only once in the Expected Result of Step 3. And I also create a new parameter ‘password’ and add the value ‘testing’ for that parameter to the parameters table:

And now the magic happens. Instead of having to duplicate and search & replace the parameters, all we need to do is add them to the parameters table of the test case. Each line in the parameters table will now lead to a new execution of the test case during testing. ADO will automatically execute the test case two times and will fill in the correct parameters combination each time (I will show you the execution later in the post). For the tester it looks like there were two separate test cases, but to the delight of our financial department, we only have to maintain one!.
Since the test case now does not only test the ‘tester’ login but also the ‘admin’ login, we now need only one instead of two test cases. So, I renamed it to ‘Login for different users’ and got rid of the Admin test case:

Great, this is how to avoid duplicated test cases for different test data. But, what if we want to test a new settings menu after log-in our colleagues developed in Iteration 2?

Scenario 3: Repeating similar steps into multiple test cases

Next situation: You now have released the first iteration with your new log-in functionality, but now you want to test the new settings menu of iteration 2. This menu link is only available if you are logged in. So in your test case you want to define, that the tester has to log-in in the beginning of each test case for the settings menu.
Easy thing, you just copy the first 5 steps of our test case ‘Login for different user’ in the beginning of each of these test cases for the settings menu. But wait! Do you remember the last situation, where you would have to adapt both test cases because of the new checkbox in your log-in form? Such a change would lead to the same problem here, because you have to find and adapt each test case where a log-in is required for testing your settings menu. And of course there is a better solution for that in Azure Devops.

Create shared steps

Okay, we know that we start each test case of the settings menu with the same 5 steps that are already defined. How can we reuse them, so that we have to maintain them only once?

This is the point where the next functionality of Azure DevOps comes into play: Shared steps. The idea of shared steps is to collect a number of steps that are similar for multiple test cases into a new work item type ‘shared steps’. These shared steps can then be referenced into each test case where these steps are required.

So let’s start with creating a shared step work item out of the first 5 steps of our test case “Login for different users”. Go into the test case, where the steps exist, that you want to reuse in another test case, mark them with shift+click and click on the ‘Create shared steps’ button:

In the next dialog, you have to give them a name:

Now, click on ‘create’ and you will see your old test case ‘Login for different users’:

Yet you see only one step which says Scout Login. As you can see on the bold font, this is just a link to the shared steps work item, which we created a few seconds ago. Below the test steps you also see the table of your parameters, which will be inserted in the parameter placeholders of the shared step during execution.
If you want to see the shared steps work item you can double click on the bold font or on the linked shared step work item on the right side under ‘Related Work’:

As you can see, here are the steps with the parameters but with an empty parameter values table. Why? Because the parameters are filled by the test case that uses these shared steps. I will show you this with our example of two different test cases, depending on the user who is logged in. Let’s say, only an admin can access the settings menu and the tester has no access to the settings menu. 

In the next dialogue, click on ‘run query’:

Let’s start with the settings page test case for the admin. Here I created a new test case called ‘Settings menu for Admin’:

Since we want to insert the shared steps for the login click on the ‘Insert shared steps’ button. In the next dialogue, click on ‘run query’:

Select the shard Step ‘Scout Login’ and hit ‘Insert shared steps’.

Now, we want to test if the admin has access to the settings menu. Therefore I create a second step, where I expect that the settings menu is shown. Since I only expect that for the administrator, I add only the login data for the admin to the parameters table:

This way, the test case will only be executed once for the admin. 

Scenario 4: Similar steps in multiple test cases with different test data

In the situation above you can see that we have a test case that uses shared steps for the login and tests if the admin has access to the settings menu. But we said that we also want to test, that the tester has no access to the settings menu. Yes, we could simply create a second test case for this, but – yes of course – this would end up in a new clone of the existing test case. But what could we do instead?

Use Parameters for both, shared steps and test case

Now, we combine parameters in a shared step with parameters in a test case. Trust me, that sounds more difficult than it is from here. We already have shared steps that use 2 parameters for the login. I will now add a new parameter called ‘settings menu state’ which represents the status of the settings menu after the user has clicked on the ‘settings’ button:

I also already added the correct state for the admin ‘is shown.’ to the parameters table. To test the prohibited access for the tester, we have to enter only one new line in the parameter values:

As you can see, I also renamed the test case to ‘Settings menu access’, since we now test access for both admin and tester.

Test execution

Here comes the fun part! Now, we will execute the test case. I already created a test plan for the second iteration:

When you click on run, the test case will be executed two times:

As you can see, the first 5 steps are automatically inserted from the shared steps work item and the parameters are drawn for each line of the parameters table in an own test execution.

Summary

I showed you 4 different scenarios and how to avoid cloning in these situations. As a rule of thumb: Every time you write the same steps in your manual tests, ask yourself: “is it possible to use parameters and/or shared steps to avoid cloning?”. Use shared steps for steps that you need in several test cases and use parameters for different test data within the same test flow. And ‘BAM!’ you only need to maintain a handful of test cases. Time saved, money saved and just overall better test cases.

Would you like to know more about shared steps, parameters or anything else about testing in Azure Devops? Let me know in the comments, contact me via linked in or send me an e-mail at andreas.horn@qualicen.de.