In this week’s article, we discuss the concept of test automation in IAM environments. Designed to minimize the business risk associated with releasing new software, test automation is frequently used to discover code that could negatively impact the client user experience. While popular in the software development lifecycle, we think that it, in a modified incarnation, has a place in operational environments as well. We are of the belief that regular automated testing provides the best method for guaranteeing that the IAM infrastructure is working as expected.
As we see it, IAM test automation would involve 3 steps: creating the tests (and test data, if necessary), executing the tests , and reacting to the test results. Below we explore each of the aforementioned steps.
There are generally two approaches for developing operational tests: automated (via a recorder) or manually (using a scripting or programming language). Using a recorder accelerates the development of your collection of tests, but customization of the test will have to done using scripting or programming. For instance, customization is needed to support HTTP cookies and HTTP headers that are session specific.
On the other hand, programmatic test development provides the greatest amount of flexibility, but also requires technical resources with the appropriate programming skills. Certain web service or API use case development will also require programming because recorders are designed to capture the requests from browsers.
Regardless of the test creation approach that is used, establishing a method to validate responses for each test step is crucial. Advanced test cases can leverage out-of-band resources such as databases, web services, email, or custom interfaces to validate responses that are returned during a test step. The results of the step or use case validation will determine if that portion of the test was successful or not.
Two components are needed to run a test without user intervention: a test engine and an orchestration tool. Luckily, there are tools on the market that can fulfill both roles.
The test engine is responsible for executing tests and capturing the results of each step of a use case. The engine is also responsible for interacting with the target system in the same manner that a web browser would. Depending on the situation, a test automation solution may require one or more test engines, with the number of test engines determined by the load test or test engine geolocation requirements. The orchestration tool, on the other hand, is responsible for managing the execution of the tests, plus generating and distributing the reports that are created.
The primary goal of IAM test automation is to ensure that the user experience over the full identity lifecycle remains consistent across releases. The success criteria developed as a part of the test creation step will be used to determine if a step or use case has executed successfully. Additionally, if the solution is designed to provide load testing capability, certain criteria (such as response time) can be used in the test case success criteria.
One final note: when developing a test automation solution, make sure to clearly define how the solution will be used and to establish a flexible test creation approach. If testing in different environments, it is best if your solution does not require significant changes when switching between them.
As always, we hope that you have found this information useful. If you need IAM assistance, reach out to SIS today and we would be happy to assist you. And subscribe to our newsletter to be notified about the posting of future articles and other SIS news.