Существует много разных источников информации по теории тестирования — книги, статьи, курсы и другие материалы. Практически в каждом из них описаны техники тест‑дизайна, сопровождающиеся простыми обособленными примерами их применения. Но часто, изучая эти материалы, я задавалась вопросом: «А что же дальше? Как объединяются техники и как выглядит общая картина тестирования?».
Меня зовут Ирина Прудникова, тестировщик Lego Low‑Code BPM платформы Citeck. В сегодняшней статье я хочу показать, как разные техники тест‑дизайна можно использовать в комплексе. В качестве примера я разберу реальную задачу из нашей работы — тестирование модуля Service Desk.
Краткое представление о Citeck
Это BPM‑конструктор, с которым может работать даже человек без глубокого бэграунда разработчика, используя интерфейс и набор готовых инструментов. Платформа сочетает в себе два подхода:
No‑Code — веб‑редактор артефактов и BPMN‑процессов,
Low‑Code — для создания микросервисов, которые будут содержать и сконфигурированные в редакторе артефакты, и необходимую дополнительную логику.
С точки зрения тестирования это выглядит довольно увлекательно. Представьте, что вас посадили в Lego city, где все сделано из совместимых и универсальных деталей. Но вот появляется новый сценарий: нужно создать Lego Хогвартс, где лестницы движутся. Для этого изобретают новую универсальную деталь. Теперь ваша задача — убедиться, что эта деталь работает не только в Хогвартсе, но и, например, превращает лестницы в эскалаторы в обычных зданиях, не разрушая их. Так возникают два совершенно разных мира с уникальной функциональностью, построенные из одних и тех же элементов, которые должны адаптироваться к любым условиям.
Наш модуль Service Desk — один из таких готовых наборов из универсальных деталей, но с уникальной функциональностью. В этой статье я разложу процесс проверки модуля на отдельные техники тест‑дизайна. Чтобы примеры были максимально практичными, вы можете развернуть у себя нашу Community‑версию.
Пользовательское описание модуля
Набор техник, который я рассматриваю в этой статье, достаточно распространенный.
Примерно так крупными блоками выглядит объем предстоящего тестирования модуля Service Desk:
Наверняка, есть еще много вариантов, как можно декомпозировать рассматриваемую задачу перед началом проверки. Однако в случае с Low‑Code важно помнить о балансе между универсальной функциональностью платформы и уникальными настройками, созданными для конкретной задачи. Если этот баланс не учитывать, легко уйти в проверку лишних аспектов, что может затянуть выполнение основной задачи.
Тестирование настройки модуля
При поставке модуля заказчику не все параметры задаются по умолчанию — часть из них настраивается индивидуально в соответствии с целями пользователей (например, время для SLA). Поэтому процесс тестирования охватывает как работу конфигурации по умолчанию, так и корректность работы пользовательских настроек.
В первом случае («Проверка конфигурации по умолчанию») мы тестируем параметры, которые заданы изначально. Здесь использование техники тест‑дизайна не требуется, поскольку речь идет о проверке на соответствие требованиям.
Во втором случае («Проверка пользовательской конфигурации»), поскольку эта часть доступна для свободного заполнения, требуется проверка возможности заполнения, входных значений, а также их обработка.
В нашем модуле такие настройки заполняются на формах. Например, одна из форм.
Форма содержит множество полей, и на данном этапе важно протестировать только их заполнение, без учета сложных сочетаний входных данных. Это связано с тем, что содержимое полей не влияет на результат после нажатия кнопки «Создать» — создается лишь правило, которое будет использоваться в расчетах SLA. На мой взгляд, тут будут уместны техники «Классы эквивалентности» и «Граничные значения». Но я напомню, что это Low‑Code платформа, а значит:
Все типы полей универсальные для всех форм системы, следовательно, разнообразные проверки на «символы вместо чисел» и пр. можно исключить. Это все проверено, проверяется и будет проверяться, но в рамках системы.
Настройки каждого поля создаются в конструкторе и доступны для просмотра. Это позволяет заранее изучить ограничения и логику, чтобы учесть их при составлении тест‑кейсов.
С учетом особенностей Low‑Code, смотрим настроенную валидацию с помощью указанных техник «Классы эквивалентности» и «Граничные значения»:
Обязательность:
Обязательные поля.
Необязательные поля.
Валидация h/m:
h/m указан.
h/m не указан.
0.
Регистр, символы, кириллица.
Такое разграничение уровня настроек и его проверка позволяют нам:
убедиться, что настройки соответствуют требованиям — это позволяет нам исключить данный уровень из локализации багов, если ошибки обнаружатся на следующих этапах,
Или
убедиться, что настройки не соответствуют требованиям — в таком случае найденный баг на этом этапе позволяет сократить ресурсы команды, исключив дальнейший поиск причины ошибки.
Тестирование основной функциональности
Тестирование основной функциональности модуля — это следующий уровень проверок. На схеме выше я разбила его на три блока:
создание заявки,
статусная модель,
ролевая модель.
Такое деление позволяет осуществлять проверку поэтапно, ничего не пропустить и не запутаться во всей логике.
Если на уровне тестирования настройки модуля мы проверили, что настройки, идущие по умолчанию, соответствуют требованиям, а пользовательские настройки доступны для заполнения, то на данном этапе проверяется сама работа модуля.
Создание заявки
Работа модуля начинается с создания заявки. Есть две больших роли, откуда может прийти заявка — внешние пользователи и внутренние. Внешние пользователи, в свою очередь, делятся на отдельные группы пользователей ‑– заказчиков. Также есть два варианта создания заявок — из системы и по почте. Таким образом, у нас появились варианты данных и условия, а значит будут комбинации их применения, что напрашивается в технику «Таблица принятия решений».
Кроме основных комбинаций условий при создании, есть еще условия поиска и определение заказчика, от которого пришла заявка.
Статусная модель
Дальнейшее поведение заявки определяется бизнес‑процессом, с помощью которого автоматизирована вся работа с заявкой. Варианты состояния заявки разнообразны: она может быть открыта и кто бы мог подумать, закрыта, т.к. проблема больше не актуальна. Или же может находиться в компетенции разных специалистов, и нужно передать другой линии поддержки. Или данных для решения недостаточно, и необходимо уточнить. Техника «Диаграмма состояний и переходов» перед глазами очень пригодиться, поскольку визуализирует логику смены статусов.
На платформе Citeck доступна готовая BPMN‑модель с описанием каждого компонента, которую могут использовать администраторы. Однако для целей тестирования и наглядности можно подготовить отдельную схему переходов по статусам. Такой подход упрощает обособленные проверки и делает процесс более управляемым. Например, в нашем случае схема схема выглядит следующим образом:
Ролевая модель
Теперь, когда основная логика работы проверена, стоит вспомнить, что все пользователи принадлежат какой‑либо компании, для которых настройки могут быть разграничены. Например, для разных заказчиков могут быть настроены разные линии технической поддержки, что влияет на маршрутизацию заявок. И как писала раньше, взаимодействовать с заявкой внешние пользователи могут только через почту.
На этом блок основной функциональности тоже можем считать базово укомплектованным проверками.
Тестирование специфичной функциональности
В нашем случае специфичным является расчет показателей SLA. Расчет зависит от ряда условий: приоритет задачи, рабочее расписание сотрудников техподдержки, время на работу с заявкой, логика в статусах.
Количество условий и их вариантов делает задачу проверки достаточно сложной. Чтобы оптимизировать процесс тестирования и охватить больше комбинаций, подходит техника «Попарное тестирование». Она позволяет выявить дефекты, связанные с пересечением двух факторов, без необходимости полного перебора всех возможных комбинаций.
Что еще можно потестировать в данном примере
Для завершения тестирования модуля Service Desk и поиска необычных сценариев необходимо использование еще двух техник. Эти техники могут применяться как в первую очередь (если у QA мало времени и имеется достаточный опыт), так и в самом конце. На мой взгляд, второй вариант предпочтительнее.
«Предугадывание ошибок». Полезная техника для тревожных людей: хороший тестировщик помнит проблемы, которые возникали ранее, и переносит этот опыт на новые задачи. Например, если при переделывании лестницы в эскалатор были сложности, то появление задачи на установку траволатора между Lego‑домом и Lego‑магазином обязательно привлечет внимание. В нашем случае это часовые пояса. Часовые пояса и обработка времени вообще — дефолтное место для предугадывания ошибок, ну а нас тут еще рабочее расписание сотрудников, приукрашенное производственным календарем.
«Исследовательское тестирование». Эта техника предполагает творческий подход, так как тест‑кейсы здесь не прописываются заранее. Вместо этого тестировщик исследует систему, полагаясь на свои знания и интуицию, чтобы выявить нестандартные сценарии поведения пользователе. После основного тестирования QA уже успевает пройтись по всем уголкам документации и достаточно уверенно ориентируется в функциональности, поэтому в голове уже появляются идеи, как подступиться к задаче. Например, в нашем случае я проверяла кейсы типа: «Что произойдет, если сотрудников одной линии поддержки заказчика подключат к решению проблем другой линии».
______________
Спасибо, что дочитали до конца. В материале я хотела показать, как разные техники тестирования могут быть применимы к одной рабочей задаче, и вместе с тем разделены последовательностью применения. Полагаю, мой пример далеко не единственно верный, и количество деталей, вынесенных в примеры проверок, меньше, чем следовало учесть. Но теперь у всех есть возможность это проверить =)