Как стать автором
Обновить

Decision Table — что это и как применять

Тестирование IT-систем *Тестирование веб-сервисов *Подготовка технической документации *

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

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

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

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

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

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

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

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

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

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

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

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

  4. Итого

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

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

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

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

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

 

Правило 1

Правило 2

...

Правило N

Условия

 

 

 

 

Условие 1

 

 

 

 

Условие 1

 

 

 

 

...

 

 

 

 

Условие N

 

 

 

 

 

 

 

 

 

Действия

 

 

 

 

Действие 1

 

 

 

 

Действие 2

 

 

 

 

...

 

 

 

 

Действие N

 

 

 

 

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


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

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

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

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

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

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

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

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

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

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

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

 

Правило 1

Правило 2

Правило 3

Правило 4

Условия

 

 

 

 

Стаж 5 лет

Нет

Нет

Да

Да

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

Да

Нет

Да

Нет

 

 

 

 

 

Результат

 

 

 

 

Страховка

200 руб

100 руб

50 руб

10 руб

 

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

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

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


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

 

Правило 1

Правило 2

...

Правило N

Условия

 

 

 

 

Условие 1

Нет

Нет

Да

Да

Условие 2

Да

Нет

Нет

Да

Условие 3

Нет

Нет

Да

Да

 

 

 

 

 

Действия

 

 

 

 

Действие 1

Do X

Do Y

Do X

Do Z

Действие 2

Do A

Do B

Do B

Do A

 

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


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

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

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

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

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

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

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

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

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

 

Правило 1

Правило 2

...

Правило N

Условия

 

 

 

 

Потратил

100

500

1000

5000

Выкуп

5%

30%

50%

80%

 

 

 

 

 

Плюшка

 

 

 

 

Скидка

0%

6%

10%

20%

Кол-во вещей

2

8

15

20

 

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

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

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

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

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

  • 500 — 5%

  • 1000 — 10%

  • 5000 — 20%

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

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


 

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

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

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

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

Тест-кейсы

Условие 1:

Потратил

Условие 2:

Выкуп

Результат

Кейс 1

100

5%

Do X / Do A

Кейс 2

500

30%

Do X / Do Y

Кейс 3

1000

50%

Do B / Do C

Кейс 4

5000

80%

Do B / Do Z

 

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

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

 

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

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

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

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

 

Итого

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

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

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

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

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

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

См также:

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

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

Визуализация ТЗ — диаграммы, схемы, картинки — про картинки

PowerPoint как инструмент тестировщика — да, так тоже можно было =)

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

Теги: требованиятесттест-дизайнdecision table
Хабы: Тестирование IT-систем Тестирование веб-сервисов Подготовка технической документации
Всего голосов 4: ↑3 и ↓1 +2
Комментарии 10
Комментарии Комментарии 10

Похожие публикации

Лучшие публикации за сутки