Привет, Хабр! Я QA-инженер с 5+ годами опыта. За последний год прошёл около 15 собеседований в крупные продуктовые компании. Заметил закономерность: кандидаты отлично пишут автотесты, но сыпятся на тест-дизайне. Хочу разобрать пять техник, которые спрашивают чаще всего, — с реальными примерами задач.

1. Equivalence Partitioning — разбиение на классы эквивалентности

Суть: делим входные данные на группы (классы), в которых поведение системы одинаково. Из каждого класса берём одно значение — этого достаточно.

Задача с собеседования:

Поле «Возраст» принимает значения от 18 до 65. Сколько тестов минимально нужно?

Классы:

• < 18 — невалидный (например, 15)

• 18–65 — валидный (например, 30)

• > 65 — невалидный (например, 70)

Ответ: 3 теста. Один из каждого класса.

Типичная ошибка: кандидат начинает перечислять 18, 19, 20... Это перебор, а не тест-дизайн.

2. Boundary Value Analysis — анализ граничных значений

Суть: баги любят границы. Тестируем значения на границе и рядом с ней.

Для того же поля «Возраст» (18–65):

6 тестов покрывают обе границы. На практике BVA почти всегда идёт в паре с Equivalence Partitioning.

3. Decision Table — таблица решений

Суть: когда результат зависит от комбинации условий, рисуем таблицу.

Задача с собеседования:

Скидка в интернет-магазине: 10% если клиент премиум ИЛИ сумма > 5000₽. 20% если оба условия выполнены. 0% если ни одно.

4 комбинации = 4 теста. Всё покрыто, ничего не забыто.

Decision Table особенно полезна, когда бизнес-логика описана словами типа «если... и... то...». Переводим прозу в таблицу — и баги сами вылезают.

4. State Transition — диаграмма состояний

Суть: если объект меняет состояния, рисуем граф переходов и тестируем каждый переход.

Пример — статус заказа:

[Новый] → Оплачен → В доставке → Доставлен ↘ Отменён ↘ Отменён

Тест-кейсы по переходам:

1. Новый → Оплачен (оплата прошла)

2. Оплачен → В доставке (передан курьеру)

3. В доставке → Доставлен (клиент получил)

4. Новый → Отменён (отмена до оплаты)

5. Оплачен → Отменён (отмена после оплаты, нужен возврат)

Ключевой вопрос на собеседовании: «А какие переходы невозможны?»

Например: Доставлен → Новый — нельзя. Если система это позволяет — это баг. Негативные переходы часто ловят серьёзные дефекты.

5. Pairwise Testing — попарное тестирование

Суть: когда параметров много, полный перебор невозможен. Pairwise гарантирует, что каждая пара значений встретится хотя бы раз.

Задача:

Форма с 3 полями: Браузер (Chrome, Firefox, Safari), ОС (Windows, macOS, Linux), Язык (EN, RU).

Полный перебор: 3 × 3 × 2 = 18 комбинаций.
Pairwise: 9 комбинаций покрывают все пары.

Проверяем: Chrome+Windows — есть ✓, Firefox+RU — есть ✓, Linux+EN — есть ✓. Каждая пара покрыта.

На практике для генерации используют инструменты: PICT (Microsoft), AllPairs, или онлайн-сервисы.

Как это выглядит на реальном собеседовании

Обычно дают задачу вида: «Протестируйте [фичу]». Правильный подход:

1. Уточнить требования — не стесняйтесь задавать вопросы. Это часть оценки.

2. Выбрать технику:

• Одно поле с диапазоном → BVA + Equivalence Partitioning

• Бизнес-логика с условиями → Decision Table

• Объект с жизненным циклом → State Transition

• Много параметров → Pairwise

3. Нарисовать — таблицу, граф или список прямо при интервьюере. Это показывает системное мышление.

4. Не забыть негативные сценарии — что будет если ввести пустую строку? Отрицательное число? SQL-инъекцию?

Частая ошибка

Кандидат говорит: «Я знаю boundary values и equivalence classes». Интервьюер спрашивает: «Окей, примените к этой задаче». И человек теряется, потому что заучил определения, но не практиковался.

Теория без практики на собеседовании не работает. Берите любую форму (регистрация, поиск, оформление заказа) и прогоняйте через все пять техник. После 5–6 таких упражнений это входит в привычку.

Если тема интересна — могу написать продолжение про тестирование API и security testing на собеседованиях.