Как тестировать экран бронирования отелей всеми возможными способами
Что проверяют
Умеете ли вы структурировать бесконечную задачу: разложить экран на функции, риски и уровни, а не перечислять «функциональное, нагрузочное, безопасности». Следом просят назвать первые пять проверок, если на всё есть час.
Как отвечать
Сначала задайте вопросы: веб или мобильное приложение, что входит в экран (поиск, выбор номера, оплата), какие интеграции и требования. Потом идите по слоям:
- функциональность: даты заезда и выезда (выезд раньше заезда, одна ночь, бронь на год вперёд, прошедшая дата, 29 февраля), число гостей и возраст детей, лимит гостей на номер, фильтры, пересчёт цены при смене параметров;
- деньги: итог равен сумме ночей, налогов и сборов, валюта, промокоды, условия отмены видны до оплаты;
- конкурентность: двое берут последний номер одновременно, цена изменилась между поиском и оплатой, двойной клик по «Забронировать» не создаёт две брони;
- интеграции: отказ платёжного шлюза, таймаут API поставщика, повтор запроса без дубля, письмо с подтверждением;
- часовые пояса: дата в поиске и дата в отеле в разных зонах;
- интерфейс: адаптивная вёрстка, кроссбраузерность, навигация с клавиатуры, подписи для скринридера, формат дат в локали;
- нефункциональное: время ответа поиска под нагрузкой, доступ к чужой брони подменой id, платёжные и персональные данные не попадают в логи.
Закончите приоритизацией: что проверяете первым, что автоматизируете (API-тесты на расчёт цены и создание брони, пара сквозных сценариев в Playwright), что оставляете исследовательскому тестированию.
Где спотыкаются
Перечисляют виды тестирования без единой конкретной проверки. Интервьюер ждёт кейсы про даты и деньги, а не определения из учебника.
Забывают про гонки и двойные бронирования. Для бронирования это самый дорогой класс багов.
Не задают уточняющих вопросов и начинают тестировать «всё». Без рамок ответ получается длинным и бессистемным.