Role testing

Owned by Sara Di Gregorio
May 26, 2016
2 min read

Discussion

Permissions and roles in OSCAR have evolved to become very complex.  At present there is a set of roles which grant varying rights to different objects across the system by default. Moreover, it is not certain these objects complete the intended standard role definitions nor that each is fully enumerated in the UI. 

OSCAR’s role implementation has complicating factors when they interact with CAISI (e.g. programs), the integrator, or with other similar system constructs such as multisite settings.  Also we lack the  information for the intended workflows in all cases e.g. how do you determine how a role enabled function is related to which program in CAISI? 

It should also be noted that we also need to document all role based rules to enable changes to the UI and to and subsequently provide tooltips/additional information on what an object actually refers to in a functional sense.  i.e. admin.misc is not intuitive.

Role Test Case Development Plan

After some analysis it is determined that the following tactics will be followed to deliver a more comprehensive set of test cases for roles:

  • Make list of current objects that can be assigned to roles by using the UI list as well as searching at the code level
  • Document the control role-objects exhibit (at a general code/page level) when granted at the  patient/provider-specific level with the requisite  permission (r/w/d/u)  which is In progress: The detail of this in progress work is as follows:
    • assign a provider with one of read/write/delete/update; then log in to check and see if the pages/page elements listed in the document are visible/modifiable/etc as per the permission
    • repeat for each permission
    • using previous tests, see if priority works correctly (assign read then "no rights" set higher priority for "no rights", then check)
    • check that updating/deleting permissions/priority for objects works correctly (example: what happens if you have a "no rights" and a "read" permission with same priority)
    • if the object includes patient-specific permissions, check to make sure those override correctly
    • if there is a call to the object in Oscar that has two roles  check what happens if you have a "no rights" on one and a "read" permission on the other: reverse the rights and repeat.
    • check role vs personal rights and whether the order of application matters
      • add a role, add a right to the same object with different permissions, check results, then set priorities for one/both and check results
      • add a role, add a different role with different permissions on an object, check results, set priorities for one/both and check results

Make sure the default rights for roles make sense and include any new rights which apply to the standard roles