Меню

Основные этапы составления таблицы принятия решений

Основные этапы составления таблицы принятия решений

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

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

В таблицах решений представлен набор условий, одновременное выполнение которых должно привести к определённому действию.

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

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

Таблица принятия решений, как правило, разделяется на 4 квадранта:

Условия Варианты выполнения действий
Действия Необходимость действий

Условия — список возможных условий.

Варианты выполнения действий — комбинация из выполнения и/или невыполнения условий этого списка.

Действия — список возможных действий.

Необходимость действий — указание надо или не надо выполнять соответствующее действие для каждой из комбинаций условий.

Рассмотрим таблицу принятия решений на примере страницы регистрации нового пользователя сервиса KUKU.io

Используем понятия “корректные” и “некорректные” данные.

Чтобы регистрация прошла успешно, необходимо заполнить корректными оба поля. Если поля заполняются некорректными данными, то система должна выдать ошибку: “Введены невалидные данные”.

Условие Значения 1 Значения 2 Значения 3 Значения 4
Ввод корректных данных в поле E-mail + +
Ввод корректных данных в поле Password + +
Ввод некорректных данных в поле E-mail + +
Ввод некорректных данных в поле Password + +
Действия
Регистрация прошла успешно +
Выдается ошибка: “Введены невалидные данные” + + +

Значения 2, 3, 4 приводят к одному и тому же результату с разными входными значениями.

Источник



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

Что такое тестирование таблицы решений?

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

Таблица решений — это табличное представление входных данных в сравнении с правилами / случаями / условиями испытаний. Давайте учиться на примере.

Пример 1. Как составить таблицу базовых решений для экрана входа в систему

Давайте создадим таблицу решений для экрана входа в систему.

Условие простое, если пользователь вводит правильное имя пользователя и пароль, он будет перенаправлен на домашнюю страницу. Если какой-либо из вводимых данных неправильный, появится сообщение об ошибке.

условия Правило 1 Правило 2 Правило 3 Правило 4
Имя пользователя (T / F) F T F T
Пароль (T / F) F F T T
Выход (E / H) Е Е Е ЧАС
  • T — правильное имя пользователя / пароль
  • F — Неверное имя пользователя / пароль
  • E — Сообщение об ошибке отображается
  • H — отображается главный экран
  • Случай 1 — имя пользователя и пароль были неверны. Пользователю показывается сообщение об ошибке.
  • Случай 2 — Имя пользователя было правильным, но пароль был неправильным. Пользователю показывается сообщение об ошибке.
  • Случай 3 — Имя пользователя было неверным, но пароль был правильным. Пользователю показывается сообщение об ошибке.
  • Случай 4 — имя пользователя и пароль были правильными, и пользователь перешел на домашнюю страницу

Преобразуя это в тестовый пример, мы можем создать 2 сценария,

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

И один из сценария ниже

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

По сути, они проверяют одно и то же правило.

Пример 2: Как создать таблицу решений для экрана загрузки

Теперь рассмотрим диалоговое окно, которое попросит пользователя загрузить фотографию с определенными условиями, такими как —

  1. Вы можете загрузить только изображение в формате .jpg
  2. размер файла менее 32 КБ
  3. разрешение 137 * 177.

Если какое-либо из условий не выполняется, система выдаст соответствующее сообщение об ошибке с указанием проблемы, и если все условия будут выполнены, фотография будет успешно обновлена.

Давайте создадим таблицу решений для этого случая.

условия Дело 1 Дело 2 Дело 3 Дело 4 Дело 5 Дело 6 Дело 7 Дело 8
Формат .jpg .jpg .jpg .jpg Не .jpg Не .jpg Не .jpg Не .jpg
Размер Менее 32кб Менее 32кб > = 32 КБ > = 32 КБ Менее 32кб Менее 32кб > = 32 КБ > = 32 КБ
разрешающая способность 137 * 177 Не 137 * 177 137 * 177 Не 137 * 177 137 * 177 Не 137 * 177 137 * 177 Не 137 * 177
Вывод Фотография загружена Несоответствие разрешения сообщения об ошибке Несоответствие размера сообщения об ошибке Размер сообщения об ошибке и несоответствие разрешения Сообщение об ошибке несоответствия формата Формат сообщения об ошибке и несоответствие разрешения Сообщение об ошибке несоответствия формата и размера Сообщение об ошибке несоответствия формата, размера и разрешения
Читайте также:  Повреждена основная таблица с файлами

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

  1. Загрузите фотографию в формате «.jpg», размером менее 32 КБ и разрешением 137 * 177 и нажмите «Загрузить». Ожидаемый результат: фотография должна быть успешно загружена
  2. Загрузите фотографию в формате «.jpg», размером менее 32 КБ и разрешением не 137 * 177 и нажмите «Загрузить». Ожидаемый результат: должно отображаться несоответствие разрешения сообщения об ошибке.
  3. Загрузите фотографию в формате «.jpg», размером более 32 КБ и разрешением 137 * 177 и нажмите «Загрузить». Ожидаемый результат: должно отображаться несоответствие размера сообщения об ошибке.
  4. Загрузите фотографию в формате «.jpg», размером более 32 кБ и разрешением не 137 * 177, и нажмите «Загрузить». Ожидаемый результат: должен отображаться размер сообщения об ошибке и несоответствие разрешения.
  5. Загрузите фотографию в формате, отличном от «.jpg», размером менее 32 КБ и разрешением 137 * 177 и нажмите «Загрузить». Ожидаемый результат: сообщение об ошибке для несоответствия формата должно отображаться
  6. Загрузите фотографию в формате, отличном от «.jpg», размером менее 32 КБ и разрешением не 137 * 177 и нажмите «Загрузить». Ожидаемый результат: формат сообщения об ошибке и разрешение несоответствия должны отображаться
  7. Загрузите фотографию в формате, отличном от «.jpg», размером более 32 КБ и разрешением 137 * 177 и нажмите «Загрузить». Ожидаемый результат: сообщение об ошибке для формата и несоответствия размера должно отображаться
  8. Загрузите фотографию с форматом, отличным от «.jpg», размером более 32 КБ и разрешением не 137 * 177 и нажмите «Загрузить». Ожидаемый результат: сообщение об ошибке для формата, размера и несоответствия разрешения должно отображаться

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

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

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

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

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

Значение этого метода сразу становится понятным по мере увеличения количества входов. Количество возможных комбинаций задается как 2 ^ n, где n — количество входов. Для n = 10, который очень распространен в веб-тестировании, имеющем большие формы ввода, количество комбинаций будет 1024. Очевидно, что вы не можете протестировать все, но вы выберете богатое подмножество возможных комбинаций, используя решение на основе методика тестирования.

Преимущества тестирования таблицы решений

  • Когда поведение системы отличается для разных входных данных и не одинаково для диапазона входных данных, как эквивалентное разбиение, так и анализ граничных значений не помогут, но можно использовать таблицу решений.
  • Представление простое, так что его можно легко интерпретировать и использовать как для развития, так и для бизнеса.
  • Эта таблица поможет составить эффективные комбинации и может обеспечить лучшее покрытие для тестирования
  • Любые сложные бизнес-условия можно легко превратить в таблицы решений
  • В случае, если мы собираемся на 100% охват, как правило, когда входные комбинации низкие, этот метод может обеспечить покрытие.

Недостатки тестирования таблицы решений

Основным недостатком является то, что с увеличением количества входных данных таблица станет более сложной.

Источник

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

При создании 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 тестов. При этом только один из сценариев приведет к положительному результату (пользователь успешно авторизуется), а остальные закончатся неудачей.

Однако, может быть так, что система выдает разные сообщения в зависимости от того, на каком этапе была допущена ошибка, скажем: invalid login, invalid password. Соответственно, групп потребуется больше, а таблица станет обширнее.

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

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

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

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

Дизайн без названия.png

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

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

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

  • Что произойдет, если не ввести код?
  • Что произойдет, если не ввести спецсимволы?
  • Что произойдет, если ввести не цифры, а другие символы?
  • Что произойдет, если ввести не четыре цифры, а другое количество?

Преимущества:

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

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

Итоги

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

Источник

QA evolution

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

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

В таблицах решений представлен набор условий, одновременное выполнение которых должно привести к определённому действию.

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

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

Таблица принятия решений, как правило, разделяется на 4 квадранта:

Условия Варианты выполнения действий
Действия Необходимость действий

Условия — список возможных условий.

Варианты выполнения действий — комбинация из выполнения и/или невыполнения условий этого списка.

Действия — список возможных действий.

Необходимость действий — указание надо или не надо выполнять соответствующее действие для каждой из комбинаций условий.

Рассмотрим таблицу принятия решений на примере страницы регистрации нового пользователя сервиса KUKU.io

Используем понятия “корректные” и “некорректные” данные.

Чтобы регистрация прошла успешно, необходимо заполнить корректными оба поля. Если поля заполняются некорректными данными, то система должна выдать ошибку: “Введены невалидные данные”.

Условие Значения 1 Значения 2 Значения 3 Значения 4
Ввод корректных данных в поле E-mail + +
Ввод корректных данных в поле Password + +
Ввод некорректных данных в поле E-mail + +
Ввод некорректных данных в поле Password + +
Действия
Регистрация прошла успешно +
Выдается ошибка: “Введены невалидные данные” + + +

Значения 2, 3, 4 приводят к одному и тому же результату с разными входными значениями.

Источник

Adblock
detector