- Зачем нужна
- Пример
- Преимущества и недостатки
- Советы по составлению
- Контрольные вопросы / Собеседование
Когда QA тестирует систему со сложной бизнес-логикой, ему бывает сложно написать тест-кейсы со всеми возможными комбинациями ввода-вывода: их получается слишком много. Что обычно тестировщики делают в такой ситуации? Пишут тест-кейсы и параллельно продумывают возможные комбинации. Здесь возникает вероятность упустить какие-то сценарии, поскольку внимание рассредоточено между двумя задачами — описаниями тест-кейсов и продумыванием сценариев/комбинаций.
Отличный метод не упустить все возможные сценарии — сделать таблицу решений (Decision Table, DT), где решения описаны в наглядной, легко читаемой форме.
Что это и зачем нужна
Это методика тестирования системы при разных комбинациях на входе, и результатов на выходе. “Системный” подход, организованный, тем и удобный.
Цель тестирования по этой методике — повысить общее тестовое покрытие, не упуская все (возможные) комбинации.
Пример
Например у тестировщика есть страница с логином-паролем.
Имеем требования:
- Пользователь должен залогиниться, вводя правильные User ID/Password.
- Пользователь не должен залогиниться, если комбинация неправильная; выдается сообщение “Неверные данные”, если любое из двух значений неправильное (или пустое).
Глядя на требования, видим, что наша Таблица Решений будет состоять из:
- Двух условий: user_id и password
- Двух действий: Логин успешный; или Ошибка, выдается сообщение “Некорректные данные”
- Трех опций: Пустое; Правильное; Неправильное; (поле)
Теперь заполняем нашу Decision Table:
Готово!
Общее количество тест-кейсов: (опции)^(условия) = 3^2 = 9 тест-кейсов.
Пример 2
Передача на сервер фотографии. Имеем ограничения (требования):
- Исключительно JPEG
- Не превышает 32 Кб
- Разрешение (соотношение сторон) исключительно 137х177
При несоответствии любому из 3 требований система выдает ошибку, с описанием что случилось. Если все 3 требования соблюдены, фотография загружается на сервер.
Формируем нашу таблицу:
Требования : | Кейс 1 | Кейс 2 | Кейс 3 | Кейс 4 | Кейс 5 | Кейс 6 | Кейс 7 | Кейс 8 |
Формат | .jpeg | .jpeg | .jpeg | .jpeg | ≠.jpeg | ≠.jpeg | ≠.jpeg | ≠.jpeg |
Размер | < 32 Кб | < 32 Кб | > или = 32 Кб | > или = 32 Кб | < 32 Кб | < 32 Кб | > или = 32 Кб | > или = 32 Кб |
Соотношение | 137*177 | ≠ 137*177 | 137*177 | ≠137*177 | 137*177 | ≠137*177 | 137*177 | ≠137*177 |
Ошибка | Фотография загружена (все ОК) | Недопустимое Соотношение | Ошибка: недопустимый размер | Ошибка: недопустимые размер и соотношение | Ошибка: недопустимый формат | Ошибка: недопустимые формат и соотношение | Ошибка: недопустимые формат и размер | Ошибка: недопустимые формат, размер и соотношение |
Из наших условий следует, что должно быть 8 кейсов.
Преимущества и недостатки метода
Плюсы
- Проверяются все возможные комбинации
- Легко найти какие-то упущенные требования
- Более полное покрытие тест-кейсами, поэтому потом не переписываются сценарии и тест-кейсы
- Сложные бизнес-требования подаются в наглядной форме, удобной пользователям, разработчикам, и разумеется тестировщикам
Минусы
- Бывает довольно сложной при отсутствии требований или неясно сформулированных требованиях
- Таблицы “разрастаются” при большом количестве входных значений, теряя простоту, то есть главное свое преимущество. Ведь количество комбинаций, как известно, равно 2 в степени n, где n = количество вводов
Таблица решений считается “полной” (или сбалансированной”), если содержит все возможные комбинации входных переменных; иными словами, “полная” таблица решений — это когда прописано действие по каждой имеющейся комбинации входных переменных.
Очень древняя методика — применялась еще в 1960х и 1970х для обработки бизнес-логики; создали даже специальные языки программирования под такие задачи.
Советы по составлению
- Классифицируй и сгруппируй условия и действия
- Таблица решений должна иметь только одну “точку входа”
- И может иметь много “точек выхода”
- Правила можно прописывать в любом порядке, но лучше если они логично сгруппированы
- Если есть два условия, одно из которых противоположно другому, убери одно из них
- Максимальное количество колонок у тебя не должно получиться больше чем 2^n, n = количество условий
Контрольные вопросы / Собеседование QA Junior — Таблица решений
Что такое таблица решений?
В более широком смысле: табличное представление процесса принятия решений. В QA: удобнейшая методика тестирования комбинаций вводов (и связанных с ними) выводов, организованных в табличном виде; в таблице решений “вводы” это условия, “выводы” это действия.
Для чего нужна таблица принятия решений? Как ее можно использовать?
Применяется, главным образом, в тестировании черного ящика. Очень помогает в дизайне тест-кейсов. Полезна при обработке сложных бизнес-требований с множеством условий.
Какие компоненты входят в таблицу решений?
Таблица решений — это двухмерная матрица, в которой есть четыре компонента: Заголовок условия (condition stub), Заголовок действия (action stub), Условие (condition entry), и Действие (action entry) — рисунок ниже.
Более простыми словами, таблица решений состоит из условий (в заголовках строчек и колонок), и действий (в точках пересечения условий).
Компоненты таблицы решений:
Какие основные этапы составления таблицы принятия решений?
- Проанализировать требования и создать первую колонку
- Добавить еще колонки, в количестве 2^(количество условий)
- Сократить таблицу при необходимости, убрав ненужные колонки если они идентичные
- Определить и прописать действия в таблице
- Далее написать тест-кейсы.