11 вопросов по теме «QA: Тест-дизайн» на собеседовании

Короткий ответ: Классы эквивалентности (equivalence partitioning) — это разбиение области входных данных на группы, внутри которых система ведёт себя одинаково, поэтому достаточно проверить одного представителя от каждого класса. Для возраста 18–65 берём один валидный класс и три-четыре невалидных.

Подробно:

1. Идея — если 20 и 40 обрабатываются одним и тем же кодом, то тест с одним из них покрывает весь класс; перебирать все значения бессмысленно.
2. Валидный класс — 18–65 (представитель, например, 30).
3. Невалидные классы — обязательно несколько: слишком мало, слишком много, не число, пустое поле.
4. Экономия — вместо перебора 48 валидных значений (и бесконечного числа невалидных) — 5 осмысленных тестов.

⚠️ Частая ошибка: назвать только валидный класс и забыть про невалидные — а именно на них интервьюер и ждёт, что вы вспомните про "abc", пустое поле и границы.

Короткий ответ: Анализ граничных значений (boundary value analysis, BVA) — это проверка значений на краях классов эквивалентности и вокруг них, потому что дефекты кластеризуются именно на границах. BVA — прямое продолжение классов эквивалентности: сначала делим домен на классы, потом целимся в их края.

Подробно:

1. Почему края — типичные баги живут в условиях >= vs >, off-by-one, неверная граница диапазона.
2. Правило трёх точек — для каждой границы берём значение до неё, на ней и сразу после.
3. Для 18–65 — нижняя граница: 17 / 18 / 19; верхняя: 64 / 65 / 66.
4. Связь с EP — классы говорят какие группы проверять, BVA говорит где внутри группы искать ошибку.

     невалидно │ валидно 18..65 │ невалидно
   ────────────┼────────────────┼────────────
            17 │ 18          65 │ 66
           ↑нет│ ↑да      ↑да   │ ↑нет

⚠️ Частая ошибка: проверить только одну сторону границы (только 18, но не 17) или только валидную сторону — тогда off-by-one на верхней границе спокойно уедет в прод.

Короткий ответ: Pairwise (попарное) тестирование — это техника, где вместо полного перебора комбинаций параметров покрываются все пары значений. Она решает комбинаторный взрыв: полная матрица параметров растёт мультипликативно, а большинство багов вызывается взаимодействием не более двух параметров.

Подробно:

1. Проблема — 3 браузера × 3 ОС × 3 локали = 27 комбинаций; четвёртый параметр — уже 81, пятый — 243.
2. Гипотеза — эмпирически большинство дефектов зависит от одного параметра или пары, а не от тройного стечения.
3. Решение — набор тестов, где каждая пара значений (например, Chrome+Windows, Chrome+macOS) встречается хотя бы раз.
4. Результат — с 27 комбинаций сжимаемся до ~9 при сохранении покрытия всех пар (генерируется инструментами вроде PICT/Allpairs).

⚠️ Частая ошибка: не суметь назвать trade-off. Pairwise экономит усилия, но не ловит баги, требующие совпадения трёх и более параметров — про это нужно честно сказать интервьюеру.

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

Подробно:

1. Признак применимости — в требованиях появляются «если… И… ИЛИ…» с несколькими флагами (лояльность, сумма, промокод).
2. Структура — строки условий сверху, строки действий снизу; каждый столбец — одно правило.
3. Полнота — N булевых условий дают 2^N комбинаций (здесь 2³ = 8); «не важно» (—) схлопывает их в меньшее число правил.
4. Ценность — визуально видно, какая комбинация в требованиях не описана.

⚠️ Частая ошибка: проверять условия по отдельности вместо их комбинаций — именно на стыке правил («Gold + промокод») чаще всего и живёт баг. Типичный вопрос банковских и e-com раундов.

Короткий ответ: Тестирование переходов состояний (state transition testing) применяют к системам, где объект проходит через набор статусов, а поведение зависит от текущего состояния. Мы проверяем валидные переходы, запрещённые переходы и краевые (начальное/терминальное) состояния.

Подробно:

1. Модель — заказ живёт по цепочке: New → Paid → Shipped → Delivered.
2. Валидные переходы — каждый разрешённый шаг должен работать (Paid → Shipped).
3. Запрещённые переходы — система обязана отклонять невозможное (Delivered → New, повторная оплата Paid → Paid).
4. Краевые состояния — что происходит в начальном (New без оплаты) и терминальном (Delivered — дальше некуда).

  New ──pay──► Paid ──ship──► Shipped ──deliver──► Delivered
   │                                                   │
   └── cancel ──► Cancelled            (Delivered ─X─► New) запрещён

⚠️ Частая ошибка: проверить только «зелёный» путь по статусам и не протестировать запрещённые переходы — а именно возможность нелегально откатить статус (отгрузить уже доставленный заказ) чаще всего и оказывается дырой.

Короткий ответ: Полноценный тест-кейс с предусловиями, шагами и ожидаемым результатом нужен там, где важна воспроизводимость и трассируемость: аудит, комплаенс, сложные многошаговые флоу. Лёгкий чек-лист достаточен для регрессии по стабильным фичам и exploratory-сессий, где важнее скорость.

Подробно:

1. Тест-кейс — формальный документ, любой может повторить шаг в шаг; дорого писать и поддерживать.
2. Чек-лист — список того, что проверить, без детальных шагов; быстро составить, гибко использовать.
3. Критерий выбора — цена поддержки против требований к строгости и аудируемости.

⚠️ Частая ошибка: тянуть тяжёлые формальные тест-кейсы туда, где хватает списка проверок, и утонуть в поддержке документации вместо реального тестирования. Интервьюер хочет услышать обоснование выбора при нехватке времени.

Короткий ответ: Тест-стратегия — это высокоуровневый, переиспользуемый подход к тестированию уровня организации или продукта (какие виды тестирования, инструменты, стандарты). Тест-план — это конкретный документ под проект или релиз: scope, сроки, ресурсы, риски, критерии выхода.

Подробно:

1. Уровень — стратегия задаёт принципы «как мы вообще тестируем», план приземляет их на конкретный релиз.
2. Срок жизни — стратегия стабильна и меняется редко; план живёт от релиза к релизу.
3. Содержимое — стратегия: подходы, типы тестов, среды, стандарты; план: что, кто, когда, чем, критерии готовности.

⚠️ Частая ошибка: употреблять эти термины как взаимозаменяемые. Если на собеседовании назвать план стратегией, интервьюер сразу считывает поверхностное знание процесса.

Короткий ответ: Использую risk-based подход: сначала критичные бизнес-пути и деньги, потом самые частые сценарии, потом недавно изменённый и исторически багованный код. Цель — за оставшееся время закрыть максимум риска, а не «протестировать всё».

Подробно (порядок приоритета):

1. Критичные бизнес-пути — то, без чего продукт не приносит денег: логин, оформление заказа, оплата.
2. Часто используемые фичи — где большинство пользователей, там дороже баг.
3. Регуляторные и платёжные флоу — цена ошибки не только в деньгах, но и в штрафах.
4. Недавно изменённый код — свежие правки = свежие дефекты; смотрю диф релиза.
5. Исторически проблемные зоны — модули с прошлыми инцидентами по багтрекеру.
6. Всё остальное — если останется время; иначе осознанный риск.

риск = вероятность дефекта × ущерб
сортируем тесты по убыванию риска ─► идём сверху вниз, пока не кончится день

⚠️ Частая ошибка: ответить «протестирую всё важное» без фреймворка. Интервьюер ждёт именно критерий приоритизации (риск = вероятность × ущерб) и осознанное решение, что НЕ тестируем.

Короткий ответ: Автоматизировать стоит стабильные, повторяемые и критичные проверки с высоким ROI — регрессию, smoke, API. Ручными оставить то, что автоматизировать дорого или бессмысленно: быстро меняющийся UI, разовые exploratory-проверки, оценку визуальных нюансов и юзабилити.

Подробно:

1. Кандидаты на автоматизацию — прогоняются часто, стабильный интерфейс, детерминированный результат, дорогой ручной прогон.
2. Оставить руками — новый или нестабильный UI (автотест сломается раньше, чем окупится), exploratory, визуал и UX.
3. Критерий — ROI: экономия от повторных прогонов минус стоимость написания и поддержки теста.

⚠️ Частая ошибка: ответить «автоматизируем всё» без оценки стоимости поддержки. Автотест по нестабильному UI ломается каждый спринт и съедает больше времени, чем экономит — это отрицательный ROI.

Короткий ответ: Позитивные тесты проверяют, что система работает на валидных данных (happy path). Негативные проверяют, что система корректно обрабатывает невалидный ввод — не падает, не пропускает мусор, а показывает внятную ошибку.

Подробно:

1. Позитивные — валидный ввод даёт ожидаемый результат: user@mail.com принимается.
2. Негативные — невалидный ввод отклоняется с понятной ошибкой, а не 500-й: пустое, без @, инъекция.
3. Баланс — негативных сценариев обычно больше, чем позитивных: невалидных состояний всегда больше, чем валидных.

⚠️ Частая ошибка: покрыть только happy path и отчитаться «работает». Реальные баги и уязвимости живут в негативных сценариях — пустой ввод, спецсимволы, инъекции.

Короткий ответ: Use case описывает, как актор достигает цели во взаимодействии с системой: основной поток плюс альтернативные и исключительные. Тест-кейс — это конкретная проверка с шагами и ожидаемым результатом. Из одного use case выводится множество тест-кейсов.

Подробно:

1. Use case — уровень требований: актор, предусловия, основной поток, альтернативы, исключения. Отвечает «что должна уметь система».
2. Тест-кейс — уровень проверки: конкретные данные, шаги, ожидаемый результат. Отвечает «как убедиться, что работает».
3. Связь — один use case «Оплатить заказ» порождает тест-кейсы: успешная оплата, недостаточно средств, истёкшая карта, таймаут шлюза.

   Use case «Оплатить заказ»
            │
   ┌────────┼─────────┬──────────────┐
   ▼        ▼         ▼              ▼
 успех   нет денег  карта истекла  таймаут
 (TC-1)   (TC-2)     (TC-3)        (TC-4)

⚠️ Частая ошибка: считать use case и тест-кейс одним документом под разными названиями. Use case описывает поведение, тест-кейс его проверяет; из одного сценария всегда рождается веер проверок, включая негативные.