Тест-дизайн: вопросы для собеседования QA

Чек-лист — быстрый список проверок без детальных шагов.

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

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

Тест-кейс детализирован и хорошо подходит для стабильной регрессии и передачи знаний.

Чек-лист быстрее в поддержке и удобен там, где команда опытная и сценарии понятные.

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

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

Граничные значения нужны, потому что ошибки чаще всего живут на границах диапазона: минимум, максимум и соседние значения.

Из практики: для поля возраста 18–65 я проверяю 17, 18, 19, 64, 65, 66 — этого обычно достаточно, чтобы быстро поймать дефект в валидации.

Позитивное подтверждает корректные пути — валидные данные, правильная последовательность действий, ожидаемое поведение.

Негативное проверяет отказоустойчивость — некорректные данные, неожиданные действия, граничные случаи.

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

Пустые значения проверяю в нескольких вариантах: null, пустая строка, строка из пробелов и отсутствие поля в запросе.

Важно отдельно проверить поведение на интерфейсе, API и в базе: одинаково ли трактуются такие значения во всех слоях.

Из практики: самые неприятные дефекты появляются, когда интерфейс считает значение пустым, а сервер сохраняет его как валидное.

Стратегию строю от рисков: определяю точки валидации (поля ввода, бизнес-правила, интеграции, ресурсные ограничения) и для каждой готовлю классы невалидных данных.

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

Из практики: негативные сценарии нахожу быстрее, когда начинаю с вопроса «что система должна отклонить» — это структурирует список лучше, чем перебор данных вслепую.

Я обычно начинаю с правил валидации на уровне интерфейса, потом дублирую ключевые проверки на стороне сервера.

Обязательно проверяю граничные значения, пустые поля и ошибки формата, чтобы не было «тихих» сбоев в данных.

Из практики: лучшая защита от грязных данных — одинаковые правила проверки во всех слоях.

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

Попарное тестирование сокращает количество проверок: мы покрываем все пары параметров, а не полный перебор всех комбинаций.

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

Базовые техники тест-дизайна: эквивалентные классы, граничные значения, таблицы решений, переходы состояний и попарное покрытие.

Выбор техники зависит от задачи: для диапазонов лучше границы, для сложной логики — таблицы, для статусных объектов — переходы состояний.

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

Начинаю с позитивного сценария: корректные данные, успешная регистрация и подтверждение пользователя.

Дальше проверяю негатив: пустые поля, формат email/телефона, слабые пароли, дубликаты и повторную отправку формы.

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

Проверяю формат ввода (ручной и через календарь), допустимые диапазоны min/max, граничные даты: 28/29/30/31 февраля, конец месяца, високосный год, переход между годами.

Добавляю негативные кейсы: невалидный формат, дата в прошлом если запрещена, дата за пределами диапазона, пустое поле.

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

Начинаю с базового: фильтр применился, результат соответствует условиям.

Проверяю комбинации фильтров, сброс, сохранение состояния, пагинацию и сортировку вместе с фильтрами.

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

Проверяю успешный вход с валидными данными, корректность редиректа и создание пользовательской сессии.

Дальше иду по негативу: пустые поля, неверные креды, блокировки, сообщения об ошибке и ограничения попыток.

Из практики: полезно сразу сверять интерфейсный результат с API и журналами, чтобы не пропустить проблемы на стыке слоёв.

Функциональность: релевантность результатов по точному и частичному запросу, работа автокомплита и подсказок, поиск по разным полям (название, описание, теги), фильтры в сочетании с поиском.

Граничные случаи: пустой запрос, строка из пробелов, очень длинный запрос (>500 символов), спецсимволы (`<script>`, `" OR "1"="1`), Unicode и эмодзи, запрос без результатов (пустая выдача с понятным сообщением), нечувствительность к регистру и опечаткам.

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

Предварительная проверка: валидация корзины (цены, наличие, скидки, промокоды), переход к оформлению с разными состояниями корзины.

Проверяю данные пользователя (адрес доставки, способ оплаты), итоговую сумму на каждом шаге, успешный и отклонённый платёж, подтверждение заказа и уведомления.

Из практики: самые дорогие дефекты в checkout — расхождение цены между корзиной и оплатой, и двойное списание при повторной отправке формы оплаты.

Я начинаю с риска: определяю, где ошибка будет самой дорогой, и под это выбираю технику тест-дизайна.

Для полей и диапазонов беру границы и эквивалентные классы, для сложной логики — таблицы решений, для статусов — переходы состояний.

Из практики: такой подход даёт компактный, но результативный набор проверок без лишнего дублирования.

Проверяю основные платёжные сценарии: успешная оплата разными методами (карта, электронный кошелёк), отклонение карты, недостаток средств, истёкшая карта.

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

Из практики: критично тестировать повторную отправку платёжной формы — двойное списание встречается именно здесь, и пользователи его замечают сразу.

Быстро пересобираю план: выделяю must-have сценарии, что можно отложить и какие риски принимаем осознанно.

Запускаю risk-based тестирование: smoke, критические флоу.

Из практики: такой подход хорошо работает в сжатые сроки, когда важно не распыляться на второстепенное.

Нахожу диапазон допустимых значений, потом проверяю минимум, минимум+1, максимум-1, максимум и выход за границы с обеих сторон.

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

Из практики: для поля возраста 18–65 шесть проверок (17, 18, 19, 64, 65, 66) покрывают граничную логику полностью вместо перебора всех чисел. Именно на границах ±1 чаще всего прячутся ошибки в условиях.

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

После построения таблицы проверяю покрытие конфликтных веток: нет ли комбинаций, которые дают противоречивые правила или не охвачены ни одним правилом.

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

Рисую состояния сущности и допустимые переходы между ними — получаю диаграмму состояний. Проверяю все валидные переходы, все запрещённые переходы и граничные случаи (повторное действие, откат назад).

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

Из практики: для заказа (Создан → Оплачен → Отправлен → Доставлен) критично проверить запрещённые переходы — нельзя перевести 'Отправлен' обратно в 'Создан'. Эти кейсы пропускают чаще всего.

Использую попарный подход когда параметров много, а полный перебор слишком дорог по времени. Сначала выделяю критичные параметры, потом строю пары через allpairs или PICT.

Дополнительно добавляю отдельные кейсы для самых рискованных комбинаций из трёх и более параметров, которые попарный метод не гарантирует покрыть.

Из практики: попарное тестирование для формы с 5 параметрами по 3 значения сокращает набор с 243 до примерно 11-15 тест-кейсов. Вручную такое не строить — использую утилиты.

Я делю входы на классы: пустая строка, строка из пробелов, слишком короткая (< min), валидная длина, граничная по максимуму, превышающая максимум, спецсимволы, Unicode/эмодзи, SQL/HTML-инъекции.

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

Из практики: строковые поля чаще всего ломаются на спецсимволах и Unicode — проверяю их отдельно, даже если это кажется маловероятным.

Начинаю с риск-ориентированного подхода: беру критичные пользовательские потоки и участки с наибольшей вероятностью дефекта (новый код, сложная логика, интеграции).

Добавляю короткий набор негативных и граничных проверок для самых частых классов ошибок. Документирую, что осознанно пропущено и какой риск принят.

Из практики: приоритизирую по формуле (вероятность дефекта × цена дефекта) / время проверки. Это даёт чёткий порядок без субъективных споров и помогает объяснить команде, почему именно эти тесты.

Для обязательных полей проверяю: пустое значение, строку из пробелов, слишком короткое/длинное значение, невалидный формат — ожидаю понятное сообщение об ошибке и блокировку отправки.

Для необязательных полей проверяю, что форма успешно отправляется без них, значение по умолчанию корректно, и данные сохраняются правильно при заполнении и при пустом поле.

Из практики: чаще всего дефекты в обязательных полях — это пробелы, которые проходят валидацию как «заполненное поле», и поля, которые обязательны на UI, но не валидируются на бэке.

Тест-оракул — это источник, по которому я понимаю, правильно работает система или нет: требования, API-договор, расчётная формула, данные в базе или согласованный макет.

Без оракула нет критерия правильности — тест может проходить, но не проверять ничего значимого. Иногда оракулом служит предыдущая версия системы или параллельная реализация.

Из практики: при тестировании расчёта комиссии использую два оракула одновременно — спецификацию и независимый расчёт в Excel. Расхождение между ними — сигнал либо бага в коде, либо противоречия в требованиях.

Проверяю каждый фильтр отдельно, потом наиболее критичные комбинации: фильтр А + фильтр Б, фильтры + сортировка, фильтры + пагинация.

Обязательно смотрю сброс фильтров (URL и состояние), возврат кнопкой браузера с сохранением фильтров, поведение при пустом результате.

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

Смотрю на дефектоёмкость: сколько дефектов найдено на один тест и насколько критичны эти дефекты. Если набор большой, а дефектов мало — техника или фокус выбраны неверно.

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

Из практики: если на 100 тест-кейсов приходится 2 найденных дефекта — или техника работает плохо, или зона избыточно покрыта. Пересматриваю фокус и добавляю исследовательские сессии.

Я выделяю параметры, которые реально влияют на поведение, и строю пары значений для максимального покрытия.

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

Из практики: это сильно сокращает объём тестов, но критичные сценарии всё равно проверяю отдельно.

Таблица решений хороша, когда важны комбинации условий и ожидаемых действий.

Диаграмма состояний лучше работает там, где важен порядок переходов между статусами.

Из практики: выбор техники по типу логики сразу делает тесты точнее и короче.

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

Потом строю минимальный набор кейсов, который покрывает основные ветки и самые рискованные исключения.

Из практики: без такой структуры тесты быстро разрастаются и перестают быть управляемыми.

Я формулирую ключевые инварианты системы и добавляю проверки на каждом критичном шаге сценария.

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

Из практики: инварианты отлично ловят редкие, но очень дорогие дефекты.

Класс эквивалентности — это группа значений, при которых система ведёт себя одинаково. Достаточно протестировать одно значение из каждого класса, чтобы покрыть всю группу.

Пример: возраст от 18 до 65 — валидный, до 18 — некорректный (несовершеннолетний), после 65 — некорректный (пенсионер). Три класса, три значения из них.

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

Граничное значение — это значение на границе класса эквивалентности. Опыт показывает, что ошибки чаще всего находятся именно на границах: off-by-one, неправильное сравнение (< вместо <=), переполнение типа.

Для диапазона [1, 100] проверяют 0, 1, 100, 101. Также 2 и 99 — соседние значения. Для строк — длина 0, 1, максимум, максимум+1.

Из практики: ловит классические баги типа «при возрасте ровно 18 показывает форму для подростков», «в поле 256 символов вместо 255 теряются данные».

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

Например, для 3 факторов по 3 значения полный перебор — 27 кейсов, pairwise — 9. Используют генераторы (PICT, allpairs.py).

Из практики: незаменимо там, где много параметров (платёжные методы × устройство × ОС × язык). Резко сокращает количество тест-кейсов без существенной потери покрытия.

Таблица решений — это структурированный способ описать «если входы такие-то, то результат такой-то». В строках — условия и ожидаемые действия, в столбцах — варианты комбинаций.

Особенно полезна для бизнес-логики с несколькими условиями: например, «скидка зависит от типа клиента, объёма заказа и наличия промокода».

Из практики: помогает не упустить редкие комбинации и обсудить логику с PM. Заодно служит спецификацией для разработчика.

State transition testing — это техника для систем с состояниями. Описывают конечный автомат: состояния и переходы между ними при определённых событиях. Тест-кейсы покрывают переходы.

Уровни покрытия: каждый переход, каждое состояние, каждый цикл, все пары переходов.

Из практики: типовая область — заказы (создан → оплачен → отгружен → доставлен → возвращён), статусы пользователя, mode'ы устройства. Помогает понять и протестировать как валидные, так и невалидные переходы.

Исследовательское тестирование — это одновременное обучение, проектирование тестов и их выполнение. Тестировщик не следует заранее написанному скрипту, а исследует продукт, основываясь на догадках и опыте.

Сила — в обнаружении неочевидных багов, поведения на необычных сценариях и в проверке UX. Особенно полезно для новых фич, рискованных областей, перед релизом.

Из практики: часто оформляют как session-based testing — назначают цель сессии (charter), время (60-90 минут), потом фиксируют находки и идеи. Это даёт структуру без скованности скриптами.

Risk-based testing — это подход, при котором приоритет проверок выбирают по риску: вероятность дефекта × ущерб от него. Чем выше риск — тем глубже тестирование.

Идентифицируют риски (новизна фичи, сложность, частота изменений, влияние на пользователей, регуляторика) и выстраивают тестовое покрытие соответственно.

Из практики: на платежи и аутентификацию выделяют больше времени, чем на «настройки уведомлений». Это структурно объясняет, почему «не всё» тестируем одинаково.

Model-based testing — это подход, где сначала строится модель системы (state machine, граф потоков, описание правил), а из неё автоматически или полуавтоматически генерируются тест-кейсы.

Модель может быть текстовой (decision table), диаграммой (state chart), или формальной (TLA+, Alloy). Инструменты: GraphWalker, Spec Explorer.

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

Error guessing — техника, основанная на опыте тестировщика: где обычно бывают ошибки. Это не формальная процедура, а интуиция, наработанная на сотнях найденных багов.

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

Из практики: эта техника отлично дополняет формальные. Её можно «формализовать» в виде чек-листов опасных мест и постоянно расширять по мере накопления опыта в проекте.

Чек-лист — это короткий список пунктов, что нужно проверить, без подробных шагов. Удобен для smoke-тестов, регрессии, exploratory-сессий.

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

Из практики: для большинства проектов хороший баланс — чек-листы на повседневное и тест-кейсы на критичные сценарии (платежи, регистрация, миграции). Не нужно всё расписывать как тест-кейс.

Test oracle — это источник истины: как определить, что результат теста правильный. Может быть документация, прежняя версия системы, эталонная реализация, common sense.

Не всегда очевиден. Иногда oracle сложно сформулировать — например, для AI/ML систем.

Из практики: для каждого теста важно понимать, какой именно oracle используется. Без оракула тест не имеет смысла.

Тестирование, опирающееся на профессиональный опыт и интуицию тестировщика. Не следует строгим скриптам, а исследует продукт глазами эксперта.

Эффективно в зрелых командах с опытными QA. Дополняет формальное тестирование.

Из практики: невозможно полностью автоматизировать. Опытные QA находят баги, которые ни в одном тест-кейсе не описаны.

Script-based — тесты, прописанные шагами, повторяемые точно. Хорошо для регрессии, автоматизации.

Model-based — тесты, генерируемые из модели системы (state machine, decision table). Может покрывать больше комбинаций.

Из практики: большинство команд используют скрипты. Model-based — нишевое, окупается для очень сложных систем.