2.3 Тестирование состояний и переходов / Таблица принятия решений

Тестирование состояний и переходов

Тестирование таблицы переходов (state transition testing) - разработка тестов методом черного ящика, при котором сценарии тестирования строятся на основе модели переходов состояний. [ISTQB Glossary]

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

Переход​ - это изменение состояния из одного в другое, произошедшее благодаря какому-то событию.

Событие​ - что-то, что вызывает изменение состояния системы.

Действие​ - это операция, которая вызвана изменением состояния.

Пример

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

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

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

Правила по Тестированию состояний и переходов:

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

Пример - Схема состояний и переходов - Пользователь регистрируется в системе

Таблица принятия решений

Таблица принятия решений – хороший способ записи сложных бизнес-правил, которые должны быть реализованы в системе. В процессе создания таблицы, тестировщик определяет условия (входы) и результирующие действия системы (выходы). Пары условий и действий образуют строки таблицы, при этом условия указываются сверху, а действия – снизу. [ISTQB CTFL Syllabus 2018]

Пример

Оклад сотрудника рассчитывается следующим образом:

• без опыта и высшего образования - 500
• с высшим образованием, но без опыта - 600
• без высшего образования, с опытом - 600
• с опытом и высшим образованием - 700

Премия для сотрудника рассчитывается следующим образом:

• без опыта и высшего образования - 5%
• с высшим образованием, но без опыта - 10%
• без высшего образования, с опытом - 15%
• с опытом и высшим образованием - 20%

Ваша задача протестировать приложение, которое должно рассчитывать оклад и премию сотрудника.

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

Итоговую таблицу необходимо использовать для создания чек-листа или тест-кейсов.

На основании столбцов Тест составляются тест-кейсы.

Техника тест-дизайна Причина и следствия и Предугадывание ошибок

Причина и следствия

Алгоритм:

1. Изучение документации и требований.
2. Выделяем причины и следствия.
3. Связываем причины и следствия между собой.
4. Продумываем негативные проверки, пути невозможности запуска следствия без причины.
5. На основании этого придумываем тестовые сценарии, в том числе можно использовать таблицу принятия решений.

Пример: Нажать кнопки --> запуск функции Удаление пользователя --> невозможность авторизоваться ||| Изменение ролей --> Невозможность выполнять некоторые действия ||| Запуск формирования отчета --> возможность его отменить

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

Предугадывание ошибок

Алгоритм:

1. Изучение требований.
2. На основании опыта тестировщик может предугадать возможные ошибки и дать обратную связь.

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

ИТОГ ПО ТЕХНИКАМ ТЕСТ-ДИЗАЙНА

1. Если это поля ввода - Класс эквивалентности и Граничные значения
2. Если много веб-форм, фильтры, сортировка, надстройки - Попарное тестирование + немного Класс эквивалентности и Граничные значения
3. Если сложные бизнес-логики - Функциональная декомпозиция (берем приложение, разбиваем его на модули, модули - на субмодули и тестируем их), Диаграмма состояний и переходов
4. Если есть пара условий (старше / младше 18 лет) - Класс эквивалентности и Таблица принятия решений

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