Answer.

Manual testing of access rights and roles allows you to verify that different types of users have the correct level of access to the application's functionality and data.

Background

As the number of users and their working scenarios grows, even simple applications have developed a role-based model. Errors in permissions often lead to serious data leaks or restrictions on business operations. This has created a need to thoroughly test roles manually.

Problems

Missed errors in restricting access to sensitive data;
Incorrectly configured roles allowing users to perform unauthorized actions (e.g., access to administrative functions for regular users);
Difficulties in verifying combined roles or non-standard access scenarios.

Solution

Document all existing roles and the corresponding actions for each role;
Create test sets for each role, including conditional overlaps of roles;
Check access not only to functions but also to different parts of the data (CRUD);
Validate both direct access (through the UI) and attempts to access through direct links or APIs.

Key features:

Comprehensive coverage of scenarios: each type of user should be tested across all possible roles and actions;
Testing boundary and combined roles: errors often manifest when overlapping rights from different roles;
Checking circumvention of standard interfaces: testing direct access to pages/actions that the user does not officially have rights to.

Trick Questions.

Is it enough to only test the main roles (e.g., "Administrator" and "User")?

No. It is in intermediate, rarely used, and combined roles that defects are most often hidden.

Is UI restriction (hidden buttons and elements) sufficient for security?

No. UI control does not protect against attempts at direct access via the URL or through the API; permissions need to be restricted at the server logic level.

Should access rights be tested through different application channels (e.g., both web and mobile applications)?

Absolutely. Often, the difference in implementation leads to differences in behavior and errors in rights restriction.

Common Mistakes and Anti-patterns

Checking only standard roles
Focusing exclusively on the external interface without validating server-side restrictions
Neglecting non-standard and combined roles

Real-life Example

Negative Case

Only the UI was checked and only three main roles. As a result, users with a non-standard combination of roles gained access to administrative functions through direct link navigation.

Pros:

Fast testing
Simplicity of the process

Cons:

Critical vulnerability identified in production
Breach of security and user trust

Positive Case

Test users with various role combinations were created for testing, an audit of the API and direct access was conducted. Errors were found and corrected before release.