Challenge

In many cases, distinct roles are used with different ActiveVOS processes. In order to ensure that testing is comprehensive, it is important that code is tested using all possible variations of the roles required. Because a user may be given different roles for specific situations, testing can miss code flaws and cause gaps in tested use cases if these role variations are not accounted for.

Description

This document discusses best practices for testing code with roles in ActiveVOS.

What to Test

Every role assigned on an ActiveVOS business process management project (BPM) project has some functionality associated with it. That functionality needs to be tested for a user operating in a number of given roles. To ensure that testing is comprehensive, tests must also be carried out when the user does not have those roles assigned, to ensure that they cannot operate beyond their authority.

Information Needed

Before testing can begin, gather the following information:

• All assigned roles
• All functions for each assigned role (cross-reference functions against each role)
• Description of what a user with a given role CAN do
• Description of what a user without that role CANNOT do
• Determine if a user can have multiple roles
  • If so, what are the possible combinations
  • Each combination should be treated as a unique role for testing purposes

Set up Users to Test

For each possible combination of roles create a user.

Example

Roles:

1. RoleA
2. RoleB
3. RoleC

Functionality:

1. Process1
2. Process2
3. Process3
4. Process4
5. Process5

Cross Reference

Multiple Roles:

1. A user with Role A can only have Role A
2. A User can have RoleB and RoleC

Set up Users:

1. UserA has Role A
2. UserB has Role B
3. UserC has Role C
4. UserBC has Role A and Role B

Specify Tests

Test each process with each user.

Multiple Tasks Within a Workflow

It is also important to consider that a workflow may contain multiple tasks and multiple submission options for each task. Permissions for these options are typically managed by role permissions in MDM/P360 It is important to test each option for each user.

Roles:

1. UserRole
2. ManagerRole 

Functionality:

1. ReviewTask
   1. AssignTask
   2. ApproveTask
   3. RejectTask
2. ApprovalTask
   1. AssignTask
   2. ApproveTask
   3. RejectTask

Summary

Specify roles when there are restrictions or authorization requirements for particular functionality. If roles and role combinations are not tested separately, issues with the code are more likely to be missed. To ensure the robustness of the code, specify each variation to be tested, document what is expected, and then test.