Testcases with References to Inaccessible Shared Steps

Written by Maton Koen, ALM consultant at eXsertus


Recently we had an issue with test cases at the customer site. It wasn’t possible anymore to open some test cases in Test Manager 2010 or in Visual Studio 2010. We always encountered error TF26198: The work item does not exist, or you do not have permission to access it.

The first option of the error message was certainly not the case, because the impacted test cases appeared in the result lists of our queries. On top of that it was also possible to open those test cases in Web Access, but then we saw the error message in the test steps tab of the work item.

The second possibility was security related, so I checked all the security settings (also settings on area level). Nothing was changed to those settings recently, and it was still possible to open most test cases we had in the project. The permissions on the test cases itself could also not be the reason.


Because in Web Access we received the error only in the test steps tab when we opened the test case, we started looking into a     potential issue with test steps. After a while we discovered that we encountered two issues:

  • One test case referred to a shared step in another project and the user didn’t have sufficient rights to access that project. So indirectly the second part of the error message was valid for this one: the user didn’t have enough rights to access the shared step.
  • Some other test cases referred to a shared step that was deleted from TFS using command line. So in this case the first part of the error message was indirectly correct.

How to detect the root cause of this error message?

If you create a new query in visual studio to view the concerning test cases, you can add the Steps column to your results. The steps are listed in a raw format, including tags and references… You can find the referenced ID’s in this column. When you export this list to excel, the tags aren’t visible anymore, and the referenced shared steps are displayed as normal test steps. In the export you’ll not be able to see the referenced work item ID’s. So there is no way to fix this issue in excel.

How to fix the issue?

Because we had two issues, we also have to define two fixes.

The first one is an easy fix that can be applied when the shared step is in another project. There are several possibilities:

– Grant permissions to the user on the project that contains the shared step. (User can choose if he/she changes the test case so permissions can be removed afterwards)

– Ask the user to edit the test case under the account of someone with sufficient rights on both projects. The shared step can be replaced by normal test steps, or by another shared step in the same project as the test case.

Both changes can be executed in the UI, because if you have sufficient permissions there is no issue opening the test case in Visual Studio, Test Manager or Web Access.

The second fix is more complicated because you cannot open the test case in order to view the test steps. Therefor you cannot fix this issue in the UI, at least I didn’t find a way to fix it in the UI. Then how can it be fixed?

I fixed it directly in the TFS database. If you go to the database of the concerning TPC, you can edit the WorkItemLongText table. Click on the SQL icon and add a query to select all the items that contain the ID of the missing shared step. Now you can delete the references to that shared step directly in the database. Make sure you also delete the closing tags of those references.

As you can see, this is a risky fix, so I copied the original values to a text file first. Then I changed one test case, and tested if everything worked fine. If not, I could have copied the original value back into the table. Luckily for me the change was successful, so I continued changing and testing the other test cases.

If someone knows a better solution to this issue, please let me know, I’m really interested!

Good luck with this, and be careful.


eXsertus is specialized in the optimalization of development processes and custom development using Microsoft Technologies. We enable IT departments to contribute to a company's success by building integrated systems and solutions. Leveraging the power of .Net, SharePoint and Biztalk. Total solutions are defined, designed and delivered in close collaboration with you. We know that an important amount of budgets is invested in maintaining existing infrastructure and applications. That's why Application Lifecycle Management (ALM) principles are integrated in our methodology. We also provide consulting services to help you optimize the processes in your company. Our company invests a lot in training our consultants in the newest technologies and the latest Microsoft Certifications. As such eXsertus is a certified partner of Microsoft. Specialties Microsoft .Net, Microsoft SharePoint, Total Project Support, Application Lifecycle Management, New development methodologies, Define, Prepare and Realise migrations, Upgrade & Re-engineering processes, Technical expertise in Business Process Automation, BizTalk

Tagged with: , , , ,
Posted in ALM, Test Cases, Visual Studio

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: