Привет, Хабр! Я 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):
Значение | Тип | Ожидание |
|---|---|---|
17 | Граница− | Ошибка |
18 | Граница | ОК |
19 | Граница+ | ОК |
64 | Граница− | ОК |
65 | Граница | ОК |
66 | Граница+ | Ошибка |
6 тестов покрывают обе границы. На практике BVA почти всегда идёт в паре с Equivalence Partitioning.
3. Decision Table — таблица решений
Суть: когда результат зависит от комбинации условий, рисуем таблицу.
Задача с собеседования:
Скидка в интернет-магазине: 10% если клиент премиум ИЛИ сумма > 5000₽. 20% если оба условия выполнены. 0% если ни одно.
Премиум? | Сумма > 5000? | Скидка |
|---|---|---|
Нет | Нет | 0% |
Да | Нет | 10% |
Нет | Да | 10% |
Да | Да | 20% |
4 комбинации = 4 теста. Всё покрыто, ничего не забыто.
Decision Table особенно полезна, когда бизнес-логика описана словами типа «если... и... то...». Переводим прозу в таблицу — и баги сами вылезают.
4. State Transition — диаграмма состояний
Суть: если объект меняет состояния, рисуем граф переходов и тестируем каждый переход.
Пример — статус заказа:
[Новый] → Оплачен → В доставке → Доставлен ↘ Отменён ↘ Отменён
Тест-кейсы по переходам:
Новый → Оплачен (оплата прошла)
Оплачен → В доставке (передан курьеру)
В доставке → Доставлен (клиент получил)
Новый → Отменён (отмена до оплаты)
Оплачен → Отменён (отмена после оплаты, нужен возврат)
Ключевой вопрос на собеседовании: «А какие переходы невозможны?»
Например: Доставлен → Новый — нельзя. Если система это позволяет — это баг. Негативные переходы часто ловят серьёзные дефекты.
5. Pairwise Testing — попарное тестирование
Суть: когда параметров много, полный перебор невозможен. Pairwise гарантирует, что каждая пара значений встретится хотя бы раз.
Задача:
Форма с 3 полями: Браузер (Chrome, Firefox, Safari), ОС (Windows, macOS, Linux), Язык (EN, RU).
Полный перебор: 3 × 3 × 2 = 18 комбинаций.
Pairwise: 9 комбинаций покрывают все пары.
# | Браузер | ОС | Язык |
|---|---|---|---|
1 | Chrome | Windows | EN |
2 | Chrome | macOS | RU |
3 | Chrome | Linux | EN |
4 | Firefox | Windows | RU |
5 | Firefox | macOS | EN |
6 | Firefox | Linux | RU |
7 | Safari | macOS | RU |
Проверяем: 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 на собеседованиях.
