Decision Table (таблица решений) — техника, помогающая наглядно изобразить комбинаторику условий из ТЗ.
Чем проще и понятнее требования, тем меньше будет разночтений. И тем меньше исправлений после реализации. И тем проще нам, тестировщикам, писать тест-кейсы по таким требованиям ))
В тестировании таблица решений используется для того, чтобы на основе требований составить тест-кейсы. И ничего не забыть при сложных комбинациях входных условий! Ведь каждая строка или столбец таблицы → готовый тест-кейс.
Decision Table относится к техникам тест-дизайна. Значит, про неё спрашивают на собеседованиях. И поэтому я сделаю небольшой цикл статей по таким техникам в помощь начинающим тестировщикам. Чтобы ознакомиться с каждой техникой:
Decision Table (таблицы решений) — текущая статья
Сегодня говорим про 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 колонок. Поддерживать ее довольно накладно и вряд ли кто-то будет это делать, а вот одноразовая акция найдет баги!
См также (напоминаю ссылочки):
Как составлять вариант использования — ещё один вариант оформления требований.
State & Transition Diagramm (схема состояний и переходов) — и ещё ))
Визуализация ТЗ — диаграммы, схемы, картинки — про картинки
PowerPoint как инструмент тестировщика — да, так тоже можно было =)
PS — это выдержка из моей книги для начинающих тестировщиков, написана в помощь студентам моей школы для тестировщиков
Комментариев нет:
Отправить комментарий