[Тестирование IT-систем, Тестирование веб-сервисов, Подготовка технической документации] Decision Table — что это и как применять
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
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НетНетДаДа Действия Действие 1Do XDo YDo XDo ZДействие 2Do ADo BDo BDo A Именно для таких случаев и применяется техника — чтобы не запутаться в требованиях, аккуратно выписываем их в табличку.Пример 2. Интернет-магазин (множественный результат)Есть интернет-магазин, который предлагает:
- Скидку постоянного покупателя
- Количество вещей, которые курьер привезет бесплатно
Это такие плюшки за лояльность и повторную покупку. Как плюшки высчитываются? Есть два условия:
- Сколько клиент потратил (всего или за какой-то период времени) — бонус добавляется при достижении 100р, 500, 1000 и 5000
- Какой процент выкупа (а то, может, курьер зря мотается) — бонус получаем при достижении 5%, 30%, 50% и 80%
Если я потратила 100р и почти ничего не выкупила — скидки мне не дадут и вещей мало привезут. Если потратила больше и выкупила больше, то дадут небольшую скидочку. Ещё потрачу — станут вещей больше привозить... И так далее.Положим требования в таблицу: Правило 1Правило 2...Правило NУсловия Потратил10050010005000Выкуп5%30%50%80% Плюшка Скидка0%6%10%20%Кол-во вещей281520 Заметьте, что условия 2, и в каждом возможны 4 варианта — это 16 возможных пересечений, 16 тестов! Попробуем записать все условия:
Даже в виде таблицы уже сложновато читается... А в виде простого текста вообще ничего не разберешь!Конечно, интернет-магазин явно не будет мудрить, скорее всего они просто завяжут одну плюшку на одно условие:
- Потратил 100 р — 0% скидка
- 500 — 5%
- 1000 — 10%
- 5000 — 20%
А количество вещей будет зависеть от выкупа... Тогда и без таблички можно оставить в ТЗ, вполне понятный список! Но сложные взаимосвязи между разными условиями также встречаются. И если они у вас есть — составьте decision table хотя бы один раз. Чтобы разобраться во всех этих правилах, всё учесть и ничего не забыть! Плюсы подхода 1. Наглядность — таблица нагляднее текста. Можно взять таблицу и подойти к аналитику с каким-то вопросом. Или к разработчику. Им будет проще понять, о чём речь, чем если вы принесете стену текста.2. Нарисовал таблицу = записал тест-кейсы. Поменял в заголовках слово «правило» на «тест-кейс», и вот они, готовые тесты! И это будут основные позитивные тесты, которые мы проводим в первую очередь.
Если неудобно, что тест приходится читать сверху вниз, а не слева направо, таблицу можно инвертировать — перевернуть:Тест-кейсыУсловие 1:ПотратилУсловие 2:ВыкупРезультатКейс 11005%Do X / Do AКейс 250030%Do X / Do YКейс 3100050%Do B / Do CКейс 4500080%Do B / Do Z 3. Наглядность поможет найти баги в документации. Так как косяк формулы будет сразу бросаться в глаза.4. Таблица помогает взглянуть на ТЗ свежим взглядом, по-новому. Пока мы пытаемся перекомбинировать условия, составляя таблицу, мы можем заметить пропущенный ранее баг. Минусы подхода Особых минусов нет, но таблица не нужна, если:
- Слишком простое условие — потому что «но зачем?». И так все понятно.
- Слишком много входных данных — овер дофига будет колонок. Много тестов, но мало результата, потому что тут уже нужен тест-анализ, pairwise и т.д.
Итого Decision Table используется для описания сложных системных правил:
- Условия представляют собой входные данные.
- Действия – это ожидаемый результат.
- Колонки – тест-кейсы!
Я настоятельно рекомендую применять эту технику хотя бы однократно — к тем требованиям, которые вы уже знаете наизусть. Думаете, проверили все возможные комбинации? Нарисуйте таблицу решений и результат вас удивит!Отлично подходит для размыливания взгляда и действительно сложных ТЗ, когда таблица получается на 100 колонок. Поддерживать ее довольно накладно и вряд ли кто-то будет это делать, а вот одноразовая акция найдет баги!
См также:Как составлять вариант использования — ещё один вариант оформления требований.PS — больше полезных статей ищите в моем блоге по метке «полезное». А полезные видео — на моем youtube-канале
===========
Источник:
habr.com
===========
Похожие новости:
- [Программирование, Scala] Основы Cat Concurrency с Ref и Deferred (перевод)
- [Тестирование IT-систем, Анализ и проектирование систем, Отладка] Язык моделирования Alloy и приключения с параллельными запросами к базе данных (перевод)
- [Программирование, Разработка под iOS, Разработка под Android, Тестирование мобильных приложений] Автоматизация тестирования мобильных приложений. Часть 1: проверки, модули и базовые действия
- [Информационная безопасность, Тестирование веб-сервисов] Чек-лист устранения SQL-инъекций
- [Анализ и проектирование систем, Проектирование и рефакторинг, Подготовка технической документации] О роли системного аналитика и шаблон для проектирования
- [Тестирование IT-систем, Тестирование веб-сервисов] Экономика тестирования
- [Разработка игр, Тестирование игр] World of Tanks Blitz: Автоматизированное тестирование производительности
- [Python, Microsoft Azure, Тестирование веб-сервисов, Облачные сервисы] HTTP атака на Azure
- [Тестирование IT-систем, Тестирование веб-сервисов] Процесс автоматизированного тестирования за 10 шагов (перевод)
- [Тестирование IT-систем, Тестирование веб-сервисов, Учебный процесс в IT, Карьера в IT-индустрии] ISTQB. Как проходит сдача экзамена онлайн
Теги для поиска: #_testirovanie_itsistem (Тестирование IT-систем), #_testirovanie_vebservisov (Тестирование веб-сервисов), #_podgotovka_tehnicheskoj_dokumentatsii (Подготовка технической документации), #_trebovanija (требования), #_test (тест), #_testdizajn (тест-дизайн), #_decision_table, #_testirovanie_itsistem (
Тестирование IT-систем
), #_testirovanie_vebservisov (
Тестирование веб-сервисов
), #_podgotovka_tehnicheskoj_dokumentatsii (
Подготовка технической документации
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 14:37
Часовой пояс: UTC + 5
Автор | Сообщение |
---|---|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
Decision Table (таблица решений) — техника, помогающая наглядно изобразить комбинатору условий из ТЗ. Чем проще и понятнее требования, тем меньше будет разночтений. И тем меньше исправлений после реализации. И тем проще нам, тестировщикам, писать тест-кейсы по таким требованиям )) В тестировании таблица решений используется для того, чтобы на основе требований составить тест-кейсы. И ничего не забыть при сложных комбинациях входных условий! Ведь каждая строка или столбец таблицы → готовый тест-кейс.Decision Table относится к техникам тест-дизайна. Значит, про неё спрашивают на собеседованиях. И поэтому я сделаю небольшой цикл статей по таким техникам в помощь начинающим тестировщикам. Чтобы ознакомиться с каждой техникой:
Но для красивой картинки нужно уметь рисовать. А для составления таблички — нет! И в этом её удобство — можно не быть художником, но наглядно переписать ТЗ. Когда текста много, можно что-то пропустить. В виде таблицы намного понятнее, компактнее и мы сразу видим 4 теста, которые надо провести.У нас может быть не 2 условия, а 3 или больше. И действий тоже может быть больше одного. Получается больше правил и больше возможности их скомбинировать: Правило 1Правило 2...Правило NУсловия Условие 1НетНетДаДаУсловие 2ДаНетНетДаУсловие 3НетНетДаДа Действия Действие 1Do XDo YDo XDo ZДействие 2Do ADo BDo BDo A Именно для таких случаев и применяется техника — чтобы не запутаться в требованиях, аккуратно выписываем их в табличку.Пример 2. Интернет-магазин (множественный результат)Есть интернет-магазин, который предлагает:
Даже в виде таблицы уже сложновато читается... А в виде простого текста вообще ничего не разберешь!Конечно, интернет-магазин явно не будет мудрить, скорее всего они просто завяжут одну плюшку на одно условие:
Если неудобно, что тест приходится читать сверху вниз, а не слева направо, таблицу можно инвертировать — перевернуть:Тест-кейсыУсловие 1:ПотратилУсловие 2:ВыкупРезультатКейс 11005%Do X / Do AКейс 250030%Do X / Do YКейс 3100050%Do B / Do CКейс 4500080%Do B / Do Z 3. Наглядность поможет найти баги в документации. Так как косяк формулы будет сразу бросаться в глаза.4. Таблица помогает взглянуть на ТЗ свежим взглядом, по-новому. Пока мы пытаемся перекомбинировать условия, составляя таблицу, мы можем заметить пропущенный ранее баг. Минусы подхода Особых минусов нет, но таблица не нужна, если:
См также:Как составлять вариант использования — ещё один вариант оформления требований.PS — больше полезных статей ищите в моем блоге по метке «полезное». А полезные видео — на моем youtube-канале =========== Источник: habr.com =========== Похожие новости:
Тестирование IT-систем ), #_testirovanie_vebservisov ( Тестирование веб-сервисов ), #_podgotovka_tehnicheskoj_dokumentatsii ( Подготовка технической документации ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 14:37
Часовой пояс: UTC + 5