Role Model: Checklist Cheat Sheet

A cheat sheet is a cheat sheet on a selected topic that you don’t forget to check. Take the cheat sheet as a basis, adapt it to your project, and you're done!

In his book about test design I wrote a number of cheat sheets that I now want to share. Today we’ll talk about the role model in the GUI and API – this is when we have a distinction of rights for individual users / entire groups (they are assigned a role).

The set of roles can be very extensive – rights only to view, to edit, to edit a specific entity or even one field in this entity, to view a specific page (reporting or audit), to create a connection…

But overall, we usually have:

• ordinary users – each group has its own set of rights;

• admin – all-powerful user;

• guest is an unauthorized user (this is, in fact, checking for zero).

Let's figure out how to check them:

1. GUI – graphical user interface

2. API – program interface

3. Combination of roles

4. Total

GUI – graphical user interface

For any action in the system, we try to perform it under:

• a user who has rights to do so;

• a user who does not have rights to do so;

• guest;

• admin

If the task is to check the role model itself, then we take the role and check for each action for which:

• there is access;

• no access.

For example, I, as the author of articles on Habré, can edit their articles. Then let's try:

• edit your article;

• edit someone else’s article (make sure there is no edit button, try opening the editor via a direct link).

If you have any explicit restrictions like:

This button should only be shown to the VIP client manager

It is important to check not only the VIP client manager, but also all other roles – that they do not see such a button.

API – program interface

Everything is the same as in the GUI, we just call methods here instead of clicking on buttons in the interface.

If we check the method, then under the user who has:

If we check the role model itself, then we take the role and call each method 1-2 times – so that there is/is not access. Let's take for example Cards system, according to Specification for a role model – “the user specified via user-id (simulates LDAP login in real life) sees only himself in the getUser method).” To check this, we send 2 requests:

Sometimes it happens that the restriction is partially imposed – for example, the operator can edit information on a client such as VIP status, but cannot edit the full name and other passport data. How can I check this? That's right, we send an edit request in which:

• editable field;

• inaccessible;

• in one request there is both an accessible (VIP) and an inaccessible (full name) field at once – how will the system behave in this case? Will the VIP flag be corrected by displaying an error on the full name?

There may also be restrictions on viewing specific fields. This is especially true for the GraphQL API, where the set of fields in the response is specified by the client. We ask in response:

• fields that can be accessed (for example, username for user_viewer in Cards, getUser method)

• fields that cannot be accessed (card data in the same example);

• both.

Combination of roles

When testing roles, you need to check them:

Because it happens that a number of “small” roles are configured:

• working with the admin panel

• working with data entry

• working with reports

• …

And then they create user groups, collecting access rights from these small roles. As if handing out bracelets allowing entry into one or another area of ​​the water park.

Therefore, we check what will happen when the user has:

• one role – how do the roles work individually? We check each one;

• two or more different roles that do not affect each other (non-conflicting);

• two or more conflicting (an operator who only sees + an operator who can edit – roles can overlap with the error “configure everything correctly”, or they can simply ignore the one that gives fewer rights);

• zero roles – log in as a guest or user who has not yet been added to any of the groups.

Total

When testing a role model, you need to test all actions and/or API methods for each role. We see that both situations are processed correctly:

• there is access;

• no access.

You can try to bypass the denial of access in the GUI (for example, there is no button in the interface, but we are following a direct link). API access denial needs to be investigated in more detail:

• no rights to the entire method;

• no rights to methods under certain conditions (we are not calling our own data);

• no rights to the returned fields (especially important for the GraphQL API).

We check the roles themselves separately and together – how do they interact with each other? Is it correct to conflict if required? What if the user doesn't have any roles yet?

PS – look for more useful articles on my blog under the “useful” tag. And useful videos are at my youtube channel