Контекст

Представьте обычное поле «Количество товара» в корзине интернет-магазина, принимающее значения от 1 до 99. Формально в него можно ввести бесконечное число вариантов: любые числа, буквы, спецсимволы, эмодзи, пустую строку, пробелы, строку из миллиона знаков. Проверить всё физически невозможно — и это лишь одно поле, а в реальной форме их десятки, и они взаимодействуют между собой. Тест-дизайн — это дисциплина осознанного выбора: какие именно проверки дадут максимум информации о качестве при минимуме затрат. Один из семи принципов тестирования по ISTQB прямо гласит: исчерпывающее тестирование невозможно, поэтому вместо перебора всех вариантов используется анализ рисков и техники проектирования тестов. Без техник тестировщик выбирает проверки интуитивно и неравномерно: одни зоны проверяет по пять раз, другие не трогает вообще. С техниками выбор становится воспроизводимым и аргументированным — вы можете объяснить коллеге и менеджеру, почему тестов именно столько и почему этого достаточно.

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

Рабочий алгоритм

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

Техники чёрного ящика (по спецификации): классы эквивалентности, граничные значения, таблицы решений, pairwise, переходы состояний, use case. Основа — требования и наблюдаемое поведение, код не нужен.
Техники белого ящика (по структуре): покрытие операторов и ветвлений кода. Применяются в основном разработчиками и в автотестах уровня unit.
Техники на основе опыта: error guessing, исследовательское тестирование, чек-листы. Дополняют формальные техники там, где спецификация молчит.
Практическое правило: начинайте с техник чёрного ящика по требованиям, а опытные техники используйте как второй слой для поиска того, что формальный анализ пропустил.

Пример из практики

Команда e-commerce проекта получила задачу проверить форму оформления заказа: адрес, телефон, комментарий, выбор доставки и промокод. Джуниор-тестировщик без техник написал 60 тестов за два дня: он перебирал случайные значения телефона («а вдруг с плюсом не сработает», «а вдруг со скобками»), но полностью пропустил взаимодействие промокода с типом доставки. На проде выяснилось, что промокод на бесплатную доставку применялся к самовывозу и уводил сумму заказа в минус. Затем задачу передали тестировщику, который начал с анализа: телефон — классы эквивалентности и границы длины; промокод и доставка — таблица решений, потому что это комбинация условий; статусы заказа — переходы состояний. Получилось 34 теста вместо 60, время проектирования — полдня, и именно тест из таблицы решений «промокод бесплатной доставки + самовывоз» поймал бы дефект до релиза. Мораль: техника — это не бюрократия, а способ направить внимание туда, где дефекты действительно живут.

Частые ошибки

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

Подменять анализ количеством: 100 хаотичных тестов хуже 30 спроектированных — избыточные проверки съедают время регресса, а дыры в покрытии остаются.
Выбирать одну любимую технику на все случаи: классы эквивалентности не помогут с зависимостями условий — там нужна таблица решений.
Игнорировать невалидные сценарии: по статистике именно обработка ошибок — самая дефектная зона, а тестируют её реже всего.
Не фиксировать логику выбора тестов: через месяц никто, включая автора, не сможет сказать, что покрыто, а что нет.

✅ Самопроверка

1Почему исчерпывающее тестирование невозможно даже для одного текстового поля?

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

2Чем техники чёрного ящика отличаются от техник на основе опыта?

Техники чёрного ящика систематически выводят тесты из спецификации и модели поведения, а опытные техники (error guessing, exploratory) опираются на интуицию и знание типовых дефектов; они дополняют, а не заменяют друг друга.

3Почему 100 хаотичных тестов могут быть хуже 30 спроектированных?

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

4Какую группу техник стоит применить первой при тестировании новой фичи по готовым требованиям и почему?

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