Manual testing is great, but takes time and may not be as repeatable as you want. Eventually, some of your manual tests will be automated (Hopefully). TFS(Team Foundation Server) and VSTS(Visual Studio Team Services) both allow you to associate automation with manual test cases. This allows you to manually test when you need or want to, but, have the ability to run all automation associated with a test plan as a part of your CI/CD process. A good overview of how to link your test automation to a test case can be found here; Associate automated tests with test cases.
Below is a test case which I have associated with some automation.
Here is where I run the automation as part of my Release Process.
And a quick image of the test results.
Everything works great until I try to access the test case parameters from my automation, like I used to with TFS. In this case, I want to access X,Y, and R from my automation. I don’t want to hard code it or maintain a separate set of test data.
Normally I would use the datasource attribute on your test method and use Microsoft.VisualStudio.TestTools.DataSource.TestCase as the datasource. You can get more info here; (Creating a data driven coded UI test). However, the datasource doesn’t seem to know how to connect to\authenticate with VSTS. At least I haven’t gotten it to work.
Thankfully, VSTS has an easy to use Restful Interface. We can use this to look up our test case and grab our parameters.
I created a pretty simple helper class along with some samples to get your started. You can find them here; https://github.com/karlrissland/vsts-testcase-paramaccess. It should be pretty easy to follow. The sample leverages the Bing Calculator for some Selenium Testing. There is also a console app so you can focus on the rest calls.
To clarify a little, while I am using Appium as my associated automation and in my process, the github repository is using Selenium as more of a standalone demo. Figured it would be easier to work with than installing a client app, getting appium up and running, etc.
Also, I don’t see this as a perfect solution. Ideally I would want to create a custom data source provider so I could continue to leverage the DataSource attribute as described in the coded UI documentation linked above. On the other hand, if I am using another framework or technology that can’t use the DataSource attribute, then this is probably the approach.