Техники тест-дизайна: как создавать эффективные тест-кейсы

Протестировать абсолютно всё не получится. Представим: форма с пятью полями, в каждом можно ввести тысячи значений. Перебирать все комбинации – это годы работы. А релиз нужен через неделю. Ну и как быть?

Ответ – техники тест-дизайна в тестировании ПО.

Мы в KOTELOV применяем их везде: от небольших стартапов до систем, где миллион пользователей одновременно. Эти методы реально сокращают количество тестов, причём качество не страдает. В статье разберём основные техники с примерами, которые пригодятся и для подготовки к ISTQB, и в ежедневной работе.

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

Если коротко – это систематические способы создания тест-кейсов. Просто звучит? На практике меняет вообще всё.

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

По классификации ISTQB техники делятся на три группы:

Здесь сосредоточимся на чёрном ящике. Именно эти техники применяются чаще всего.

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

Идея элементарная. Если система обрабатывает кучу значений одинаково – зачем проверять их все? Достаточно одного.

Допустим, поле «Возраст» принимает значения от 18 до 65. Что происходит с числами внутри диапазона? Система их принимает все одинаково. Нет никакого смысла проверять 18, потом 19, потом 20, и так до 65. Берём любое значение – скажем, 30 – и идём дальше.

Так формируются классы эквивалентности:

Три теста вместо сотни. Работает? Ещё как.

Как применять:

Сначала определяем входные данные. Потом разбиваем их на классы – валидные и невалидные. Выбираем по одному представителю от каждого. Создаём тест-кейсы и готово.

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

Где чаще всего ломается код? На границах. Это статистика, не теория.

Разработчик пишет условие if (age >= 18 && age <= 65). Легко поставить > вместо >=. Легко перепутать 64 и 65. Такие баги – абсолютная классика.

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

Для поля «Возраст от 18 до 65»:

Шесть значений вместо бесконечности. И именно они находят больше всего багов.

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

Таблица решений в тест-дизайне

Когда в системе много условий и комбинаций, текстовые описания превращаются в кашу. «Если клиент VIP и сумма больше 10000, то скидка. А если не VIP, но сумма больше 50000, тоже скидка. А если VIP, но сумма меньше…» Запутаться – раз плюнуть.

Таблица решений делает логику видимой.

Вот пример для интернет-магазина:

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

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

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

Заказ в интернет-магазине не может перескочить из «Новый» сразу в «Доставлен». Почему? Есть последовательность: оформлен, оплачен, собран, отправлен, доставлен. Это конечный автомат.

Техника State Transition проверяет три вещи. Все разрешённые переходы работают. Запрещённые переходы невозможны – попробуй хоть сто раз. Система правильно реагирует на события в каждом состоянии.

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

Где это нужно? Workflow-системы, многошаговые формы, любые процессы со статусами. По сути — почти везде.

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

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

Тестируем браузерную совместимость. Три браузера, три операционки, три разрешения экрана. Полный перебор даёт 27 комбинаций. Попарное тестирование сокращает до 9-12. При этом все пары значений будут проверены – ни одна не пропущена.

Составлять такие наборы вручную? Муторно. Есть инструменты: PICT от Microsoft бесплатный и мощный, AllPairs, Hexawise.

Когда попарное тестирование реально спасает:

Примеры тест-кейсов с применением техник

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

Поля: Email, Пароль, Возраст.

Эквивалентное разбиение для Email – какие классы? Валидный: user@example.com. Невалидный без @: userexample.com. Невалидный без домена: user@. И пустое значение. Четыре класса – четыре теста.

Граничные значения для Возраста (18-65): 17 даёт ошибку, 18 – успех, 65– успех, 66 – ошибка.

Шаблон тест-кейса выглядит так:

Результат? Ноль случайных проверок. Каждый тест обоснован.

Техники тест-дизайна для ISTQB

Готовитесь к сертификации? На Foundation Level спрашивают всё из этой статьи. И не только определения – надо уметь применять.

Что ещё проверяют на экзамене?

Если не уверены в своих силах – попробуйте применить техники к любой форме на любом сайте. Официальный Syllabus даёт теорию, а экзамен требует навыка. Это лучшая тренировка из возможных.

Мы в KOTELOV не просто тестируем – мы выстраиваем процессы, которые работают долго. На 86% меньше обращений в техподдержку после нашей работы – это реальная цифра. S7, Т-Банк, Газпромбанк уже обращались за тестированием.

Если интересует UX-аудит как часть комплексной проверки продукта – есть отдельная услуга юзабилити-анализа.

Что в итоге

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

Лучший эффект? Комбинирование. Для одного поля – эквивалентное разбиение плюс граничные значения. Для бизнес-правил – таблица решений. Для workflow – тестирование состояний.