Привет, я Мариам Джанунц, мидл QA-инженер Битрикс24 в Далее. В статье покажу на реальных примерах, как использовать методы тест‑дизайна при проверке сложных бизнес-процессов. Когда есть десятки ролей, ветвлений и условий — и один баг в логике может сломать всю цепочку.

Материал полезен QA, проектным менеджерам, аналитикам и всем, кто работает с enterprise-решениями — системами, в которых важна устойчивость и прозрачность CJM. Вы узнаете, как не утонуть в бесконечных кейсах и минимальными артефактами держать под контролем весь процесс.

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

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

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

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

Давайте познакомимся с этими техниками ближе: 

• decision tables — таблицы принятия решений;

• выделение классов эквивалентности для бизнес-логики;

• прием «ядро + вариации»;

• state transition testing — тестирование переходов состояний;

• визуализация процессов с помощью карт состояний и схем переходов;

• пять вопросов, которые меняют отношение к тест-дизайну.

Это поможет вам лучше понять логику работы системы и выявить потенциальные проблемы. 

Подбор техники под задачу: когда использовать decision tables

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

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

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

Техника decision tables позволяет компактно описать все комбинации условий и действий, визуализировать их и увидеть, где есть дыры в логике.

Пример

Допустим, вы разрабатываете систему расчета страховых выплат. На сумму выплаты влияют:

• Возраст клиента: до 25 лет / 25–60 / старше 60.

• Стаж вождения: меньше 2 лет / больше 2 лет.

• Тип авто: эконом / бизнес / спорт.

• Страховые случаи: были / не было.

• Регион проживания: обычный / повышенного риска.

Кажется, можно просто прикинуть пары условий и протестировать вручную.

Но даже при трех возможных значениях в трех полях мы получаем 27 комбинаций. А с 5 полями — 243 возможных сценария.

Люди не умеют держать в голове 243 комбинации, важно учитывать логику программиста. Мы склонны мыслить линейно: если возраст < 25, то +10% к тарифу. Но сочетание «возраст < 25 + спорткар + 0 страховых случаев + Москва» может вести к скидке — и это уже другая логика.

И вот тут возникает вопрос — как убедиться, что система точно корректно обрабатывает ВСЕ 243 сценария? 

Decision table превращает хаос в карту. Мы можем визуально увидеть: где есть дыры в логике, какие комбинации забыты, а какие — избыточны.

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

Стоит учитывать и масштаб. Если количество комбинаций превышает разумные пределы (более 50-100), то необходимо группировать условия или использовать попарное тестирование для сокращения объема проверок.

Как выделять классы эквивалентности для бизнес‑логики

Equivalence Class Partitioning, или разбиение классов эквивалентности — метод, который основан на простой идее: 

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

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

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

Пример #1

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

• Возраст заемщика до 18 лет → отказ

• Возраст 18-65 лет → рассматривается по другим критериям

• Возраст свыше 65 лет → отказ

Вместо тестирования каждого возраста от 0 до 120 лет (что абсурдно), мы выделяем три класса эквивалентности и тестируем по одному представителю возрастом 16, 35 и 70 лет. Три теста вместо ста двадцати — при том же качестве покрытия.

Пример #2

Вернемся к нашей более сложной системе расчета страховых гарантий. Рассмотрим факторы влияния — стаж и количество ДТП. Каждый параметр создает свои классы эквивалентности:

Стаж вождения:

• 0-2 года → коэффициент 1.8

• 3-10 лет → коэффициент 1.2

• Свыше 10 лет → коэффициент 1.0

Количество ДТП за три года:

• 0 ДТП → без доплат

• 1-2 ДТП → коэффициент 1.5

• 3+ ДТП → коэффициент 2.0 или отказ

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

Этот подход универсален. Его используют не только тестировщики, но и аналитики при проектировании систем, продуктовые менеджеры при планировании функций, разработчики при создании архитектуры. ISTQB включил эквивалентные классы в базовый стандарт не случайно — это фундаментальный принцип качественного анализа.

Как не захлебнуться в сценариях: прием «ядро + вариации»

Метод «Ядро + Вариации» переворачивает привычную логику. Вместо попыток описать все возможные пути, мы фокусируемся на одном идеальном маршруте и точечных отклонениях от него.

Ядро — это золотой путь пользователя, тот самый happy path, который покрывает 80% всех транзакций. Обычно это список из 10-15 шагов, описывающий идеальное взаимодействие от начала до конца.

Вариации — это не альтернативные сценарии, а именно точки отклонения. Места, где что-то может пойти не так или пользователь может поступить иначе. «А что, если сумма изменится на последнем шаге?», «А что, если внешний сервис вернет ошибку?», «А что, если у пользователя нет нужных прав?»

Как пользоваться приемом «Ядро + Вариации»

Шаг 1: Нарисуйте карту процесса

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

Шаг 2: Найдите точки турбулентности

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

Шаг 3: Сформулируйте вариации

Для каждой точки турбулентности опишите 1-2 коротких отклонения. Не больше! Цель — не покрыть все возможные исходы, а проверить критические развилки.

Шаг 4: Создайте живую документацию

Оформите результат в виде наглядной схемы: ядро в центре, вариации — как лепестки вокруг. Такой формат легко понимать и просто обновлять.

Пример #1

Рассмотрим процесс онлайн-покупки. В классическом подходе мы бы создали десятки сценариев: «Покупка с картой», «Покупка с бонусами», «Покупка со скидкой», «Покупка с измененным адресом» и так далее. В методе «Ядро + Вариации» это выглядит совершенно иначе.

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

Пример #2 

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

До внедрения метода команда поддерживала 45 тест-кейсов только для базового флоу. После применения «Ядро + Вариации» количество сократилось до 8, а выявляемость критических багов выросла на 30%.

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

Классический подход превращает тестирование в конвейер по обработке чек-листов. Метод «Ядро + Вариации» заставляет думать о рисках и приоритетах. Кроме того, эта техника естественным образом адаптируется к изменениям. Новое требование чаще всего затрагивает одну-две точки, а не весь процесс целиком. Вместо переписывания десятков сценариев вы корректируете одну вариацию.

Когда система помнит прошлое: где помогает state transition testing

Возьмем банковскую карту. Попробуйте три раза ввести неверный ПИН — и карта заблокируется. Но если вы введете правильный ПИН с первого раза, никаких проблем не возникнет. Тот же самый ввод (правильный ПИН) дает разные результаты в зависимости от предыдущих действий.

Современные системы редко работают как простые калькуляторы, где результат зависит только от введенных данных. Они «помнят» прошлые действия пользователя, и это влияет на поведение.

Тестирование переходов состояний становится особенно важным в системах, где:

• Пользователи могут менять решения и возвращаться к предыдущим шагам.

• Есть сложные бизнес-процессы с множественными согласованиями.

• Интегрированные внешние сервисы могут работать с задержками.

• Данные имеют жизненный цикл и меняют свой статус со временем.

Ошибки в логике могут привести к финансовым потерям или нарушению законодательства.

Метод state transition testing включает:

• Создание карты состояний

Первый шаг — визуализировать все возможные состояния системы и переходы между ними. Это похоже на создание карты метро: каждая станция — состояние, каждая линия — возможный переход.

• Тестирование валидных переходов

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

• Проверку невалидных переходов

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

• Изучение пограничных состояний и исключений

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

Пример 

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

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

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

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

Как визуализировать процессы для удобства работы

Вот нам дали 30 страниц ТЗ с описанием функционала согласования документов. В процессе участвуют пять департаментов, каждый имеет свои полномочия, есть исключения для срочных случаев, возможности отката, параллельные ветки для разных типов документов... К пятой странице глаза начинают слезиться, а к десятой — мы понимаем: мозг отказывается воспринимать информацию в таком формате.

Здесь помогает визуализация — инструмент, который превращает текстовый хаос в понятную картину. 

Рисуем карту состояний

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

Качественная карта состояний содержит несколько ключевых элементов

Состояния — это существительные, описывающие положение объекта: «Создана», «На согласовании», «Отклонена», «Исполняется». Каждое состояние должно быть четко определено, чтобы было понятно, что означает нахождение объекта в этом статусе.

Переходы — это глаголы, действия, которые переводят объект из одного состояния в другое: «согласовать», «отклонить», «отправить на доработку». Важно указывать не только действие, но и кто его может выполнить.

Условия — ограничения и правила, при которых переход возможен. Например, переход «согласовать» доступен только руководителю и только в рабочие дни до 18:00.

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

Цветовая навигация — цветовое кодирование элементов схемы. Зеленые стрелки обычно обозначают позитивные переходы — движение процесса вперед к желаемому результату. Красные — критические точки, где процесс может завершиться неудачно. Оранжевые или желтые — возвраты и доработки. Серые — технические переходы, не влияющие на основной поток.

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

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

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

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

• Разработчик видит, какие статусы нужно предусмотреть в базе данных и какие права доступа настроить. 

• Product-менеджер может оценить сложность пользовательского пути и найти места для упрощения.

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

Пять вопросов, которые меняют отношение к тест-дизайну

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

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

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

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

1. Что именно я проверяю? Конкретное условие, переход состояний, граничное значение? Размытые цели порождают размытые тесты.

2. Почему именно это стоит проверять? Какой риск я закрываю? Какую бизнес-ценность защищаю? Если ответа нет — возможно, этот тест не нужен.

3. Сколько различных классов или состояний здесь присутствует? Часто оказывается, что то, что казалось одним сценарием, на самом деле содержит множество скрытых вариаций.

4. Есть ли у меня хотя бы один тест на каждый значимый класс или переход? Пропуски в покрытии — это потенциальные баги в продакшне.

5. Могу ли я удалить дублирующие проверки, не потеряв смысл? Каждый лишний кейс — это дополнительные затраты на поддержку.

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

True Story

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

Было: 1100+ поддерживаемых кейсов, регресс занимал 3 дня, в продакшн попадало 4-5 критических багов за квартал.

Стало: 320 структурированных кейсов, регресс укладывается в день, критических багов — не более одного за квартал.

Но дело не только в цифрах. Команда наконец-то успевает проводить регресс в рамках спринта. Задачи на релиз готовы на сутки раньше. Разработчики получают фидбек практически в реальном времени, что кардинально меняет качество итогового продукта.

Качество — это не количество выстрелов, а точность попаданий. В мире, где скорость решает все, побеждают те, кто умеет делать меньше, но лучше.

А какие техники структурного тест-дизайна используете вы? Как они помогают вам улучшить проверку?