Superuser & Test Automation for Roles and Permissions
CenterTest’s role-based testing accelerates InsuranceSuite development by using superuser for functional testing and then using those same tests to verify permissions – a feature missing in Guidewire’s GT framework.
When testing modern, enterprise-level software, roles and permissions are integral components that define how users interact with the system. Permissions dictate whether specific actions are authorized, while roles are collections of permissions that define the actions users can perform. For example, permissions might control whether a role can create a policy or copy a job. Essentially, roles are assigned to users to manage access within the system.
Each role serves a distinct purpose. For instance, administrators oversee system management and configuration, while customers engage with the product or service. In more specialized systems, such as Guidewire InsuranceSuite, additional roles come into play. You might have producers handling submissions and policy creation, underwriters assessing and approving risks, claims adjusters managing claims processing, and billing managers dealing with payments and invoicing.
Understanding these roles is critical for ensuring that the software behaves as expected, as each role determines the specific actions a user can perform and the restrictions they face. This alignment of roles and permissions helps maintain the integrity and security of the system, ensuring that users can only perform actions appropriate to their responsibilities.
For example, while a producer can create a policy, they cannot bind the policy if there are outstanding underwriting holds because they should not have permission to do so. For the purposes of testing and development, this is not critical to know unless the team is explicitly testing permissions.
This article discusses permission testing, the role of superuser and their associated risks, and how CenterTest accelerates development by using superuser for testing and then using those same tests for permission verification.
API and UI Testing
API testing is done using specific service endpoint IDs or tokens, not your application user IDs. For example, when you attempt to retrieve an MVR record through the front-end (UI), once you are authorized to make the call, the service ID or token is used to perform the actual MVR retrieval, not your user ID. Therefore, API testing falls outside the scope of this article since it is unrelated to user IDs, roles, and permissions.
Unlike API testing, UI (User Interface) testing requires logging in with specific users tied to roles within the system. These roles determine the permissions and, thus, actions the users can perform. Ensuring that the correct user has only the necessary permissions to access the appropriate features is crucial for properly testing the system’s security measures.
In complex systems like InsuranceSuite, identifying the correct user for each test can be challenging, especially when roles and permissions are still evolving. This requires careful planning and collaboration with developers and business analysts to ensure accurate and effective testing.
Moreover, complex real-world scenarios may require verifying actions across multiple roles, needing different users within the same test. For instance, you might begin a test as a producer who initiates a submission and then switch to an underwriter who needs to approve it. Managing these scenarios can be time-consuming and error-prone, particularly when it involves logging off and on or using multiple browsers.
Superuser
Understanding the challenges of permission testing, especially as roles and permissions evolve, leads us to consider alternatives. Guidewire offers superuser, a special user with access to everything within InsuranceSuite. Testing with superuser accelerates development by allowing teams to focus on validating core functionality without being delayed by incomplete or evolving permissions.
Once you validate the functional code, you can transition to verifying permissions using role-specific IDs instead of superuser.
When testing complex systems like InsuranceSuite, separating functional testing from security and permission testing not only simplifies the process but also accelerates development. By focusing first on validating core functionality with tools like superuser and then verifying permissions with role-based IDs, you streamline testing and reduce the overhead of managing evolving or incomplete permissions during the initial phases of development.
The Risks of Superuser
The benefits of using superuser for functional testing are significant, but it does carry certain risks. Guidewire’s Best Practices advise minimizing the use of superuser because of the potential for unintended system-wide changes. While this is a valid concern, such occurrences are extremely rare.
In my 18+ years as a Guidewire consultant, I have encountered this issue only a few times, and those instances occurred when we were actively trying to fix something using superuser rather than encountering an unexpected problem. Moreover, these issues only arose in local or lower regions, where the impact was minimal.
The only other potential risk of superuser is “lost time” running the same test multiple times during functional testing, then at least once more for permission testing. Not only is time not lost due to factors we will describe later in Out of Sync, CenterTest automation completely eliminates this risk as you’ll see in the next section.
CenterTest Automation and Role-Based Testing
CenterTest test automation is specifically designed for role-based testing, allowing you to decouple the user associated to actions when writing a test, then tightly couple users to actions when running a test for functional or permission purposes.
User Property File
CenterTest offers a flexible and scalable approach that ties actions to roles rather than users. Unlike traditional user-based methods, where tests are linked to specific users, CenterTest dynamically assigns roles to the appropriate users at runtime through a role-user-environment mapping externalized in a property file.
Let’s look at a simple user property file.
In the above example file, superuser (su) is used for every CenterTest UI login since no environmental restrictions are identified. This setup greatly simplifies functional testing by bypassing all permission-based restrictions—a common approach for local developer machines.
The structure of the user property is:
centertest.user.role.environment=user|password
where
Let’s look at another property file incorporating explicit users identified for specific roles.
In this example, superuser is still used for local testing (line 1), but now aarmstrong is assigned to the producer role and bbaker as the adjuster for the dev and qa environments.
Finally, let’s look at a more complex example with different users, passwords, and even pulling information from a value or secret source.
This example highlights several key points:
- Lines 1 and 4 are using role-based IDs for local testing as well.
- Lines 3 and 6 use different IDs and passwords for the qa environment.
- Line 7 retrieves the adjuster user ID and password from a vault to further secure the preprod environment, a common CenterTest approach for CI/CD pipelines.
Testing with Multiple User Roles
Now that we’ve seen the flexibility of property files, let’s examine a CenterTest test to understand how role-based testing correlates to a user property file.
There are two things to note in this example test:
Line 9 logs into PolicyCenter with the pcContext defined in line 6 connecting to the producer role. Since producer retrieves the associated user id/password from the property file, it can initially point to superuser then later switch to aarmstrong or producer01 as needed, without changing the test.
Similarly, line 13 logs into ClaimCenter using the ccContext defined in line 7 connecting to the adjuster. And again, you can switch the user ID/password as needed without changing the test.
Verifying Permissions at the Code Level
At the application layer, code ties actions directly to permissions, not to roles. Let us look at an example of defining a Guidewire action to a permission.
In the above code snippet, we want to ensure a person can copy a submission (line 1 function name of canCopySubmission). Line 2 checks the system’s permission object (perm) along with the permission type (Submission and System) and the specific type (create and jobcopy) to ensure the person is authorized for the action. The function provides a simple true/false as a return value.
Similarly, you can use visible, editable, or other properties to check permissions at the UI (PCF) level. In the above example, line 5 checks the field’s visibility using the perm.System.createreferralreason to ensure proper access before displaying the “Add Referral Reason” button.
Out of Sync
With more than 60 roles and over 300 permissions in Guidewire OOTB, it is easy to get them out of sync, especially between environments or after database updates. When this happens, it can significantly disrupt testing and development. For example, a tester may suddenly encounter issues completing a task that worked fine before the latest code update. After some effort, the tester reports the defect to development.
Development tests the same task, and it works perfectly for them. “It works for me” is not an acceptable response, so development spends additional time troubleshooting before confirming that they cannot recreate the problem. Eventually, they discover that the tester no longer has the necessary permissions.
This can happen several ways:
- The tester temporarily removed their own permission to test something else and forgot to add it back.
- A database drop occurred, and while roles and permissions were reloaded, discrepancies emerged.
- The tester’s user account no longer has the role they once had.
- Roles have changed, and the tester is not using the correct one.
Unfortunately, this happens more often than desired due to the volatility of roles and permissions. It does not happen frequently enough to become second nature, but when it does occur, it is both stressful and wasteful to your project.
Summary
Testing with superuser offers a powerful approach to accelerate development by allowing teams to bypass the restrictions imposed by roles and permissions. This strategy enables developers to focus on validating core functionality without being delayed by evolving or incomplete permissions. While superuser is highly effective for this purpose, it is important to recognize and manage the potential risks, particularly in environments where unintended changes could have broader impacts.
CenterTest further enhances this approach with role-based testing for simple transitions from superuser-driven functional testing to comprehensive permission verification. By strategically leveraging superuser along with effective test automation, teams can accelerate their development processes while ensuring that security and access controls are properly validated as projects progress.
Kim Filiatrault
Founder and President
Special thanks to the Kimputing team: Raivis Sarkovskis, Arkadiusz Frankowski , and Duncan Guignet for their contributions to this article.
Watch or read our other posts at Kimputing Blogs. You’ll find everything from Automated testing to CenterTest, Guidewire knowledge to general interest. We’re trying to help share our knowledge from decades of experience.
