В первой части гайда по тест-дизайну в блоге ЛАНИТ на Хабре мы уже рассмотрели основные техники тест-дизайна, связанные со сценариями и данными. Теперь давайте обсудим, как тестировать ролевую модель приложения. 

Действия пользователей в системе и в рамках бизнес-процессов существенно влияют на эргономику, слаженность и безопасность. Работа с множеством ролей и процессов может быть сложной и требует внимания, но понимание этой механики необходимо.

Блок 5. Тестирование ролевой модели (или прав доступа)

Тестирование ролевой модели – это техника тест-дизайна, направленная на проверку корректности реализации прав и разграничений пользователя в соответствии с ролью в системе и заложенных в ней процессах. 

Во многих системах существует ролевая модель. Например, в банковской системе это может быть администратор, клиент, оператор, специалист отдела X и т.д. В системе складского учёта это может быть администратор, начальник склада, заместитель начальника склада, кладовщик, грузчик.

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

В общем случае тестирование ролевой модели подразумевает проверку того, что пользователю, имеющему в рамках системы такую-то роль:

• доступны одни функции, а другие недоступны;

• доступны или недоступны для чтения/редактирования/удаления некие данные на неких формах пользовательского интерфейса;

• достаточно тех или иных прав для выполнений своих задач согласно сценариям использования системы, в которых его роль задействована, т.е. он способен выполнять задачи в рамках отведённого ему участка бизнес-процесса.

Разграничение на «доступны» и «недоступны» – основа для создания позитивных и негативных тестов.

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

Когда применяется

Эту технику следует использовать при:

• тестировании систем с множеством ролей пользователей и процессов, основанных на роли пользователя;

• внедрении новых ролей;

• изменении существующих прав;

• работе с системами, где конфиденциальность и безопасность являются приоритетами.

Виды ролей

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

Физические роли – это роли пользователя в системе, обозначающие круг их прав и возможностей. Например, руководитель отдела, старший бухгалтер, бухгалтер, старший инженер, менеджер по персоналу и т.д. 

Как правило, они хорошо и детально описаны в документации продукта во всех необходимых аспектах. Для каждой физической роли прописывается, какими правами и ограничениями должен обладать пользователь, наделённый этой ролью. 

Например, пользователю с ролью «Бухгалтер» должен быть доступен функционал создания ежемесячных отчетов о выплатах заработной платы сотрудникам и ограничен доступ к функционалу административной части системы, которая доступна пользователю с ролью «Специалист тех.поддержки».

Логические роли – это роли пользователя относительно его участия в каком-либо бизнес-процессе. Например, автор задачи в Jira, исполнитель задачи, наблюдатель. 

• В отличие от физических ролей, описание логических ролей в документации дается не всегда четко и однозначно. 

• У логической роли может меняться доступ к функционалу.

• Также логические роли могут присутствовать или отсутствовать в определенном процессе или команде.

Эти свойства связаны с тем, что в системах набор логических ролей может гибко меняться в зависимости от состава ролевой команды или из-за требований конкретного рабочего процесса на проекте. Поэтому иногда для одних и тех же физических ролей в разных процессах может быть различный набор логических ролей. 

Рассмотрим это свойство на конкретном примере. В системе Jira есть объект «Задача», который могут создавать представители различных компаний, занимающихся разработкой одного ПО. В объекте «Задача» в команде одной компании есть стадии «Открыта», «В разработке» и «В тестировании». Соответственно, в рабочем процессе этой компании есть логические роли: автор, разработчик, QA-инженер. Также задача проходит стадию «Ревью дизайна», в рамках которой ответственный за ревью сотрудник проверяет внешний вид пользовательского интерфейса разработанного сервиса на соответствие макетам. За этой стадией закреплена логическая роль «Рецензент». 

В команде другой компании стадии «Ревью дизайна» нет, есть только «Открыта», «В разработке» и «В тестировании». Получается, во второй компании отсутствует логическая роль «Рецензент».

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

После того, как бухгалтер отсылает разработанный отчёт старшему бухгалтеру на согласование, старший бухгалтер получает логическую роль «Рецензент», отчёт находится у него на ревью, а бухгалтеру с логической ролью «Автор отчёта» уже запрещается редактировать созданный отчёт. В момент ревью документа бухгалтер получает временную/промежуточную роль «Наблюдатель». Теперь редактировать отчёт может только тот, кто назначен рецензентом, и только рецензент имеет право привести отчет в состояние «Утвержден».

Для логических ролей характерна изменчивость как самого набора таких ролей у каждого пользователя, так и самих возможностей, которые эти роли могут давать. 

Например, старший бухгалтер может иметь возможность оставлять комментарии и замечания до тех пор, пока не установит для отчета состояние «Утвержден» или «Отправлено на доработку». После этого рецензенту будет запрещено вносить какие-либо правки или совершать какие-либо действия с отчетом.

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

Алгоритм составления основы для ТК проверки прав доступа

Шаг 1. Идентификация физических ролей и их допусков 

а) Выявление списка физических ролей.

б) Выявление доступа физической роли к разделам программы.

в) Выявление уровня доступа физической роли к функционалу каждого раздела программы.

Шаг 2. Идентификация логических ролей и их допусков

а) Выявление списка пользовательских процессов системы.

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

в) Выявление соотношения каждой логической роли с каждой стадией пользовательского процесса.

Шаг 3. Выявление соответствия физических ролей с логическими

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

1) Таблица с физическими ролями и тестирование физических ролей.  Физические роли составляют основу проверок, на них стоит опереться в первую очередь, так как они более постоянные в системе.

2) Таблица с логическими ролями. Логические роли изменчивы, представлены не полностью. На них опираемся во вторую очередь.

3) Итоговая таблица с комбинациями физических и логических ролей на основе предыдущих таблиц.

Пример

Шаг 1.  Построение таблицы с физическими ролями и тестирование физических ролей.

Таблица содержит поля «объект» (набор функционала, который имеется в тестируемой системе), «действие», которое можно совершить с этим функционалом, а также поля в виде физических ролей: директор, менеджер по персоналу, старший бухгалтер. Для каждой физической роли заполняем ячейки, какие действия ей доступны для конкретного объекта системы, а какие – нет. 

Сначала выписываем все объекты системы. 

Затем действия, которые можно совершить с объектами на разной стадии существования объекта в системе. 

Затем расставляем «Да» и «Нет» в каждой физической роли относительно действий с каждым объектом. Для удобства восприятия информации выделим значения «Да» и «Нет» цветом. В итоге получится некая вариация чек-листа, в котором для каждой физической роли будет отмечено, что можно делать, а что нельзя.

При работе с тестированием прав доступа нельзя использовать технику выделения классов эквивалентности, так как все физические роли, относящиеся к модулю «Бухгалтерия» не обязательно будут иметь одинаковый набор доступов к функционалу. Нужно проверять каждую роль, каждый доступ, каждое действие, чтобы убедиться, что все они реализованы согласно требованиям, описанным в документации.

При проверке ролей и их доступов важно проверить: 

• как реализовано выполнение и отказ от выполнения того или иного действия;

• совпадает ли фактическая реализация с заявленной в требованиях.

Наличие или отсутствие доступа пользователя к какому-либо функционалу может реализовываться разными способами. Например, для роли «Директор» все объекты интерфейса и контента страницы «Описание отчёта» могут быть видимыми, но быть неактивными и выдавать при попытке взаимодействия сообщение, почему это невозможно. А могут быть полностью убраны из визуализации интерфейса.

Для фиксации итогов тестирования физический ролей в этой же таблице сделаем отметки о том, какие действия и по отношению к каким объектам соответствуют обозначенным в документации правилам, а также поясним, чем они отличаются, если это необходимо.

Шаг 2.  Построение таблицы с логическими ролями и тестирование логических ролей

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

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

Выписываем все объекты системы в таблицу. 

Затем записываем действия, которые можно совершить с ними на разной стадии существования объекта в системе. 

После анализа информации о логических ролях в тестируемом ПО указываем в таблице, какие логические роли могут делать конкретные действия с имеющимися объектами тестирования. Для тестирования этого вида ролей характерно резкое возрастание количества разных проверок. Нужно провести оптимизацию набора проверок хотя бы на основе знания о приоритетности сочетаний физических и логических ролей.

Для оптимизации набора проверок поможет третий шаг построения пирамиды.

Шаг 3.  Комбинирование физических и логических ролей

Этот этап построения набора тестов для прав доступа связан с процессом сопоставления физических и логических ролей. В рамках него мы проверяем, какие физические роли могут обладать конкретными логическими ролями по отношению к тем или иным объектам системы.

Чтобы построить таблицу с комбинированными физическими и логическими ролями, необходимо взять первую таблицу с физическими ролями и заменить в этой таблице значения «Да» и «Нет» на логические роли из таблицы с логическими ролями. 

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

Далее на основании проведенного анализа ролевой модели тестируемого продукта красным цветом отмечаем те логические роли, в которых не может находиться пользователь, обладая конкретной физической ролью в системе, а зелёным – логические роли, в которых он может находится в своей физической роли.

Таким образом, для физической роли «Директор» при выполнении действия «Просмотр» с объектом «Отчет о финансах» должны быть окрашены красным цветом логические роли «Автор», «Исполнитель» и «Рецензент», так как директор в примере не имеет возможности создавать и изменять отчёты о финансах, а может только наблюдать (см. расстановку «Да» и «Нет» в первой таблице). 

Соответственно, логическая роль «Наблюдатель» должна быть окрашена в зелёный цвет. Аналогично отмечаем цветом остальное содержимое таблицы.

Как видите, заполнение содержимого итоговой таблицы соответствует значениям «Да» и «Нет» в таблице с физическими ролями, но имеет более детальное разделение по цветам внутри ячейки, учитывая то, какими логическими ролями может обладать пользователь в конкретной физической роли.

Работа с ролями и доступами может быть запутанной, даже при небольшом количестве процессов. Применяйте этот подход методично, разбирая каждый процесс отдельно. Не спешите объединять процессы в одну таблицу, если под вашей ответственностью находится множество бизнес-процессов. Это уместно только тогда, когда все процессы проработаны отдельно, и в них участвует одинаковый набор физических ролей (в идеале).

Заключение

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

Техники тест-дизайна позволяют инженеру тестирования сделать набор тестов максимально компактным, способствуя при этом максимально возможному сохранению полноты тестового покрытия.

Стоит помнить, что в чистом виде на сокращение количества тестов работает техника эквивалентного разбиения.

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

• Техника «Анализ граничных значений» покрывает риск нахождения дефектов на границах, где в программе происходит переход от одной логики вычислений к другой.

• Техники «Полный перебор» и «Метод всех пар» позволяют покрыть риск возникновения дефектов при вводе различных комбинаций валидных значений.

• «Таблица принятия решений» помогает выявить вариации сценариев, по которым может протекать сравнительно небольшой бизнес-процесс (например, в рамках одного интерфейса).

• «Диаграммы и переходов и состояний» дают возможность спланировать целые цепочки тестов, призванные проверить бизнес-процессы, которые охватывают множество модулей и интерфейсов продукта.

• «Тестирование ролевой модели» позволяет не упустить из вида несанкционированные доступы одних пользователей к возможностям других, что сделает выполнение бизнес-процессов продукта более четким и безопасным.

Выбор подходящих именно вам и для вашего проекта техник тест-дизайна зависит от:
- понимания механик и предназначения каждой техники,
- знания архитектуры продукта,
- опыта,
- понимания своей зоны ответственности,
- построения рабочих процессов,
- и, конечно же, имеющегося в наличии самого главного ресурса – времени на тестирование.

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

Материалы, которые использовались в гайде:

• Ли Копланд “A Practitioner's Guide to Software Test Design”, перевод  Уфимцевой Галины

• Техника граничных значений и классов эквивалентности. 2022 | ВКонтакте 

• Техники тест дизайна: Доменное тестирование (Эквивалентное разбиение и анализ граничных значений) - CrashTest 

• Cause and Effect Graph - Dynamic Test Case Writing Technique 

• https://avatars.mds.yandex.net/get-lpc/1220100/47122370-7e23-4ed2-8478-e1642cf9c1ec/width_480_q70 

• QA_Bible  

• State & Transition Diagram — что это и как применять 

• What is State transition testing in software testing? 

• Use cases and Test cases - Тест-дизайн и ручное тестирование - Форум тестировщиков