Техники тест-дизайна: что это такое и какие бывают

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

При этом бизнесу важны сроки и быстрые релизы. Возникает конфликт между качеством и скоростью.

На практике ищут компромисс: проверяют не всё подряд, а сценарии с высоким риском — где ошибка наиболее вероятна или может привести к серьёзным последствиям.

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

Содержание

• Что такое тест-дизайн
• Что такое техники тест-дизайна
• Эквивалентное разделение
• Анализ граничных значений
• Таблица принятия решений
• Граф состояний и переходов
• Причинно-следственный анализ
• Тестирование на основе опыта
• Какую технику тест-дизайна выбрать

Что такое тест-дизайн

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

На практике тест-дизайн включает пять этапов:

• Идентификация тестовых условий. Тестировщик определяет параметры, которые влияют на результат. Например, при расчёте страхового полиса важно учесть возраст туриста и длительность поездки. Это ключевые параметры, которые должны быть проверены.
• Выбор техники тест-дизайна. В зависимости от характера тестовых условий специалист подбирает подходящий метод. Например, если тестовые данные распределены по группам, то можно выбрать метод эквивалентного разделения.
• Определение конкретных значений для проверки. На основе выбранной техники тестировщик формирует входные данные для проверок.
• Проектирование тест-кейса. Специалист подготавливает подробную инструкцию для проверки работы программы в целом или отдельной функциональности на основе первых трёх шагов.
• Группировка тест-кейсов. Готовые тест-кейсы объединяют в логические блоки — например, «Проверки оплаты», «Проверки скидок» и другие. Это повышает удобство работы.

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

Что такое техники тест-дизайна

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

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

Читайте также:

Что такое QA-тестирование и как оно устроено

Разберём семь наиболее распространённых техник тест-дизайна. Все примеры покажем на условной платформе туристического страхования SafeJourney: этот сервис помогает туристам оформлять страховой полис, учитывая даты поездки, возраст и дополнительные опции — например, тип отдыха.

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

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

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

В страховой системе SafeJourney возраст туриста влияет на тариф. Выделяют несколько категорий: до 18 лет — детский тариф, от 18 до 60 — стандартный, от 61 до 80 — тариф с повышенным риском, старше 80 — отказ в страховании.

Проверять каждый возраст от 0 до 100 не нужно. Достаточно взять по одному значению из каждого класса: например, 9, 39, 70 и 90 лет. Это позволит проверить правильность определения тарифа для всех четырёх групп.

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

На практике дефекты часто возникают на границах диапазонов — из-за неточностей в условиях. Например, в страховой системе SafeJourney указано, что оформление профиля недоступно с 80 лет, но неясно: входит возраст 80 в ограничение или нет.

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

Чтобы проверить корректность выбора тарифа страхования, нужно протестировать граничные значения каждого диапазона. Для этого в тесты включают значения на стыках тарифов: 17 и 18, 60 и 61, 80 и 81.

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

Читайте также:

Use case: что это, как его составить и какие инструменты пригодятся

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

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

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

В SafeJourney есть несколько правил:

• невозможно получить страховой полис, если турист старше 60 лет и выбирает тип активности «Экстрим»;
• скидка 10% применяется к поездкам продолжительностью более 30 дней и без типа активности «Экстрим».

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

• возраст — до или после 60 лет;
• тип активности — «Экстрим» или нет;
• длительность поездки — до или более 30 дней.

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

Граф состояний и переходов

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

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

В SafeJourney полис проходит несколько статусов:

• при создании — «Черновик»;
• после нажатия «Оформить» — «Ожидает оплаты»;
• после успешной оплаты — «Активен»;
• при отмене — «Отменён».

По этому графу тестировщик проверяет корректность переходов. Например, он должен убедиться, что система выдаёт ошибку, если попытаться перевести полис из «Черновика» сразу в «Активен», минуя этап «Ожидает оплаты» с успешной оплатой.

Причинно-следственный анализ

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

Тестировщики оформляют причинно-следственный анализ в формате «если X, то Y».

Рассмотрим варианты описания техники на примере SafeJourney:

• если пользователь оставил поле Email пустым и нажимает на кнопку «Продолжить», то кнопка блокируется и под полем ввода электронной почты появляется сообщение «Введите почту»;
• если пользователю более 60 лет и он выбирает тариф «Экстрим», то получает отказ системы в выдаче полиса.

Покажем оба сценария в виде блок-схем.

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

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

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

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

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

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

В результате тестировщик покрывает тестами ключевые взаимодействия параметров и снижает объём проверок без значимой потери качества.

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

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

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

Какую технику тест-дизайна выбрать

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

Ниже — шпаргалка, которая поможет выбрать подходящую технику.