Что такое тест-дизайн. Обзор техник
Что такое тест-дизайн. Обзор техник
Введение
Представь, что ты тестируешь форму регистрации. Только в поле «возраст» можно ввести числа от 0 до 150, буквы, спецсимволы, пустую строку — сотни вариантов. А ещё есть имя, email, пароль, чекбоксы... Протестировать всё невозможно физически.
Тест-дизайн — это не про то, как написать тест, а про то, какие тесты написать.
Тест-дизайн — это процесс создания тестовых случаев (тест-кейсов), которые максимально покрывают требования при минимальной избыточности. Это инженерная дисциплина: ты выбираешь данные и сценарии не случайно, а по системе.
Зачем нужен тест-дизайн?
Без системного подхода тестировщики:
- Пропускают целые классы дефектов
- Дублируют проверки (тратят время впустую)
- Тратят больше времени на написание тестов, чем на их выполнение
Три главные цели тест-дизайна:
| Цель | Описание |
|---|---|
| Полнота | Покрыть все значимые сценарии и классы входных данных |
| Эффективность | Минимум тестов — максимум найденных дефектов |
| Воспроизводимость | Другой тестировщик сможет повторить те же шаги с теми же результатами |
Техники тест-дизайна: обзор модуля
В этом модуле мы разберём 6 ключевых техник:
1. Эквивалентное разделение (Equivalence Partitioning, EP)
Делим входные данные на группы (разделы), внутри каждой — поведение одинаково. Тестируем по одному значению из каждой группы.
2. Анализ граничных значений (Boundary Value Analysis, BVA)
Ошибки чаще всего прячутся на границах диапазонов. Тестируем граничные значения и значения рядом с ними.
3. Таблицы принятия решений (Decision Tables)
Когда несколько условий в комбинации дают разные результаты — строим таблицу всех комбинаций и проверяем каждую.
4. Диаграммы переходов состояний (State Transition Diagrams)
Система переходит из одного состояния в другое под воздействием событий. Тестируем все состояния, переходы и невалидные переходы.
5. Попарное тестирование (Pairwise Testing)
Когда параметров много, полный перебор нереален. Попарное тестирование гарантирует покрытие всех пар значений при минимальном числе тестов.
6. Тестирование на основе сценариев использования (Use Case / User Story Testing)
Тесты строятся на реальных пользовательских сценариях: счастливый путь, альтернативы, исключения.
Как техники дополняют друг друга
Техники не конкурируют — они закрывают разные типы рисков:
EP + BVA → числа, строки, даты (одиночные поля)
Decision Tables → комбинации нескольких условий
State Transition → системы с состояниями (заказ, пользователь, сессия)
Pairwise → конфигурации, формы с множеством параметров
Use Case → сквозные пользовательские сценарии
Опытный тестировщик выбирает технику под тип требования, а не применяет одну на всё подряд.
Частые ошибки
- Применять только одну технику ко всему подряд
- Смешивать техники без понимания, что каждая даёт
- Считать, что тест-дизайн — это «написать побольше тест-кейсов»
- Тестировать только «счастливый путь» и забывать об ошибочных сценариях
Что мы запомним
- Тест-дизайн — это выбор правильных тестов, а не написание всех возможных
- Цель: максимальное покрытие рисков при минимальном числе тест-кейсов
- В модуле 6 техник: EP, BVA, Decision Tables, State Transition, Pairwise, Use Case
- Техники дополняют друг друга и применяются в зависимости от типа требования