какими способами можно оптимизировать количество проверок при работе с таблицами принятия решений

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

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

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

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

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

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

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

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

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

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

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

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

Правило 1

Правило 2

Правило N

Условия

Действия

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

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

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

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

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

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

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

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

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

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

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

Источник

Какими способами можно оптимизировать количество проверок при работе с таблицами принятия решений

Техники тест-дизайна и их предназначение

При создании IT-продукта большую роль играет обеспечение качества – Quality Assurance (QA). Для того, чтобы устранить ошибки и «баги», QA-инженеры в числе прочих инструментов применяют техники тест-дизайна.

Тест-дизайн – это разработка, создание тестов. Каждый тест направлен на проверку конкретного предположения. Например: «Что будет, если пользователь по ошибке кликнет здесь не левой, а правой кнопкой мыши».

QA моделирует набор тестовых случаев (тест-кейсов), чтобы проверить, как приложение ведет себя в разных условиях. Задача специалиста – найти баланс и выявить максимальное количество ошибок при необходимом минимуме тестовых сценариев. При этом нужно проверить все наиболее важные кейсы, поскольку время тестирования ограничено.

Типы тестирования

Статическое тестирование, как следует из названия, не требует запускать программу или приложение и позволяет находить самые очевидные ошибки еще на ранних этапах создания продукта. Например, частью статического тестирования является проверка параметров ПО на соответствие требованиям технического задания, вычитка кода.

Динамическое тестирование требует проверять ПО в действии. Этот вид, в свою очередь, также делится на две обширные группы:

Техники белого ящика (они же структурное тестирование) применяют в том случае, если специалист хорошо знает архитектуру продукта, его код, «начинку» – то есть может ориентироваться в самой программе.

Техники черного ящика позволяют проверять работу продукта, не зная внутреннего устройства системы. При этом тестирование проводится на основе требований, указанных в спецификации проекта или в ТЗ.

Техники серого ящика позволяют тестировать продукт, когда специалист частично знает его внутреннее устройство. Для выполнения тестирования «серого ящика» не нужен доступ к исходному коду.

Этапы тестирования

1. Подготовка. На этом этапе QA-инженер читает проектную документацию, выясняет требования к продукту, прорабатывает план, продумывает стратегию, расставляет задачи по приоритетности и анализирует возможные риски.

2. Непосредственно тестирование. Предварительно специалисты анализируют собранную ранее информацию, составляют список тестируемых функций, знакомятся с уже известными багами, если они есть, пишут тест-кейсы.

Еще раз подчеркнем: принципиально важно стремиться к минимально возможному числу тестов, при этом необходимо, чтобы сценарии находили наибольшее число высокоприоритетных дефектов.

3. Анализ результатов и составление отчетов.

При работе над созданием тестов QA-специалист ориентируется не только на документацию, но и на устные сведения от других QA, аналитиков, разработчиков, менеджеров проекта.

Техники тест-дизайна на примерах

Рассмотрим несколько основных методик, однако, будем помнить, что зачастую их используют в комплексе. Одной техники может быть недостаточно, поскольку она не обеспечит максимальный охват тестовых сценариев.

Эквивалентное разбиение

Метод эквивалентного разбиения позволяет минимизировать число тестов, не создавая сценарий для каждого возможного значения, а выбрав только одно значение из целого класса и приняв за аксиому, что для всех значений в данной группе результат будет аналогичным.

Например, мы тестируем функциональность приложения, позволяющего покупать авиа- и железнодорожные билеты онлайн. Стоимость билета будет зависеть от возраста пассажира, так как дети, студенты и пенсионеры относятся ко льготным категориям.

У нас есть четыре возрастных группы: младше 15 лет, от 15 до 25 лет, старше 25 и младше 60 лет и люди старше 60. При этом, в поле для ввода возраста помещается всего два символа, поэтому указать возраст более 99 лет технически невозможно.

QA-специалисту не нужно писать 99 тестов для каждого возраста, хватит пяти: по одному для каждой возрастной группы (скажем, 10, 18, 35 и 75 лет) и один для случая, если возраст человека превышает 99 лет. Да, последний тест на практике невыполним (поскольку в поле возраста невозможно ввести более двух знаков), и все же не следует забывать об этой проверке.

Граничные значения

Техника граничных значений основана на предположении, что большинство ошибок может возникнуть на границах эквивалентных классов. Она тесно связана с вышеописанной техникой эквивалентного разбиения, из-за чего часто используется с ней в паре. Тогда для примера из предыдущего пункта границами будут являться значения 0, 15, 25, 60 и 99. Граничными значениями будут 0, 1, 14, 15, 16, 24, 25, 26, 59, 60, 61, 98, 99, 100.

Часто сложности возникают, если возрастные категории указаны «внахлест», например, 0-12, 12-25 лет и т.д.

Таблица принятия решений

Другое название метода – матрица принятия решений. Эта техника подходит для более сложных систем, например – двухфакторной аутентификации. Предположим, чтобы войти в систему, пользователю нужно ввести сначала логин и пароль, а затем еще подтвердить свою личность присланным в смс кодом.

Какие возможны сценарии:
1. Правильный логин и правильный пароль.
2. Правильный логин, неправильный пароль.
3. Неправильный логин, правильный пароль.
4. Неправильный логин, неправильный пароль.

Первый из этих сценариев сопровождается либо правильным, либо неправильным вводом смс-кода, итого у нас получается 5 тестов. При этом только один из сценариев приведет к положительному результату (пользователь успешно авторизуется), а остальные закончатся неудачей.

Этот метод хорош тем, что он показывает сразу все возможные сценарии в форме, понятной даже неспециалисту.

Пример таблицы принятия решений

Попарное тестирование

Суть этого метода, также известного как pairwise testing, в том, что каждое значение каждого проверяемого параметра должно быть протестировано на взаимодействие с каждым значением всех остальных параметров. После составления такой матрицы мы убираем тесты, которые дублируют друг друга, оставляя максимальное покрытие при минимальном необходимом наборе сценариев.

Попарное тестирование позволяет обнаружить максимум ошибок без избыточных проверок.

Pairwise testing: пример

Для Parwise достаточно, чтобы каждое значение всех параметров хотя бы единожды сочеталось с другими значениями остальных параметров. Таким образом, матрицу можно значительно сократить. Например:

При составлении матрицы принятия решений для двух браузеров, двух ОС и двух языков было бы нужно 8 сценариев. При попарном тестировании достаточно четырех.

Все это можно просчитать и вручную, но не обязательно – гораздо удобнее автоматизировать процесс. Для этого существует программа попарного независимого комбинированного тестирования – Pairwise Independent Combinatorial Testing (PICT). Для проведения тестирования специалист создает текстовый файл с перечислением и их возможных значений, а затем запускает PICT через cmd – командную строку. Скомбинированные тесты отображаются в виде таблицы в самой консоли. Так же результаты по желанию можно выгрузить в файл Excel.

Пример содержимого файла для программы PICT:

Браузер: Chrome, Opera
ОС: Windows, Linux
Язык: RU, ENG

Пример попарного тестирования

Причина и следствие

Простая проверка базовых действий и их результата. Например, если нажать крестик в правом верхнем углу окна (причина), оно закроется (следствие), и т.д. Этот метод позволяет проверить все возможности системы, а также обнаружить баги и улучшить техническую документацию продукта.

Примерный алгоритм использования техники:

1. Выделяем причины и следствия в спецификациях.
2. Связываем причины и следствия.
3. Учитываем «невозможные» сочетания причин и следствий.
4. Составляем «таблицу решений», где в каждом столбце указана комбинация входов и выходов, т.е. каждый столбец – это готовый тестовый сценарий.
5. Расставляем приоритеты.

Эта техника помогает:

Определить минимальное количество тестов для нахождения максимума ошибок.

Выяснить все причины и следствия – таким образом, мы убедимся, что на любые манипуляции с системой у системы будет ответ.

Найти возможные недочеты в логике описания приложения (что, в свою очередь, поможет улучшить документацию).

Например, QA-специалист тестирует приложение типа “записная книжка”. После ввода всех данных нового контакта и нажатия кнопки Создать (причина) приложение должно автоматически создать карточку с номером телефона, фотографией и ФИО человека (следствие). Тесты покажут, можно ли оставлять одно или несколько полей пустыми, распознает ли система кириллицу, латиницу или оба алфавита, а также другие параметры.

Предугадывание ошибок

Используя свои знания о системе, QA-специалист может «предугадать», при каких входных условиях есть риск ошибок. Для этого важно иметь опыт, хорошо знать продукт и уметь выстроить коммуникации с коллегами.

Например, в спецификации указано, что поле должно принимать код из четырех цифр. В числе возможных тестов:

1. Эта проверка эффективна в качестве дополнения к другим техникам.
2. Выявляет тестовые случаи, которые “никогда не должны случиться”.

Недостатки:
1. Техника в значительной степени основана на интуиции.
2. Необходим опыт в тестировании подобных систем.
3. Малое покрытие тестами.

Итоги

Разумеется, этот список далеко не полон и дает только самое общее представление о принципах тестирования и техниках тест-дизайна. Например, исчерпывающее тестирование, покрывающее все возможные сценарии и обнаруживающее все ошибки, существует только в теории. Это связано с тем, что проверка всех параметров и состояний займет слишком много времени. Однако, чем опытнее QA-специалист, тем лучших результатов он может добиться, и для этого важно уметь правильно подбирать и комбинировать техники.

Таблиці рішень та їх застосування в тестуванні

Таблиці рішень використовуються для дослідження взаємодії між комбінаціями умов. Вони надають чіткий метод перевірки всіх відповідних комбінацій, щоб гарантувати, що продукт обробляє всі можливі умови, взаємозв’язки і обмеження. Таблиці рішень є ефективним методом тестування програмного забезпечення, що використовується для аналізу реакції системи на різні вхідні дані.

Тестування за допомогою таблиць прийняття рішень – це одна з технік тест-дизайну методом чорного ящика, яка відноситься до динамічного аналізу. Вона також відома як таблиця причинно-наслідкових зв’язків. А схематична демонстрація логіки відома як причинно-наслідковий графік. Це візуальне уявлення використовується для отримання таблиці рішень.

Інші методи досліджень, наприклад, перевірка на еквівалентність або аналіз граничних значень, часто застосовуються тільки для конкретних вхідних даних. Техніка таблиці рішень використовується у тому випадку, коли для різних вихідних використовується комбінація вхідних даних. Основною метою є перевірка бізнес-логіки і тестового покриття.

Таблиця рішень, як правило, має 4 складові:

Приклад застосування таблиць рішень.

Умова дуже проста: якщо користувач вводить правильне ім’я користувача і пароль, він буде авторизований і перенаправлений на домашню сторінку. Якщо будь-які з даних, що вводяться є неправильними, то з’явиться повідомлення про помилку.

T – Правильне ім’я користувача/пароль.

F – Неправильне ім’я користувача/пароль

E – Відображається повідомлення про помилку.

H – Користувач авторизований/Відображається домашня сторінка.

Розглянемо окремо кожен із стовпчиків:

Стовпчик 1. Ім’я користувача і пароль були неправильні. Відображається повідомлення про помилку.

Стовпчик 2. Ім’я користувача було правильним, але пароль був неправильним. Відображається повідомлення про помилку.

Стовпчик 3. Неправильне ім’я користувача, але правильний пароль. Відображається повідомлення про помилку.

Стовпчик 4. Ім’я користувача і пароль були правильними, авторизація пройшла успішно, відображається домашня сторінка.

Для того щоб конвертувати це у тестовий приклад, можна створити декілька тест-кейсів.

Тест-кейс 1. Ввести валідні ім’я користувача та пароль, натиснути кнопку «Увійти».

Очікуваний результат : користувач авторизований і перенаправлений на домашню сторінку.

Тест-кейс 2. Ввести валідне ім’я користувача та невалідний пароль, натиснути на кнопку входу.

Очікуваний результат : відображається повідомлення про помилку.

Тест-кейс 3. Ввести невалідне ім’я та валідний пароль, натиснути кнопку «Увійти».

Очікуваний результат : відображається повідомлення про помилку.

Тест-кейс 4. Ввести невалідне ім’я користувача та пароль, натиснути на кнопку входу.

Очікуваний результат : відображається повідомлення про помилку.

Необхідно звернути увагу на той факт, що всі кейси, крім першого, перевіряють одне і те ж правило. Таким чином, була створена найпростіша таблиця рішень. За необхідності її можна розширити.

Ще один приклад застосування рішень на прикладі працездатності принтера

Умовні позначення: Y – так; N – ні.

Цей приклад показує простоту, з якою таблиця рішень демонструє можливі комбінації умов і дій. До того ж її легко модифікувати в разі зміни вихідних даних (наприклад, при включенні індикатора іншого кольору в принтері).

Переваги використання таблиці рішень під час тестування програмного забезпечення:

Недоліки таблиць рішень під час тестування програмного забезпечення.

Таблиці рішень є хорошим способом опису вимог, коли існує кілька бізнес-правил, що взаємодіють один з одним. Використовуючи цей метод, фахівцю стає простіше написати вимоги, які включають в себе всі доступні умови. Застосування цієї техніки допомагає краще проаналізувати тестований продукт, систематизувати всі знання по ньому. В результаті стає легше писати повні тестові приклади, охопити всі можливі комбінації.

Тестирование таблицы решений

Таблица принятия решений используется для тестирования с различными комбинациями входных данных, которые приводят к различным выходным данным в программе. Тестирование таблицы решений также называется тестированием причинно-следственных связей. Это очень систематический подход к тестированию, где мы фиксируем входные комбинации и их результаты в табличном формате. Эти таблицы достаточно точны и компактны для моделирования сложной логики.

Почему таблицы решений так важны?

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

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

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

Как создать таблицу решений для тестирования?

Теперь, когда вы знакомы с тем, что такое тестирование решений, давайте создадим таблицу решений.

Шаг 1: Создание первого столбца таблицы с учетом требований.

Мы создадим первый столбец таблицы, взглянув на то, что нам нужно проверить. Для этого примера рассмотрим пример транзакции ATM. Ниже будут его условия и действия:

Шаг 2: Добавление дополнительных столбцов.

Теперь, когда первый столбец готов, мы рассчитаем оставшееся количество необходимых столбцов. Это будет зависеть от количества условий на руке, а также от того, сколько альтернатив доступно для этих условий.

Для простоты тестирования мы должны создать меньшие таблицы решений, а затем создать огромные. Закончив с количеством столбцов, мы можем заполнить True или False. Вы можете заполнить ячейки следующим образом:

После этого наша таблица выглядит следующим образом:

Шаг 3: сделать стол меньше.

Мы также должны пометить ячейки с незначительными значениями как «-». Например, не имеет значения, предоставляется ли кредит, если сумма

Источник

Как использовать таблицы принятия решений в тестировании

Сегодня познакомлю вас с таблицами решений – что это и как эффективно использовать в тестировании. Таблицы решений зарекомендовали себя как удобный и простой способ тест-дизайна.

Для начала выясним, что же такое “Таблица решений”. Для этого обратимся к любимой Википедии за формальным определением: таблица принятия решений – это способ компактного представления модели со сложной логикой. Простыми словами, это варианты действий при различных входных условиях.

Давайте представим обычную ситуацию возвращения домой с работы или учебы. У нас есть ключ от домофона. Мы можем либо взять его с собой, либо забыть (дома \ на работе \ где-то еще). В момент возвращения домой нас могут ждать родственники \ друзья \ собака, которая умеет открывать дверь, либо дома никого нет – все ушли гулять.

Итак, какие входные параметры мы имеем?

Какие наши возможные действия?

Можно придумать что-то из мира фантастики, например, взобраться на 20 этаж и проникнуть в квартиру через окно. Пока остановимся на перечисленных выше вариантах действия.

Все необходимые данные у нас есть, теперь нужно собрать все в красивую табличку. Слева в столбец перечисляем входные параметры или “условия”.

Далее создаем столбцы справа, где каждый столбец будет определять один из возможных вариантов этих условий.

“Да” означает, что условие выполняется, “Нет” – не выполняется. Прочерк – неважно выполняется ли это условие (например, если у нас есть ключ, нам все равно на месте ли консьерж, мы открываем дверь сами).

Для каждого варианта выполнения нужно определить ожидаемое действие. Смотрим на вариант 1: если ключ с собой, мы открываем дверь ключом. Напротив соответствующего действия ставим символ “Х”, который показывает, что должно выполняться именно это действие.

Основой метода построения таблицы решения является таблица из четырех блоков:Если внимательно посмотреть на таблицу, можно заметить, что каждый столбец представляет собой отдельный тест-кейс! Вуаля 🙂

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

Мы знаем, что форма содержит поля логина, пароля и кнопки “Войти” и “Отмена”.

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

Выберем “Условия” для данных сущностей, т.е. возможные входные значения.

Пустое значение выбрано как отдельное условие из-за того, что ошибка в этом случае отличается от ошибки ввода неверного значения. Кнопки объединили в одно условие, т.к. мы можем нажать или одну или другую кнопку, одновременно нажать две – проблематично 🙂

Выделим возможные действия:

После того, как выбрали условия и варианты действия начинается самое интересное – составить таблицу решений!

Выписываем в столбец все условия и варианты:

Считаем, что в случае неверного значения для логина и пустого значения пароля – система выдает нам обе ошибки. Как должна вести себя ваша программа – смотрите в требованиях и спецификациях 🙂

Теперь для всех 18 вариантов определим необходимость действий.

В итоге для проверки всех возможных вариантов действий с формой авторизации нам потребуется 18 тест-кейсов. Они по факту уже готовы и записаны в таблице.

Вы можете детальнее расписать ввод неверного значения, например, отдельно ввод цифр, символов, непечатных символов, копипаст в поле, максимальное и минимальное значение, ограничение по длине, формат поля email и т.д.

Здесь мы рассмотрели только функцию авторизации – либо она происходит, либо нет. Отдельную таблицу можно составить для всех возможных ошибок, связанных с данными, которые вводим в поля формы авторизации.

Для удобства выполнения таких тест-кейсов рекомендую добавить еще одну строку к таблице “Статус прохождения теста” и в ходе тестирования отмечать тесты как Passes / Failed / Blocked / Not Run.

Источник