Is this the first time you've thought about testing? Is it something you push to the back of your mind?
Here, we explore why identity management testing is important, and how you can manage and automate it to become more efficient.
Identity management testing has always been a particular challenge for IT departments. It can sometimes be perceived as an unnecessary overhead, getting pushed towards the end of projects and rushed through at the last minute.
In the past, when we used Microsoft Identity Integration Server (MIIS) and Information Lifecycle Management (ILM), the solutions were limited to the Sync Engine and several connected systems. This meant all of the solution logic was in Visual Studio, which made it easy to build and then test at the end.
“Testing can no longer be thought of as a nice-to-have, or something that you can just fit in at the end.”
Forefront Identity Manager (FIM) then came along and introduced the Portal. This meant we had parts of the solution in two different places, with the portal allowing a lot more functionality. We went from small to medium identity management solutions, then to medium to large identity management solutions, where the approach to delivering MIIS and ILM solutions no longer works.
We now have code to test in the Sync Engine, and Workflows and Permissions to test in the Portal. Testing all of this functionality can no longer be left until the end of a development as there is so much to do. Regression testing, when adding new functionality, is now more important than ever.
Testing can no longer be thought of as a nice-to-have, or something that you can just fit in at the end. If you try this approach, the project will overrun, go over budget and require remediation afterwards.
View 'Microsoft identity stack demos: Overcoming typical challenges when setting up new user' and learn about:
When delivering a solution, testing needs to be the first thing on the agenda. It’s not just about making sure the solution is working correctly. When thinking about testing, ask yourself HOW exactly you are going to test and WHAT exactly you are going to test at the start of the project. This ensures both the consultant and the client have a comprehensive and cohesive understanding of the testing process.
Testing starts as soon as the design of the solution is complete, involving the key stakeholders agreeing on an Acceptance Criteria for the user stories. This enables the client and consultant to agree and be sure on what is going to be delivered, and what the outcome of that user story is going to be. Depending on how complex the user story is, that could mean four, five or even 25 Acceptance Criteria.
For example, an Acceptance Scenario for a new user could be “When a new account is created, a unique account name (five characters from surname + Initial + NN – must be unique – for example, SMITHJ01) is created.” When you write the tests, it is possible and normal for one test to cover more than one Acceptance Scenario.
Once the client has agreed the Acceptance Criteria, we are now in a position to get the Acceptance Scenarios written. These are tests written by the consultant, that go into detail about what attributes the initial object has and what attributes will be set at the outcome. The aim is to assess the life-cycle that object will go through in the production environment. The steps should include enough detail to enable anyone with a little identity management knowledge to follow. An Acceptance Scenario example might be a new employee in HR getting an account created in Azure Active Directory (Azure AD) with the correct attributes set, including account name, email address, manager, etc.
Test Scenarios are tests that confirm a small part of the functionality is working as expected. This test being passed does not mean an Acceptance Criteria is passed. An example of a Test Scenario could be that the Portal sets new account names correctly.
Once the Acceptance Scenarios and Test Scenarios are written, they are then reviewed by someone else on the team to confirm they have enough detail, ensuring that the Acceptance Criteria is covered.
We now have our tests up and ready to go. When we start developing the solution, as we complete each User Story, we can run these tests to confirm that what we have developed is going to meet the client’s expectations.
Ideally, the client will have someone who is creating their own Acceptance Scenarios to run once the development is finished, so that they can also test the solution and confirm it is working as anticipated. During this stage, the client can log any defects with the consultant, who can then resolve any issues that may have been identified.
Hopefully, this article has got you thinking about how you are going to best test your identity management solution and how you can reap the benefits of being pro-active.
There is, of course, an overhead to testing: capturing the Acceptance Criteria, creating the Acceptance Scenarios and Test Scenarios, running the tests and supporting User Acceptance Testing. However, that overhead could work out significantly less than a project that over runs and has defects in the production environment.
There are four key factors to an identity management project:
Next, watch the Microsoft identity stack demos to see how Microsoft’s key identity management technologies enable seamless user creation journeys.
Or download ‘The business case for IAM’ e-Guide and become the driving force behind modernisation, cyber security and operational efficiency in your organisation.
We'd love to hear from you! Our friendly team can be reached Monday through Friday, from 9am to 5pm.Contact Us
Eight-time winner of the Microsoft Partner of the Year Award for Identity Management, Enterprise Mobility, and Security and Compliance.
You are seeing this because you are using a browser that is not supported. The ThirdSpace website is built using modern technology and standards. We recommend upgrading your browser with one of the following to properly view our website:Windows
Please note that this is not an exhaustive list of browsers. We also do not intend to recommend a particular manufacturer's browser over another's; only to suggest upgrading to a browser version that is compliant with current standards to give you the best and most secure browsing experience.