Привет! Я работаю в компании «ЛАНИТ Экспертиза» тест‑лидом на проектах систем электронного документооборота и хочу поделиться практическими наработками в области формирования тестовой модели с использованием средств визуализации. В профессиональной деятельности часто встречаются ситуации, когда необходимо быстро погрузиться в систему или часть функционала и приступить к тестированию. Однако сделать это может быть невозможно по ряду таких причин, как фрагментированное описание, высокая сложность и многомерность процессов, отсутствие коммуникации с экспертами по системе. В этом случае одним из способов решения задачи быстрого погружения и старта может стать формализация процессов системы в графический вид или их комбинации, удобные для актуализации, использования и масштабирования количества участников процесса тестирования.

Виды схем и их применение

Существует ряд устоявшихся практик структурирования информации в графическом виде.

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

Рисунок 1. Mindmap системы электронного документооборота 
Рисунок 1. Mindmap системы электронного документооборота 
  • Блок-схема. Принцип построения - иллюстрация процесса с помощью специальных символов - блоков. Применяется для детального описания одного конкретного процесса.

Рисунок 2. Блок-схема согласования документа 
Рисунок 2. Блок-схема согласования документа 

На рис. 2 использованы основные элементы.  К примеру “Подготовка документа к согласованию” является действием, “Согласование 1” — цикл решения, этап процесса, в котором формируется ответ.

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

Рисунок 3. Диаграмма переходов и состояний, где 1-14 действия в системе, позволяющие осуществить переход от одного состояния в другое
Рисунок 3. Диаграмма переходов и состояний, где 1-14 действия в системе, позволяющие осуществить переход от одного состояния в другое
  • ER-диаграммы. Принцип построения - визуализация модели БД в виде сущностей и отношений между ними (типы связей в БД). 

Рисунок 4. ER-диаграмма модели БД
Рисунок 4. ER-диаграмма модели БД

Для построения ER-диаграмм важно определить сущности (данные) и их атрибуты и после этого выстроить связи (на основе их характеристик) между сущностями. На рис. 4 представлены различные виды связей: один к одному, один ко многим, многие ко многим.

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

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

Принципы построения структурно-логических схем

Для построения структурно-логических схем подходят все источники информации о проекте:

  • проектная документация;

  • консультации с аналитикой;

  • обучающие видео по системе;

  • показы функционала;

  • пользовательские сценарии.

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

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

Рисунок 5. Структурно-логическая схема согласования документа руководителем
Рисунок 5. Структурно-логическая схема согласования документа руководителем

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

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

Например, начиная с блока “Подготовка документа Автором” и двигаясь по линии потока 1-го приоритета до блока “Документ отправляется следующему руководителю”, мы получаем проверку с приоритетом “смоук”: “Подписание Руководителем  документа с типом  А с выбранным статусом  без внесения изменений с заполнением обязательных полей”.

Если же двигаться по линии потока вверх от блока “Работа с документом руководителем” к блоку “Вернуть”, то мы получаем проверку с приоритетом “регресс”: “Возврат Руководителем документа Автору с внесением исправлений в документ с типом  А с выбранным статусом с заполнением обязательных полей”.

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

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

Рисунок 6. Чек-лист по проверке рассматриваемой сущности и её состояний с приоритезацией проверок 
Рисунок 6. Чек-лист по проверке рассматриваемой сущности и её состояний с приоритезацией проверок 

Выводы и рекомендации

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

  2. На основании таких схем возможна подготовка чек-листов по проверке рассматриваемой сущности и её состояний с приоритезацией проверок:

    • основной процесс → проверки 1-го приоритета,

    • ветвления процесса → проверки 2-го приоритета.

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

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

Комментарии (2)


  1. AleksSharkov
    14.10.2025 08:11

    С теорией понятно, а что с инструментами? Где удобнее рисовать? Может где-то можно yaml в схему перегонять? Что из этого OpenSource?


    1. Robtheguitar Автор
      14.10.2025 08:11

      Добрый день!

      Для схем использовал Draw io, для процессов yEd Graph Editor или Miro.

      Для майнд-карт MindMeister или MindMup.

      Про yaml не подскажу, с ним не работал.