In my last Identity Management Testing blog, we explored and highlighted the importance of testing, and the benefits doing this could bring to your organisation. This week, before we can start any testing, I want to focus on the tools we use to document and store test results.
So, before we get to running tests, we need to spend a little time documenting the tests we are planning to run.
What is Visual Studio Team Services?
Microsoft Visual Studio Team Services (VSTS) is a Team Foundation Server in Azure. If that still means nothing to you, think of it as a website which stores everything about the project you are working on, with the added benefit that it’s free (well, the first five users are free and then any additional users incur a cost). Not only does this tool allow us to track and manage our testing, it also manages the Tasks, User Stories and Source Codes.
If users want to create test cases, an additional license or Enterprise MSDN license is required. You can discuss this with your Microsoft software provider if you have any questions.
VSTS allows us to store what we are doing in order to deliver User Stories. Within those User Stories, we are able to define Acceptance Criteria, enabling us to create and link Acceptance Scenarios (Test Cases). The Test Cases that are created detail each step required to complete the test.
We can then run Test Cases, checking off each step as we pass or fail. If a step fails, you can record the reason for the failure and include any additional information involved.
Tests can be rerun and the history of each test can be viewed as often as required, so that a consultant can see whether a customer got any further the next time they ran a Test and the history of the issue.
I’m now going to run through a few steps showing you how you can add Acceptance Criteria to a User Story and create a Unit Test which is linked to the User Story. I will then test a couple of times to show it failing, and then pass and view the history.
I’ve logged into VSTS and navigated to my current list of User Stories.
By double clicking the User Story, the User Story will open up on your screen.
There is space here to enter a description of what the User Story is about. I find it useful to copy any design document contents here for reference.
In the Acceptance Criteria, we can list what they are. So, in this instance, we can add the following:
- Employee is present in AD
- User object created in Employee OU
We can then click to save the object, but we don’t want to close it yet as we need to add the Test Cases.
Now that the Acceptance Criteria has been added, we can add the Test Cases. For this demo, we are doing this all at the same time. Traditionally, there would be a gap whilst the Acceptance Criteria gets signed off by the project. Click the link tab to go to the links page.
This page shows us all the links the User Story has. Currently it has two Child Tasks linked to it and one Parent Feature.
To add the Test Case, click the Add Link button.
This popup will appear; we need to change the default options to the following values:
- Link Type: Tested By
- Work Item Type: Test Case
- Title: New User Created In HR, is Created in AD (A, B)
The title is the name of the Test Case – I put the Acceptance Scenario the Test Case is for in brackets at the end to remind me.
Click ‘Ok’ and the test case will be created.
We can now create the Test Case. I’m going to keep it simple for this blog, but there are many different options you can use to enhance the reporting and searching of items.
I add some steps to the Test Case, then it’s set up and ready to use.
Now to run the tests
Click on the Test Tab.
We can see the new Test Case we have created. To run it, we simply select it and click the run icon. Your web browser may block the popup from opening, so allow it to open and click again.
We are now able to run the test by ticking the checkbox. In this example, the New User did not get exported to the FIM Portal.
Save and close the Test Run, and the Test Plan will be automatically updated.
If we repeat this a couple of times, it will generate the test run history. Once you have done this, we can then assume it is fixed and ready to pass.
It now shows as ‘passing’ on the test page. If we open Test Manager, we can view the history of the test.
Right-click the Test Case and select view results.
At the bottom of the screen, we can see the history. If we select one of the failed attempts, the details will be displayed.
We can now see why this test failed previously. Going through this process could be a real benefit for any test that might have had similar issues in the past, e.g. a test that has been fixed and suddenly begins to have problems.
You should now know how to document what you’re going to test and how you can run through them. Hopefully, the benefits of using this tool have been made clear to you. I am aware there are other tools out there, but I find that having everything in one single place increases productivity and user experience. Assuming people working on the project have the correct MSDN license, there are no additional costs.
In our next Identity Management Testing blog in this series, we will go through how we can test Sync Engine rule extensions.
Interested in finding out more? Sign up to watch a recording of our recently held webinar on ‘Navigating the world of identity and access management’.