Вступление
— "Как вы тестируете? Просто жмёте всё подряд?"
— "Нет. Я пользуюсь тест-дизайном — и поэтому багов нахожу больше, а времени трачу меньше."
Тест-дизайн — это искусство и наука превращать скучные чек-листы в умные сценарии, которые ловят неочевидные ошибки и не превращают тестирование в монотонную каторгу. Сегодня разберём техники, которые реально работают в бою, сэкономят время и покажут вашу экспертность даже самому вредному менеджеру.
1. Эквивалентное разбиение (Equivalence Partitioning)
Что это:
Вместо того, чтобы тестировать каждый возможный ввод, разбиваем значения на группы, где система ведёт себя одинаково (эквивалентные классы). Достаточно проверить по одному значению из каждой группы.
Пример:
Поле "Возраст" от 18 до 60:
- Класс 1: меньше 18 (некорректно)
- Класс 2: от 18 до 60 (корректно)
- Класс 3: больше 60 (некорректно)
Тестируем 17, 18, 60, 61 — и покрываем сразу всё.
Плюс: меньше тест-кейсов, больше реальной пользы.
2. Анализ граничных значений (Boundary Value Analysis)
Что это:
Баги часто прячутся "на границе". Проверяем значения на границе, рядом с ней и вне её.
Пример:
То же поле "Возраст":
- Минимум: 18
- Максимум: 60
Тестируем: 17, 18, 19, 59, 60, 61.
Лайфхак:
Используйте всегда вместе с эквивалентным разбиением — эффект усиливается!
3. Pairwise Testing (тестирование попарных комбинаций)
Что это:
Вместо того, чтобы проверять все возможные комбинации параметров (их может быть тысячи), достаточно проверить все возможные пары.
Пример:
У вас есть форма с 3 полями:
- Способ оплаты (карта/нал/крипта)
- Доставка (самовывоз/курьер)
- Промокод (есть/нет)
Всего комбинаций — 3×2×2=12, но если покрыть все пары (pairwise), тестов будет всего 6–8.
Смысл: баги почти всегда появляются на стыке двух параметров.
Инструменты:
- Pairwise Online
4. State Transition Testing (тестирование переходов состояний)
Что это:
Техника для систем с "режимами": переходы из одного состояния в другое.
Пример:
Банкомат:
- "Нет карты" → "Карта вставлена" → "Пин-код введён" → "Операция" → "Карта извлечена".
Проверяем не только обычный сценарий, но и неожиданные переходы: вставить карту — не вводить пин — извлечь карту и т.д.
Когда применять:
- Автоматизация сложных бизнес-процессов
- Мобильные приложения с несколькими экранами
5. Тестирование по таблицам принятия решений (Decision Table)
Что это:
Строим таблицу: входные условия — на пересечении ожидаемый результат.
Пример:
Доставка пиццы:
- Клиент дома? (да/нет)
- Пицца готова? (да/нет)
Таблица:
Клиент домаПицца готоваДействиеДаДаДоставитьДаНетЖдать приготовленияНетДаПозвонить клиентуНетНетОжидание
Проверяешь каждую строку — покрываешь все варианты.
6. "Exploratory testing" — тестирование по наитию
Что это:
Исследовательское тестирование — не по сценарию, а по собственному чутью и опыту.
Зачем:
Находит баги, которых нет в спецификации и которые “невозможно предсказать”.
Как делать:
- 20–30 минут свободного “исследования” фичи
- Всё найденное — сразу в баг-репорт/заметки
- Особенно круто работает для новых, сырых фич
Лайфхак:
Включайте exploratory-сессии в каждый спринт!
7. Классика: чек-листы, mind map, баг-туры
Чек-листы:
Кратко, по делу, без воды. Удобно для регресса, командной работы, для новичков.
Mind map:
Визуальная карта тестов: быстро видно, что уже покрыто, где есть “дыры”.
Баг-тур:
10-15 минут на "тур" по самому баговому месту приложения (например, профили, платежи, личный кабинет).
8. Практические советы, как экономить время и ловить баги чаще
- Не пытайся протестировать всё подряд — используй техники, чтобы выделить главное.
- Постоянно уточняй требования — “слепое” тестирование забирает время.
- Делай “черновики” тестов в mind map или на стикерах — экономит время на документацию.
- Используй автоматизированные генераторы pairwise-комбинаций.
- Планируй хотя бы один баг-тур на каждый релиз.
- Не бойся экспериментировать с разными техниками под разные задачи — не существует одной “волшебной палочки”.
9. Мифы о тест-дизайне
- Миф: техники — это сложно и для “гуру”.
Факт: простейшее эквивалентное разбиение можно внедрить за 5 минут, а пользу увидишь сразу. - Миф: тест-дизайн нужен только для автоматизации.
Факт: любой ручной тестер может резко повысить свою эффективность, используя правильные техники. - Миф: начальство не даст времени.
Факт: правильно выбранная техника экономит время — и твое, и команды.
10. Итоги
Хочешь ловить больше багов и тратить меньше времени на скучную рутину? Используй тест-дизайн!
Это не про “галочки для отчёта”, а про умный подход, который показывает твой профессионализм и делает работу QA интереснее.
А может, у тебя есть свои проверенные “фишки”? Давай делиться опытом!