Тест-дизайн
Таблица принятия решений и диаграмма состояний и переходов: примеры
Таблица принятия решений – техника тест-дизайна для логики, где результат зависит от сочетания условий: условия и действия системы сводят в таблицу, и каждый её столбец становится тест-кейсом. Диаграмма состояний и переходов описывает объект со статусами, например пользователя или заказ, и показывает, в каких состояниях он бывает и какие события переводят его из одного в другое. Обе техники полезны уже при анализе требований, потому что быстро показывают неучтённые сочетания и переходы, о которых стоит спросить аналитика.
- Столбец = тест
- каждое правило таблицы решений проверяют хотя бы одним тестом
- Одно состояние
- в каждый момент объект находится ровно в одном
- Бесплатно
- урок с заданиями в моём базовом курсе
Таблица принятия решений: что это и пример
Таблица принятия решений (decision table) показывает, что делает система при каждом сочетании условий. Условия записывают в верхние строки, действия в нижние, а каждый столбец – это правило, то есть уникальная комбинация условий и того, что из неё следует. Столбцы в разных источниках и компаниях называют тестами, правилами или значениями, и все три названия означают одно и то же. В русском переводе программы ISTQB Foundation 2018 года таблицу называют таблицей альтернатив.
Значения условий обычно пишут как Y и N (истина и ложь), прочерк означает, что значение не важно, а нужное действие отмечают X. Полная таблица содержит по столбцу на каждую комбинацию: у двух условий с двумя значениями их четыре, у трёх – восемь. Столбцы с невозможными сочетаниями или такими, где условие на результат не влияет, можно убрать. Покрытие по ISTQB считают как долю правил, проверенных хотя бы одним тестом.
Пример из урока строится на обычной форме входа по логину и паролю, без двухфакторной аутентификации. Условий два, логин валиден и пароль валиден, поэтому правил четыре, и каждое – готовый тест-кейс. Во всех трёх отказах сообщение одно: "Вы ввели неверный логин или пароль". Если система подскажет, что неверен именно пароль, злоумышленник узнает, что такой логин существует, и сможет подбирать к нему пароль программой. С этим подходом согласны не все, но я советую не уточнять, какое поле введено неверно.
Сокращённая таблица слила бы правила 3 и 4, ведь при неверном логине пароль на результат не влияет. На форме входа всё же полезно проверить все четыре, потому что одинаковое сообщение – само по себе требование и разойтись оно может в любом столбце.
Правило 1. Логин верный, пароль верный
Пользователь входит в систему, сообщений об ошибке нет.
Правило 2. Логин верный, пароль неверный
Вход не выполняется, появляется сообщение об ошибке.
Правило 3. Логин неверный, пароль верный
Вход не выполняется, сообщение то же.
Правило 4. Логин неверный, пароль неверный
Например, такого пользователя нет в системе. Вход не выполняется, сообщение то же.
Таблица решений для бизнес-логики: товары 18+ и счастливые часы
Второй пример ближе к тестовым заданиям. Интернет-магазин продаёт товары с возрастным ограничением 18+, например алкоголь и сигареты, и обычные товары. Есть счастливые часы со скидками, отдельные для мужчин и для женщин. Условий два: исполнилось ли пользователю 18 лет и какого он пола. Действия описывают, что можно купить и какие скидки доступны.
Таблицу решений часто просят применить в тестовом задании. Подсказка из урока: если в задании есть условие и несколько значений, которые оно может принимать, скорее всего, ждут именно таблицу. Условие про возраст к тому же делит пользователей на классы эквивалентности, поэтому обе техники лучше использовать вместе, а возраст у самой границы, 17 и 18 лет, стоит проверить отдельно.
Пустые клетки таблицы сразу видны. Если в требованиях не сказано, какое сообщение увидит пользователь младше 18 лет при попытке купить товар 18+, вопрос уходит аналитику, а если такого экрана нет на макетах, то дизайнеру.
Мужчина, 18 лет и старше
Доступны все товары и мужские счастливые часы, женские часы недоступны.
Женщина, 18 лет и старше
Доступны все товары и женские счастливые часы, мужские часы недоступны.
Мужчина младше 18 лет
Доступны только товары без возрастного ограничения и мужские счастливые часы.
Женщина младше 18 лет
Доступны только товары без возрастного ограничения и женские счастливые часы.
Что такое диаграмма состояний и переходов
Техника подходит для всего, у чего есть статус: пользователя, заказа, документа, платежа. Состояние говорит, в каком положении сейчас объект. Переход, который ещё называют действием, показывает, что нужно сделать, чтобы объект перешёл из одного состояния в другое. Незарегистрированный пользователь после регистрации становится зарегистрированным, а после правки профиля его данные оказываются изменены.
По ISTQB каждый переход вызывается событием, например вводом данных. Если одно событие может привести к разным переходам, выбор задаёт защитное условие (guard), а сам переход может закончиться действием системы, например сообщением. Диаграмма обычно показывает только допустимые переходы. Таблица переходов дополняет её и перечисляет все сочетания состояний и событий, включая недопустимые, и по ней видно, что должно случиться, если событие пришло в неподходящем состоянии.
На практике таблица переходов ловит такие дефекты. В приложении доставки заказ проходит статусы "Создан", "Оплачен", "Передан курьеру", "Доставлен" и "Отменён". Таблица подсказывает проверить отмену в каждом статусе: оплаченный заказ отменяется с возвратом денег, а у доставленного отмены по требованиям быть не должно. Кнопки "Отменить" у доставленного заказа в интерфейсе нет, но если тот же запрос на отмену, отправленный через Postman, проходит и деньги возвращаются, это дефект недопустимого перехода.
Думать здесь стоит об объекте в базе данных. Запись вроде "нажать кнопку, чтобы пользователь попал в систему" на диаграмме неуместна, здесь важно, какое состояние принимает объект и что его меняет. ISTQB применяет технику шире, например к меню и переходам между экранами, но и там на схеме изображают состояния и события.
На диаграмме один объект
Если рисуется пользователь, то корзина и оплата заказов на этой схеме не нужны, для них будет своя диаграмма.
В каждый момент одно состояние
Объект не может быть одновременно на модерации и активным. Если на схеме так получается, состояния выделены неверно.
Переход делает пользователь или система
Пользователь регистрируется сам, а модерацию может проводить система автоматически. И то и другое – переходы, и оба попадают на диаграмму.
Пример диаграммы: пользователь и модерация
В уроке диаграмма строится для пользователя в системе, где новые профили проходят модерацию. Её проводит система автоматически или модератор. Ниже переходы этой схемы, и по каждому из них пишут тест-кейс.
Кроме допустимых переходов проверяют недопустимые. Например, незарегистрированный пользователь не должен стать активным в обход модерации, а удалённый не должен суметь обновить профиль. В программе ISTQB 2023 года покрытие описано тремя уровнями: все состояния, все допустимые переходы и все переходы вместе с недопустимыми.
Признаюсь, на работе я рисую такие схемы нечасто, потому что не всегда хватает времени. Зато на этапе анализа требований диаграмма быстро показывает исключительные случаи, и по ней можно уточнить у аналитиков, что происходит с объектом на каждом шаге. Так тестировщик помогает сделать требования лучше для всей команды.
Не зарегистрирован → На модерации
Переход – регистрация пользователя.
На модерации → Активен
Модерация пройдена, и пользователь может работать в системе.
На модерации → Не активен
Модерация не пройдена. Система или модератор присылает письмо с просьбой внести правки, и до этого пользователь ничего не может делать в системе.
Не активен → На модерации
Пользователь внёс правки и снова отправил профиль на проверку.
Активен → На модерации
Пользователь обновил данные профиля, и они снова уходят на модерацию. Схема замыкается в круг, и для объекта со статусами это нормально.
Активен → Удалён
Пользователь удаляет себя сам. Может ли его удалить система, в требованиях не сказано, и это повод задать вопрос аналитику.
Причина и следствие, предугадывание ошибок и выбор техники
В том же уроке я разбираю ещё две техники. Причина и следствие (cause-effect) связывает действие с тем, что оно вызывает. Нажатие кнопки регистрирует пользователя, после удаления пользователя под его данными нельзя войти, при смене роли с администратора на модератора отключаются модули, а после запуска отчёта появляется кнопка отмены. Сначала изучают документацию и пользовательские истории и выписывают причины и следствия, в том числе те, которых в требованиях нет, но которые подсказывает опыт. Потом их связывают между собой и добавляют негативные проверки, а связки удобно сводить в таблицу решений.
Предугадывание ошибок (error guessing) опирается на опыт тестировщика. Если в требовании сказано, что в поле можно ввести 15 символов, опытный тестировщик сразу проверит максимум, минимум, недопустимые спецсимволы и пустое значение. Самостоятельной техникой я её не считаю, это надстройка над остальными. В ISTQB предугадывание ошибок относится к техникам, основанным на опыте.
В конце урока я подвожу итог трём занятиям о тест-дизайне и объясняю, какую технику когда брать.
Поля ввода
Классы эквивалентности и граничные значения.
Много параметров и настроек
Фильтры, сортировки и настройки проверяют попарным тестированием, а значения для него выбирают классами эквивалентности.
Условие с несколькими значениями
Например, пользователь старше или младше 18 лет. Подходят классы эквивалентности и таблица принятия решений.
Объект со статусами и сложная бизнес-логика
Диаграмма состояний и переходов или функциональная декомпозиция, когда приложение разбивают на модули, модули на подмодули и рисуют майнд-карту.
Поверх любой техники
Причина и следствие и предугадывание ошибок, когда уже есть опыт и знание продукта.
Видеоурок, шпаргалки и тренажёры
Я разбираю эти техники в ролике о тестировании состояний и переходов и таблице принятия решений на YouTube, вместе с причиной и следствием и предугадыванием ошибок. Это продолжение уроков о классах эквивалентности, граничных значениях и попарном тестировании. В бесплатном базовом курсе по тестированию тема идёт уроком "Таблица принятия решений, таблицы переходов и состояний", и после теории в нём есть задания.
Шпаргалка по таблице решений устроена как конструктор, в котором условия и действия раскладываются по таблице. Шпаргалка по состояниям показывает кликабельную диаграмму заказа с покрытием переходов. В тренажёрах нужно собрать матрицу условий и решений и найти, где логика противоречит себе, а ещё восстановить жизненный цикл объекта с запрещёнными путями.
Курсы по теме
Вопросы и ответы
Что такое таблица принятия решений в тестировании?
Техника тест-дизайна для логики, где результат зависит от сочетания условий. Условия и действия системы записывают в таблицу, и каждый столбец описывает одно правило, то есть сочетание условий и ожидаемых действий. По каждому правилу пишут хотя бы один тест.
Как составить таблицу принятия решений?
Выписать из требований условия и действия, перечислить все сочетания значений условий (у трёх условий с двумя значениями их восемь) и для каждого отметить, что должна сделать система. Затем убрать невозможные сочетания и те, где условие на результат не влияет, и по каждому оставшемуся столбцу написать тест.
Что такое диаграмма состояний и переходов?
Схема объекта со статусами: в каких состояниях он бывает и какие события или действия переводят его из одного состояния в другое. По ней пишут тесты на каждое состояние и каждый допустимый переход и проверяют, что недопустимые переходы система не выполняет.
Чем таблица решений отличается от диаграммы состояний?
Таблица решений описывает один момент: какие действия следуют из сочетания условий. Диаграмма состояний описывает историю объекта, где результат зависит от того, в каком состоянии он сейчас и что с ним было раньше. Для формы входа подходит таблица, для жизненного цикла заказа или пользователя – диаграмма.
Какую технику тест-дизайна выбрать?
Поля ввода проверяют классами эквивалентности и граничными значениями. Если параметров и настроек много, берут попарное тестирование, если результат зависит от сочетания условий, составляют таблицу решений, а для объектов со статусами рисуют диаграмму состояний и переходов. Предугадывание ошибок и анализ причин и следствий работают поверх любой из них.
Просят ли применить таблицу решений в тестовом задании?
Да, и часто. Если в задании есть условие с несколькими значениями, например возраст или тип пользователя, скорее всего, от вас ждут таблицу принятия решений.
Посмотреть программы курсов
Программа каждого курса открыта целиком: видны все модули, уроки и число шагов.