Decision Table (таблица решений) техника, помогающая наглядно изобразить комбинатору условий из ТЗ.
Чем проще и понятнее требования, тем меньше будет разночтений. И тем меньше исправлений после реализации. И тем проще нам, тестировщикам, писать тест-кейсы по таким требованиям ))
В тестировании таблица решений используется для того, чтобы на основе требований составить тест-кейсы. И ничего не забыть при сложных комбинациях входных условий! Ведь каждая строка или столбец таблицы готовый тест-кейс.
Decision Table относится к техникам тест-дизайна. Значит, про неё спрашивают на собеседованиях. И поэтому я сделаю небольшой цикл статей по таким техникам в помощь начинающим тестировщикам. Чтобы ознакомиться с каждой техникой:
-
Decision Table (таблицы решений) текущая статья
-
State & Transition Diagramm (схема состояний и переходов) TBD
-
Другие диаграммы, схемы, картинки (бонус такой к техникам) TBD
Сегодня говорим про Decision Table (таблица решений):
Помимо статьи есть видео о таблице решений с моего канала. Кому что удобнее! :)
Как составлять таблицу
-
По горизонтали выписываем условия, которые влияют на результат. А чуть ниже сам результат, в оригинале Action действие, которое нужно выполнить.
-
По вертикали правила:конкретная комбинация входных условий.
То есть мы указываем значения условий и результата
Правило 1 |
Правило 2 |
... |
Правило N |
|
Условия |
||||
Условие 1 |
||||
Условие 1 |
||||
... |
||||
Условие N |
||||
Действия |
||||
Действие 1 |
||||
Действие 2 |
||||
... |
||||
Действие N |
Давайте посмотрим на простом примере когда у нас один результат (action).
Пример 1. Страховка на автомобиль (один результат)
Я прихожу в страховую компанию и заполняю анкету, где есть 2 вопроса:
-
Есть ли 5 лет стажа вождения?
-
Была ли в авариях?
Ответить можно либо да, либо нет.
Получается 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 колонок. Поддерживать ее довольно накладно и вряд ли кто-то будет это делать, а вот одноразовая акция найдет баги!
См также:
Как составлять вариант использования ещё один вариант оформления требований.
PS больше полезных статей ищите в моем блоге по метке полезное. А полезные видео на моем youtube-канале