Decision Table (таблица решений) — техника, помогающая наглядно изобразить комбинаторику условий из ТЗ.

Чем проще и понятнее требования, тем меньше будет разночтений. И тем меньше исправлений после реализации. И тем проще нам, тестировщикам, писать тест-кейсы по таким требованиям.

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

Decision Table относится к техникам тест-дизайна. Значит, про неё спрашивают на собеседованиях. И поэтому я сделаю небольшой цикл статей по таким техникам в помощь начинающим тестировщикам. Чтобы ознакомиться с каждой техникой:

1. Вариант использования

2. Decision Table (таблицы решений) — текущая статья

3. State & Transition Diagramm (схема состояний и переходов) — TBD

4. Другие диаграммы, схемы, картинки (бонус такой к техникам) — TBD

Сегодня говорим про Decision Table (таблица решений):

1. Как составлять таблицу

2. Плюсы подхода

3. Минусы подхода

4. Итого

Помимо статьи есть видео о таблице решений с моего канала. Кому что удобнее! :)

Как составлять таблицу

• По горизонтали — выписываем условия, которые влияют на результат. А чуть ниже — сам результат, в оригинале Action — действие, которое нужно выполнить.

• По вертикали — правила: конкретная комбинация входных условий.

То есть мы указываем значения условий и результата

Давайте посмотрим на простом примере — когда у нас один результат (action).

Пример 1. Страховка на автомобиль (один результат)

Я прихожу в страховую компанию и заполняю анкету, где есть 2 вопроса:

1. Есть ли 5 лет стажа вождения?

2. Была ли в авариях?

Ответить можно либо да, либо нет.

Получается 2 условия по 2 возможных варианта, итого 4 варианта пересечения условий, 4 правила. На каждое правило свой результат:

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

• Если нет стажа, но нет аварий — плачу поменьше, но не сильно. Знаете как бывает — первое время катаются очень осторожно, а потом начинают думать «да я царь и бог, не попаду в аварию». И понеслось...

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

• Если опытный, да еще и без аварий — меньше всего. Очень аккуратный водитель, платить скорее всего не придется!

А теперь то же самое, только в виде таблички:

Согласитесь, табличка выглядит лучше стены текста выше, да? Еще лучше может быть только картинка!

Но для красивой картинки нужно уметь рисовать. А для составления таблички — нет! И в этом её удобство — можно не быть художником, но наглядно переписать ТЗ.

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

У нас может быть не 2 условия, а 3 или больше. И действий тоже может быть больше одного. Получается больше правил и больше возможности их скомбинировать:

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

Пример 2. Интернет-магазин (множественный результат)

Есть интернет-магазин, который предлагает:

• Скидку постоянного покупателя

• Количество вещей, которые курьер привезет бесплатно

Это такие плюшки за лояльность и повторную покупку. Как плюшки высчитываются? Есть два условия:

• Сколько клиент потратил (всего или за какой-то период времени) — бонус добавляется при достижении 100р, 500, 1000 и 5000

• Какой процент выкупа (а то, может, курьер зря мотается) — бонус получаем при достижении 5%, 30%, 50% и 80%

Если я потратила 100р и почти ничего не выкупила — скидки мне не дадут и вещей мало привезут. Если потратила больше и выкупила больше, то дадут небольшую скидочку. Ещё потрачу — станут вещей больше привозить... И так далее.

Положим требования в таблицу:

Заметьте, что условия 2, и в каждом возможны 4 варианта — это 16 возможных пересечений, 16 тестов!

Попробуем записать все условия:

Даже в виде таблицы уже сложновато читается... А в виде простого текста вообще ничего не разберешь!

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

• Потратил 100 р — 0% скидка

• 500 — 5%

• 1000 — 10%

• 5000 — 20%

А количество вещей будет зависеть от выкупа... Тогда и без таблички можно оставить в ТЗ, вполне понятный список!

Но сложные взаимосвязи между разными условиями также встречаются. И если они у вас есть — составьте decision table хотя бы один раз. Чтобы разобраться во всех этих правилах, всё учесть и ничего не забыть!

Плюсы подхода

1. Наглядность — таблица нагляднее текста. Можно взять таблицу и подойти к аналитику с каким-то вопросом. Или к разработчику. Им будет проще понять, о чём речь, чем если вы принесете стену текста.

2. Нарисовал таблицу = записал тест-кейсы. Поменял в заголовках слово «правило» на «тест-кейс», и вот они, готовые тесты! И это будут основные позитивные тесты, которые мы проводим в первую очередь.

Если неудобно, что тест приходится читать сверху вниз, а не слева направо, таблицу можно инвертировать — перевернуть:

3. Наглядность поможет найти баги в документации. Так как косяк формулы будет сразу бросаться в глаза.

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

Минусы подхода

Особых минусов нет, но таблица не нужна, если:

• Слишком простое условие — потому что «но зачем?». И так все понятно.

• Слишком много входных данных — овер дофига будет колонок. Много тестов, но мало результата, потому что тут уже нужен тест-анализ, pairwise и т.д.

Итого

Decision Table используется для описания сложных системных правил:

• Условия представляют собой входные данные.

• Действия – это ожидаемый результат.

• Колонки – тест-кейсы!

Я настоятельно рекомендую применять эту технику хотя бы однократно — к тем требованиям, которые вы уже знаете наизусть. Думаете, проверили все возможные комбинации? Нарисуйте таблицу решений и результат вас удивит!

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

См также:

Как составлять вариант использования — ещё один вариант оформления требований.

PS — больше полезных статей ищите в моем блоге по метке «полезное». А полезные видео — на моем youtube-канале