Ответ.

Ручное тестирование прав доступа и ролей позволяет проверить, что разные типы пользователей имеют корректный уровень доступа к функционалу и данным приложения.

История вопроса

По мере роста числа пользователей и их сценариев работы даже простые приложения обзавелись ролевой моделью. Ошибки в правах часто приводили к серьёзным утечкам данных или ограничению бизнес-операций. Отсюда возникла необходимость тщательно тестировать роли вручную.

Проблема

пропуск ошибок в ограничении доступа к чувствительным данным;
неверная настройка ролей, позволяющая пользователям выполнять недозволенные действия (например, доступ к административным функциям для обычных пользователей);
сложности в проверке комбинированных ролей или нестандартных сценариев доступа.

Решение

Документировать все существующие роли и соответствующие действия для каждой роли;
Формировать тестовые наборы для каждой роли, включая условные пересечения ролей;
Проверять доступ не только к функциям, но и к разным частям данных (CRUD);
Валидировать как прямой доступ (через UI), так и попытки доступа через прямые ссылки или API.

Ключевые особенности:

Всестороннее покрытие сценариев: каждый тип пользователя должен быть проверен во всех возможных ролях и действиях;
Тестирование граничных и комбинированных ролей: часто ошибки проявляются при наложении прав разных ролей;
Проверка обхода стандартных интерфейсов: тестирование прямого доступа к страницам/действиям, к которым пользователь официально не имеет прав.

Вопросы с подвохом.

Достаточно ли протестировать только основные роли (например, "Администратор" и "Пользователь")?

Нет. Именно в промежуточных, редко используемых и комбинированных ролях чаще всего скрываются дефекты.

Является ли ограничение UI (скрытые кнопки и элементы) достаточным для безопасности?

Нет. UI-контроль не защищает от попыток прямого доступа по адресу или через API, права необходимо ограничивать на уровне серверной логики.

Нужно ли тестировать права доступа через разные каналы приложения (например, и через веб, и через мобильное приложение)?

Обязательно. Часто различие в реализации приводит к отличиям в поведении и ошибкам в ограничении прав.

Типовые ошибки и анти-паттерны

Проверка только стандартных ролей
Ориентация исключительно на внешний интерфейс, без валидации серверных ограничений
Пренебрежение нестандартными и комбинированными ролями

Пример из жизни

Негативный кейс

Проверялся только UI и только три основные роли. В результате пользователи с нестандартной комбинацией ролей получили доступ к административным функциям через прямой переход по ссылке.

Плюсы:

Быстрое тестирование
Простота процесса

Минусы:

Критическая уязвимость, выявленная на продакшене
Нарушение безопасности и доверия пользователей

Позитивный кейс

Для тестирования были созданы тестовые пользователи с различными комбинациями ролей, проведён аудит API и прямого доступа. Ошибки были найдены и исправлены до релиза.