Тест-дизайн — это не просто теория с курсов, а реальный инструмент, который помогает тестировщику работать эффективно. Особенно это важно для новичков: вы не проверяете "всё подряд", а умеете выбирать сценарии, в которых баги появляются чаще всего.
В этой статье разберёмся:
- Что такое тест-дизайн
- Зачем он нужен
- Какие бывают техники тест-дизайна
- Как их применять на практике
Что такое тест-дизайн?
Тест-дизайн — это процесс создания тестовых сценариев (тест-кейсов, чек-листов и прочих артефактов), основанный на анализе требований, бизнес-логики и возможных вариантов использования системы.
Проще говоря — это способ придумать, что и как тестировать, чтобы найти максимум багов с минимальными усилиями.
Зачем тест-дизайн вообще нужен?
Тест-дизайн позволяет:
- 📌 Экономить ресурсы: вы не проверяете всё подряд, а выбираете наиболее вероятные места возникновения ошибок
- 📌 Повышать покрытие: за меньшее количество тестов проверяете больше логики
- 📌 Систематизировать тестирование: легче понять, что уже покрыто, а что — нет
- 📌 Сделать тестирование обоснованным: не «на глазок», а по технике
Это особенно важно для ручного тестировщика, где время — ресурс ограниченный.
Основные техники тест-дизайна (с примерами)
Разберём несколько базовых техник, которые должен знать каждый QA, даже если он только начал путь.
1. Эквивалентное разбиение (Equivalence Partitioning)
Суть: берём все возможные значения входных данных и делим их на логические группы — так называемые эквивалентные классы, где система ведёт себя одинаково. В каждом классе достаточно протестировать одно значение — оно будет представлять всю группу. Это помогает не тратить время на повторяющиеся кейсы и охватить максимум логики с минимумом тестов.
Пример:
Проверка поля ввода возраста, допустимые значения: от 18 до 65.
- Группа 1: < 18 (недопустимые)
- Группа 2: от 18 до 65 (допустимые)
- Группа 3: > 65 (недопустимые)
Выбираем по одному значению:
- 16 (отклонить)
- 30 (принять)
- 70 (отклонить)
Плюс: меньше тестов, больше смысла.
2. Граничные значения (Boundary Value Analysis)
Суть: баги — как непрошенные гости: чаще всего они появляются там, где система на пределе возможностей. Поэтому тестируем всё по краям, как будто ищем дырки в заборе — именно на границах значений чаще всего всё и ломается.
Пример: всё тот же возраст 18–65:
- Грани:
- 17 (на один меньше)
- 18 (нижняя граница)
- 65 (верхняя граница)
- 66 (на один больше)
Итог:
- 17 — ошибка
- 18 — ок
- 65 — ок
- 66 — ошибка
Это помогает поймать баги, которые не вылезают в середине диапазона.
3. Попарное тестирование (Pairwise / All-Pairs)
Суть: когда у нас несколько параметров (например, тип клиента, способ доставки, метод оплаты), не надо сходить с ума и перебирать все возможные комбинации (их может быть тысячи). Вместо этого мы берём только те пары значений, которые взаимодействуют между собой, и проверяем их. Это как в жизни: чтобы понять, сработается ли команда, не нужно устраивать корпоратив на тысячу человек — достаточно свести по двое и посмотреть, не подерутся ли. Такой подход экономит время и покрывает основные варианты взаимодействия.
Пример: форма заказа:
- Метод оплаты: карта, PayPal, наличные
- Способ доставки: курьер, самовывоз
- Тип клиента: новый, постоянный
Комбинаций: 3 × 2 × 2 = 12
Вместо 12 тестов можно протестировать 6–7, если грамотно составить попарные комбинации:
- карта + курьер + новый
- карта + самовывоз + постоянный
- PayPal + курьер + постоянный
- PayPal + самовывоз + новый
- наличные + курьер + постоянный
- наличные + самовывоз + новый
Пары покрыты, время сэкономлено.
Инструменты: для генерации попарных комбинаций можно использовать онлайн-сервисы вроде pairwise.teremokgames.com. Просто вбиваешь параметры — и получаешь готовый список пар для тестирования. Удобно, быстро, почти как магия, но без Хогвартса.
4. Диаграммы переходов состояний (State Transition Testing)
Суть: если система ведёт себя по-разному в зависимости от того, что происходило раньше (например, сначала авторизовался, потом вышел, потом снова зашёл), нужно рисовать состояния (экраны, статусы, роли и т.п.) и переходы между ними. Это помогает не пропустить важные ветки поведения: куда пользователь может попасть, а куда — нет, что должно происходить при ошибках, таймаутах, повторных действиях и т.д.
Пример: пользователь в приложении
- Состояния: неавторизован, авторизован, заблокирован
- Действия: логин, logout, неправильный пароль 3 раза
Диаграмма:
- Неавторизован → логин → Авторизован
- Авторизован → logout → Неавторизован
- Неавторизован → 3 ошибки → Заблокирован
Тесты составляются по всем возможным переходам, в том числе негативным.
5. Таблицы принятия решений (Decision Table Testing)
Суть: когда есть много условий и правил, удобно оформить их в виде таблицы: если то — то.
Пример: скидки в интернет-магазине. Каждую строку — в отдельный тест-кейс.
Как выбрать технику?
Всё зависит от:
- Типа системы: формы (ввод, валидация), потоковые сценарии (регистрация → заказ → оплата), API-запросы (GET, POST, ошибки), мобильные приложения, веб-интерфейсы — везде свои нюансы и свои предпочтительные техники тест-дизайна.
- Требований: если документация чёткая и подробная — легче применить технику, которая работает по формальным правилам (например, таблицы решений). Если требований мало или они расплывчатые — на помощь приходят эвристики и негативные кейсы.
- Ресурсов: если времени мало — подойдут техники, которые дают максимум покрытия с минимумом кейсов (эквивалентное разбиение, граничные значения, попарное тестирование). Если команда большая и можно покрыть больше сценариев — в бой идут таблицы решений и переходы состояний. и времени
Быстрые советы:
- Поля с вводом чисел → граничные значения + эквивалентное разбиение
- Много параметров → попарное тестирование
- Статусы и переходы → диаграммы состояний
- Много правил и условий → таблица решений
Как внедрять тест-дизайн в учебных проектах
Начни с малого:
- Протестируй форму регистрации на демо-сайте
- Сначала сделай чек-лист «на глаз», потом — по техникам
- Сравни: где ты что-то упустил без структурного подхода
Сервисы для практики:
- testpages.herokuapp.com — ещё одна отличная площадка для тренировки. Здесь есть десятки демонстрационных страниц: формы, таймеры, таблицы, алерты, загрузки файлов и другие элементы. Этот сайт особенно полезен для практики граничных значений, таблиц решений и негативных кейсов.
- демо-магазины (демо-версии интернет-магазинов) — такие сайты, как litecart.net/demo имитируют реальную работу онлайн-магазина. Ты можешь добавлять товары в корзину, оформлять заказы, регистрироваться и тестировать весь пользовательский путь. Отличная площадка для проверки форм, бизнес-логики, валидации, расчётов и сценариев с переходами между состояниями (гость → пользователь → заказ оформлен и т.п.)
Ошибки новичков в тест-дизайне
❌ Придумывают 50 кейсов на один сценарий, не разделяя по техникам
✅ Лучше 5 осмысленных тестов по технике, чем 50 бессмысленных копий ради самоуспокоения. Если ты написал 30 кейсов для формы логина, и все они — про "ввести правильный логин и пароль" с разными заглавными буквами, остановись и подумай: ты тестируешь или просто играешь в Word? Подход с техниками — это как тренажёр для мозга: меньше повторений, больше смысла.
❌ Тестируют только «нормальное» поведение
✅ А теперь представь юзера, который решил ввести в поле номера телефона стих Пушкина, а после отключил Wi-Fi и нажал «Отправить». Вот такие сценарии тоже нужно тестить. Негативные кейсы (невалидный ввод, отмена действий, обрыв сети и прочие приколы) — это золото для тестировщика.
❌ Игнорируют зависимость между шагами
✅ Если система ведёт себя по-разному в зависимости от того, что происходило до этого — добро пожаловать в мир переходов состояний. Например: нажал «Выйти» — и всё, ты уже не авторизован. Нельзя просто взять и протестировать экран «Профиль», не зайдя в систему. Если система меняет состояние — рисуй переходы и тестируй каждый путь, как будто это лабиринт с ловушками.
Что в итоге
Тест-дизайн — это суперсила любого QA. Он превращает хаос «что бы потестить» в осознанную стратегию:
- Помогает не тратить время впустую
- Учит думать системно
- Даёт уверенность в своих тестах
Даже если ты только учишься — начинай применять техники. Сначала будет сложно, но с практикой ты начнёшь видеть сценарии «через рентген» и писать тест-кейсы, которые реально ловят баги.