Техники тест-дизайна.

Тест дизайн — это этап процесса тестирования ПО, на котором проектируются и создаются тестовые случаи (тест кейсы) в соответствии с определёнными ранее критериями качества и целями тестирования.

Другими словами это методы, используемые для создания эффективных тест-кейсов. Основные техники включают эквивалентное разбиение (разделение входных данных на классы, которые обрабатываются одинаково), анализ граничных значений (проверка крайних значений входных данных), и попарное тестирование (тестирование комбинаций параметров по парам).

Другие техники включают метод основанный на сценариях использования, тестирование состояний и переходов (State Transition Testing) и таблицы решений. Эти техники помогают улучшить покрытие тестов и минимизировать количество тестов, не теряя их эффективности.

Цели тест-дизайна.

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

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

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

Правила работы:

Определение класса эквивалентности.
Минимум 1 тест для 1 класса.

Пример 1: Есть поле ввода с диапазоном допустимых значений от 1 до 100.

Сами понимаете, что на 95 тестов на допустимые значения и на несметное количество тестов на недопустимые значения уйдет очень много времени. И здесь нам помогут классы эквивалентности.

Исходя из того, с одной стороны, все допустимые значения могут влиять на поле ввода одинаково, следовательно все числа от 1 до 100 можно смело считать эквивалентными. С другой стороны, все недопустимые значения должны одинаково влиять на поле ввода (в идеале не должно быть возможности ввода этих значений в поле). Таким образом, есть уже несколько классов эквивалентности:

Допустимые значения (от 1 до 100). Недопустимые значения.

От — ∞ до 0.
От 101 до + ∞.
Специальные символы (# @ + — / _ : ; ” ’ и т.д.).
Буквы.

Используя классы эквивалентности можно протестировать поле ввода минимум из 5 тестов.

Пример 2: Есть поле ввода, принимающее на ввод число из 3 цифр. Формируем классы эквивалентности.

Например, число 111 представляет класс «трехзначные числа». Поданное на ввод, число 111 не вызывает ошибку в поле (тест пройден). Из этого делаем вывод, что все другие члены класса
«Трехзначные» также будут нормально приняты полем.

А теперь берем число 15 из класса «двузначные числа». Ожидается, что поле выдаст ошибку в ответ и это будет значить, что оно работает правильно, и предполагается, что остальные двузначные числа также будут вызывать ошибку.

Также берем число 5 из класса «однозначные числа». Ожидается, что поле выдаст ошибку в ответ и это будет значить, что оно работает правильно, и предполагается, что остальные однозначные числа также будут вызывать ошибку.

Анализ граничных значений.

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

Пример 1: Поле ввода пароля принимает значения минимум 6 до максимум 10 символов.

Это означает, что результаты для значений в разделах 0-5, 6-10, 11-14 должны быть эквивалентными.

№ сценария тестирования.
Описание.
Ожидаемый результат.

Введите от 0 до 5 символов.

Система не должна принимать.

Введите от 6 до 10 символов.

Система должна принять.

Введите от 11 до 14 символов.

Система не должна принимать.

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

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

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

Пример 2: Есть форма регистрации на сайте, и одно из полей — это возраст с допустимым диапазоном от 18 до 60 лет. Граничные значения будут: 17, 18, 19, 59, 60, 61. Здесь 17 и 61 — это значения за пределами границ, которые должны вызвать ошибку или предупреждение. Почему мы выбираем именно эти значения?

18 и 60: Это минимальное и максимальное допустимые значения. Тестируя их, можно удостовериться, что система корректно принимает граничные допустимые значения.

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

19 и 59: Они представляют собой внутренние граничные значения. Тестируя их, мы убеждаемся, что система корректно обрабатывает значения, которые находятся непосредственно внутри диапазона.

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

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

В числе возможных тестов:

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

Основные принципы техники предугадывания ошибки:

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

Пример: Возьмем один из элементов сайта — форму регистрации.

Можно использовать вот какие варианты:

Указать e-mail c несуществующим доменом на конце.
Указать e-mail без знака «@».
Заполнить поле «Пароль» без использования обязательных символов. Например, если программа требует, чтобы в пароле были заглавные и строчные буквы, то пробуем ввести пароль без использования заглавных букв.
В поле «Пароль еще раз» ввести символы отличные от символов в поле «Пароль».
Снять галочку «Я принимаю условия Пользовательского соглашения».
Ввести неверные символы с картинки.
Оставить одно поле незаполненным.

Исчерпывающее тестирование.

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

Матрица соответствия требованиям.

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

Таблица дает визуальное отображение двух параметров:

Наличие в системе требований, которые еще не покрыты (если у требования нет ни одного пересечения с тест-кейсами).
Есть ли в системе избыточное тестирование — если требования имеет несколько пересечений (необходимое условие).

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

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

Как это работает?

Причина: Это фактор, который может повлиять на результат. Например, это может быть действие пользователя или конкретный ввод данных.
Следствие: Это то, что происходит в результате действия причины — это ожидаемый результат.

Пример 1: Онлайн-магазин.

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

Причина: Пользователь хочет добавить товар в корзину.
Следствие: Товар появляется в корзине.

Теперь рассмотрим различные ситуации:

Ситуация 1: Пользователь нажимает кнопку «Добавить в корзину».
Следствие: Товар отображается в корзине. (Ожидаемый результат).
Ситуация 2: Товар недоступен для покупки (например, он распродан).
Следствие: Появляется сообщение об ошибке: «Товар недоступен». (Ожидаемый результат).
Ситуация 3: Пользователь не авторизован и пытается добавить товар в корзину.
Следствие: Появляется сообщение: «Пожалуйста, войдите в систему». (Ожидаемый результат).

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

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

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

Главные цели попарного тестирования:

Убрать избыточные проверки.
Обеспечить хорошее тестовое покрытие.
Выявить наибольшее количество багов на минимальном наборе тестов.

Принцип работы метода попарного тестирования:

Идентификация параметров: Определение параметров, которые могут влиять на функциональность продукта. Например, это могут быть параметры ввода, настройки или опции.
Определение значений параметров: Для каждого параметра определяются возможные значения. Например, параметр «Цвет» может иметь значения «Красный», «Синий», «Зеленый» и т.д.
Создание комбинаций: Для всех параметров создаются все возможные комбинации значений. Однако, вместо создания всех комбинаций, используется методика для минимизации числа тестовых случаев.
Создание тест-кейсов: Для каждой комбинации значений создаются отдельные тест-кейсы для тестирования.

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

Пример 1: у нас есть простое приложение, в которое ввод подается выбором значений из таких объектов ввода: выпадающего списка (с числами от 0 до 9), чекбокса, радиокнопки, текстового поля, и кнопки ОК. Текстовое поле принимает только числа от 0 до 100.

Получаются варианты следующие:

Список: 0,1,2,3,4,5,6,7,8,9.

Чекбокс: Отмечен / нет. Радиокнопка: Выбрана / не выбрана. Текстовое поле: числа 0…100.

Исчерпывающее тестирование такого приложения предполагает (умножаем все количества вариантов) 10*2*2*100 = 4000
тест-кейсов. Если же к этому добавить «негативные варианты» (то есть с вводом заведомо некорректных значений, а так обязательно случается в реальном мире), то количество будет
«сильно выше» 4000. Попарное тестирование:

Варианты радиокнопки и чекбокса сокращать нельзя, они всегда будут иметь только возможных 2 значения.
С текстовым полем можно ограничиться тремя числами: валидное целое, невалидное целое, буква или спецсимвол.
Со списком: здесь предположим, для упрощения, что значение будет или 0, или «любое другое кроме 0», то есть получается только 2 варианта, «0» и «другое».
Считаем количество вариантов (тест-кейсов) теперь: 2*2*2*3 = всего 24. То есть, при «обычном» подходе у нас 24 тест-кейса, что уже неплохо.

Идем дальше по пути попарного тестирования:

Упорядочиваем объекты ввода так, чтобы объект ввода с самым большим количеством вариантов шел первым, и т.п.
Делаем таблицу. Список у нас будет принимать 2 значения.
Следующая колонка — чекбокс, тоже 2 значения.
Проверяем, что у нас «покрыты» все комбинации списка и чекбокса.
То же делаем с радиокнопкой (2 значения).
Проверяем, что все пары «покрыты».
Текстовое поле
Выпадающий список
Чекбокс
Радиокнопка
Валидное целое
0
Отмечен
Включена
Валидное целое
«другое значение» (не 0)
Не отмечен
Выключена
Невалидное целое
0
Отмечен
Включена
Невалидное целое
«Другое значение»
Не отмечен
Выключена
Буква
0
Отмечен
Включена
Буква
«Другое значение»
Не отмечен
Выключена

Таким образом, пользуясь техникой попарного тестирования, сократили количество тест-кейсов сначала с 4000 до 24, затем до 6 как в таблице.

ADHOC тестирование.

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

Основные характеристики техники ADHOC тестирования:

Неформальность.

Тестирование проводится без заранее подготовленных планов или тест-кейсов. Тестировщик исследует приложение на основе своего интуитивного понимания и опыта.

Креативность.

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

Ориентированность на реальные сценарии.

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

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

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

Недостатки:

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

Примеры ADHOC тестирования:

Тестирование пользовательского интерфейса.

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

Тестирование случайных сценариев.

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

Тестирование сценариев использования.

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

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

Пользовательский сценарий.

Техника тест-дизайна «пользовательский сценарий» (User Scenario Testing) — это метод, при котором создаются тест-кейсы, описывающие типичные сценарии использования продукта реальными пользователями. Эта методика позволяет проверить, как продукт взаимодействует с пользователями в реальных условиях и как он соответствует их потребностям.

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

Идентификация пользовательских сценариев.

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

Создание тест-кейсов.

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

Проведение тестирования.

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

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

Пример: Регистрация нового пользователя.

Шаг 1: Открыть веб-приложение.

Открыть веб-браузер.

Ввести URL адрес веб-приложения. Нажать Enter.

Шаг 2: Перейти на страницу регистрации.

Найти и нажать на кнопку «Регистрация». Дождаться загрузки страницы.

Шаг 3: Ввести данные для регистрации.

Ввести уникальное имя пользователя в поле «Имя пользователя». Ввести пароль в поле «Пароль».

Повторно ввести пароль для подтверждения в поле «Повторить пароль».
Ввести адрес электронной почты в поле «Email». Нажать на кнопку «Зарегистрироваться».

Шаг 4: Проверить результат регистрации.

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

«Регистрация успешно завершена».

Проверить, что новый пользователь появился в списке зарегистрированных пользователей в базе данных.

Шаг 5: Выйти из приложения. Найти и нажать на кнопку «Выход».

Дождаться завершения выхода из приложения.

Состояние / переход.

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

Позитивные и негативные данные.

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

Позитивные тестовые данные.

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

Пример позитивных тестовых данных:

Положительное число.

Проверить, как приложение обрабатывает корректное положительное число.

Корректный адрес электронной почты.

Проверка, как приложение реагирует на правильно отформатированный адрес электронной почты.

Допустимая длина строки.

Проверка, как приложение обрабатывает строку с допустимой длиной.

Негативные тестовые данные.

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

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

Примеры негативных тестовых данных:

Отрицательное число.

Проверка, как приложение обрабатывает отрицательное число, если такая обработка не предполагается.

Некорректный адрес электронной почты.

Проверка, как приложение реагирует на адрес электронной почты с неправильным форматом.

Слишком длинная строка.

Проверка, как приложение обрабатывает строку с длиной, превышающей максимально допустимую.

Ввод специальных символов.

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

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

Комбинирование обоих видов тестовых данных обеспечивает более полное и надежное тестирование.

Метод шляпы / роли.

Техника тест-дизайна «Шляпы и Роли» (Hats and Roles Testing) — это метод, при котором тестировщики принимают разные «роли» или «шляпы» пользователей и, в соответствии с этими ролями, проводят тестирование, чтобы получить более разнообразные и объективные результаты. Этот метод позволяет исследовать продукт из разных точек зрения, что может помочь выявить разнообразные аспекты его работы.

Принципы работы метода «Шляпы и Роли»:

Определение ролей и шляп.

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

Создание тест-кейсов.

Для каждой роли создаются соответствующие тест-кейсы, которые акцентируются на тех аспектах продукта, которые наиболее важны для данной роли.

Проведение тестирования.

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

Пример техники «Шляпы и Роли»:

Предположим, что есть приложение для социальной сети. Нужно применить метод «Шляпы и Роли» для тестирования:

Роль: Обычный пользователь.

Тест-кейсы:

Проверка функционала добавления друзей.

Проверка возможности создания и публикации постов. Проверка функции лайков и комментариев к постам.

Роль: Администратор группы.

Тест-кейсы:

Проверка возможности создания группы.

Проверка функционала управления участниками группы. Проверка правил модерации контента.

Роль: Рекламодатель.

Тест-кейсы:

Проверка функции создания рекламных объявлений. Проверка опций таргетированной рекламы.

Проверка отчетности о показах и кликах.

Роль: Технический специалист.

Тест-кейсы:

Проверка безопасности приложения: SQL-инъекции, XSS и т.д.

Проверка производительности: время загрузки страниц, отклик интерфейса.

Роль: Мобильный пользователь.

Тест-кейсы:

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

Проверка функционала мобильных уведомлений.

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

В данной технике тест дизайна описываются подходы к составлению тест кейсов на некоторых «ролях» как пользователь, администратор, система и т. п. Описываются тестовые сценарии с точки зрения этих «ролей» и проводятся тестовые мероприятия.

Разговорчики-driven.

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

Analytics management.

Техника тест-дизайна «управление аналитикой» (Analytics management) — это метод, при котором создаются тест-кейсы, основанные на аналитических данных, как:

Наибольшее количество посещении той или иной страницы, если тестируется web-сайт.
Частое использование определенного функционала приложения.
Основные элементы взаимодействия пользователей.
Используются такие сервисы, как Google Analytics, Яндекс Метрика и т. п.

Bug-driven.

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

Принципы техники Bug-Driven Testing:

Идентификация багов.

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

Создание тестовых сценариев.

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

Разнообразие сценариев.

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

Тестирование граничных условий.

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

Итеративность.

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

Примеры:

Работа над мессенджером, и обнаружены следующие баги:

Баг.

При отправке сообщения с определенными специальными символами, приложение вылетает.

Тестовый сценарий.

Создать сообщение с этими символами и отправить. Проверить, не вылетает ли приложение.

Баг.

Сообщения иногда отправляются дважды, если отправить их в быстром режиме.

Тестовый сценарий.

Отправить несколько сообщений подряд с минимальным временным интервалом. Проверить, не отправляются ли они дважды.

Баг.

При долгом чате приложение начинает тормозить и медленно реагировать на ввод.

Тестовый сценарий.

Заполнить чат большим количеством сообщений. Взаимодействовать с интерфейсом и проверить, насколько медленно реагирует приложение.

Баг.

Не уведомляет о входящих сообщениях, если приложение было свернуто.

Тестовый сценарий.

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

Баг.

Иногда неверно отображается статус «онлайн» у контактов.

Тестовый сценарий.

Отследить различные случаи, когда статус «онлайн» должен измениться (появление, исчезновение активности) и проверить, корректно ли отображается.