The Issue

For any application with multiple users, you’ll need to test for Role Based Visibility. First, you’ll confirm your object level visibility – this means checking that certain objects or elements on the screen are only visible to certain users or roles/types. Depending on user type for an application, one user may have a completely different UI than another.

This further extends with data level security – which will check for certain user types being able to access or view data. For example, a user with higher level access may be allowed to view pages that restricted to lower access users.

The Answer

Lets use Awetest to demonstrate how two users can have different levels of access based on role. Within Awetest, users can be set up with multiple tiers of access. Lets take the lowest level of access, which is set as Tester. Testers are not able to switch projects or companies beyond what they are assigned (the top right dropdown). They will also not be able to interact with anything in the management tab, which is removed from the left hand menu.

Screen Shot 2017-12-27 at 5.09.33 PM

Conversely, we see below the homepage of a super user. The difference here is that we now have access to the management tab. We can also select different projects from the dropdown.

Screen Shot 2017-12-28 at 10.14.08 AM

Now that we know what we’re testing for, lets delve into the code for validating our super user visibility. We’ll use a simple Watir Webdriver script to validate:

This script will open our browser, navigate to Awetest, login, and proceed to cycle through checking we are seeing the correct UI for our given user access. If we do not find the management tab, the script will fail and throw us an error message “Management tab not found”. To test for the lowest access user, we’ll use the below script:

This script will proceed  through the same steps until it needs to look for the management tab; in this case, if we do find the Management element, we will fail the script, as the super user should not be seeing this.


The above example captures the main essence of Role Based Validations – validating based on expected user access. Depending on the application, you’ll need to check for a variety of things – in our example, we did a simple check for an element (the management tab) that should not appear visible for certain users. Other applications will have vastly different layouts and levels of data access based on the current user – addressing these different cases will help to ensure application functionality across the board.