Все разборы

Тест-дизайн

Как ответить на вопрос «Какие техники тест-дизайна знаете и как выбираете» на собеседовании QA

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

Зачем это спрашивают

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

Вторая половина вопроса — «как выбираете» — отделяет junior от кандидата посильнее. Если вы применяете одну любимую технику ко всему подряд, это сразу видно. Если же вы объясняете, от чего зависит выбор, интервьюер понимает, что вы сможете самостоятельно спроектировать проверки для новой фичи.

Как построить сильный ответ

Удобная структура из трёх шагов.

1. Зачем нужны техники. Одной фразой: время ограничено, входных данных и комбинаций бесконечно много, поэтому нужен способ сократить число проверок без потери опасных мест.

2. Какие техники вы знаете. Назовите основные и коротко скажите, что каждая делает:

Техника Когда работает
Классы эквивалентности поведение зависит от значения поля: делим входы на группы, берём по представителю
Граничные значения у класса есть края: проверяем значения на границе и рядом с ней
Таблица решений результат зависит от комбинации нескольких условий
Переходы состояний у объекта есть статусы, и важна история действий
Попарное тестирование (pairwise) много независимых параметров, полный перебор слишком велик
Предугадывание ошибок известны типовые слабые места: пустые значения, повторы, обрывы
Исследовательское тестирование требований мало, нужно быстро изучить систему

Подробнее про первые две — в разборе классов эквивалентности и граничных значений.

3. Как выбираете. Это главная часть. Сформулируйте критерий: смотрите, от чего зависит поведение системы.

  • От значения одного поля — классы и границы.
  • От сочетания условий («если пользователь авторизован и сумма больше N и выбрана доставка курьером») — таблица решений.
  • От последовательности действий и текущего статуса — диаграмма переходов состояний.
  • От многих независимых настроек (браузер, ОС, язык, тип оплаты) — pairwise.
  • От того, что про систему почти ничего не известно, — исследовательская сессия и предугадывание ошибок.

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

Пример ответа

Техники тест-дизайна нужны, чтобы за ограниченное время выбрать немного проверок и при этом не пропустить опасные места. Я использую классы эквивалентности и граничные значения, таблицу решений, переходы состояний, попарное тестирование, а ещё предугадывание ошибок и исследовательское тестирование. Выбираю по тому, от чего зависит поведение. Если важны значения поля, например количество товара, — делю на классы и проверяю границы. Если результат зависит от нескольких условий сразу, как скидка при оформлении заказа, — строю таблицу решений. Если у объекта есть статусы, как у заказа, — рисую переходы и проверяю и допустимые, и запрещённые. Если параметров много, беру pairwise. Обычно я комбинирую: таблица даёт сочетания условий, а границы подсказывают значения внутри каждого сочетания.

Частые ошибки

  • Список без смысла. Назвать пять техник и замолчать. Интервьюер ждёт, что вы объясните, зачем каждая нужна.
  • Одна техника на всё. Например, проверять статусную модель заказа только граничными значениями. У каждой техники своя область применения.
  • Путать классы и границы. Классы — это группы значений с одинаковым поведением, границы — края этих групп. Это две связанные, но разные техники.
  • Забыть невалидные данные. Техники нужны не только для позитивных сценариев. Пустое поле, буквы вместо цифр, запрещённый переход статуса — такие же полноценные проверки.
  • Считать pairwise полным покрытием. Попарные комбинации не ловят дефекты, которые возникают только при сочетании трёх и более параметров. Об этом стоит сказать самому.
  • Не упомянуть комбинирование. Ответ «для этой фичи я использую только таблицу решений» звучит слабее, чем «таблица плюс границы для каждого условия».

Пример на MarketCove

Представьте, что вам дали проверить оформление заказа в учебном магазине https://shop.tomiddle.com. Разберём, какие техники здесь уместны.

Поля «Имя» и «Адрес». Поведение зависит от длины и состава строки, значит — классы и границы. Уточните у аналитика допустимую длину и набор символов и проверьте минимум, максимум и значения сразу за ними, а также строку из одних пробелов, дефис, букву «ё» и дробь в номере дома.

История заказов. Увидит ли покупатель заказ в профиле, зависит от комбинации условий: вошёл ли он до оформления, действителен ли токен, тот ли это аккаунт. Здесь подходит таблица решений:

Вошёл до оформления Токен действителен Тот же аккаунт Ожидание
да да да заказ виден в истории
да да нет заказа в истории нет
да нет — предложение войти заново, /api/users/me отвечает 401
нет — — заказ не появляется ни в одном профиле

Статусы заказа. В профиле и в админке заказ проходит через статусы. Здесь нужны переходы состояний: какие переходы разрешены, а какие должны быть запрещены (например, вернуть отменённый заказ в обработку, если правила этого не допускают).

Оформление гостем и авторизованным пользователем в разных браузерах. Параметров несколько: тип покупателя, браузер, один или несколько разных товаров в заказе, платформа — веб или Android-приложение. Полный перебор большой — pairwise сократит набор.

Сверху добавьте предугадывание ошибок: двойной клик по кнопке «Оформить», обновление страницы во время отправки, очищенный localStorage посреди сценария.

Задание для практики

Возьмите любую форму в https://shop.tomiddle.com, например оформление заказа. Выпишите все поля и правила, которые сможете найти в интерфейсе и в Swagger на /api/docs. Для каждого поля решите, какая техника подходит, и одной строкой объясните почему. Затем найдите хотя бы одно место, где поведение зависит от комбинации условий, и постройте для него таблицу решений. Проговорите результат вслух за две минуты — так, будто отвечаете на собеседовании. Для разминки пройдите блиц и посмотрите формулировки в разделе техник тест-дизайна.

Что спросят следом

  • Чем pairwise отличается от полного перебора комбинаций?
    Полный перебор проверяет все сочетания значений всех параметров, и их число растёт как произведение. Pairwise покрывает лишь каждую пару значений любых двух параметров хотя бы один раз. Подход опирается на наблюдение, что многие дефекты проявляются на взаимодействии двух факторов, поэтому набор получается в разы меньше, но ошибки от сочетания трёх и более параметров он может пропустить.
  • Что такое предугадывание ошибок и разве это техника?
    Это осознанный поиск мест, где ошибки появляются чаще всего: пустые значения, нули, двойной клик, обрыв сети, повторная отправка формы. Основа — опыт и знание типовых дефектов, поэтому результат зависит от тестировщика. Её используют как дополнение к формальным техникам, а не вместо них.
  • Нужно ли применять техники, если тест-кейсов пишут мало?
    Да, техники нужны для выбора проверок, а не для оформления документов. Даже короткий чек-лист станет сильнее, если значения в нём выбраны по границам и классам, а сценарии — по переходам состояний. Формат записи не важен, важно обоснование.
  1. Q-01
    Что такое классы эквивалентности и граничные значения?
  2. Q-02
    Протестируйте лифт (ручку, кофемашину)
  3. Q-03
    Чем тест-кейс отличается от чек-листа?
  4. Q-04
    Что такое пирамида тестирования?

Отрепетировать ответ с куратором

В сопровождении — весь банк вопросов, мок-собеседование и разбор каждого настоящего собеседования, пока не придёт оффер. Гарантий трудоустройства не даём — готовим к тому, что спросят.