Собеседование тестировщика: практические задачи по тест-дизайну и API

На собеседовании тестировщика могут дать описание функции и попросить рассказать, как вы её проверите. Удобно начать с условий: что должна делать программа, какие данные принимает и какой результат считается правильным. Затем выберите примеры, назовите ожидаемый ответ и объясните, почему проверяете именно их.

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

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

Условия учебного сервиса

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

Считаем, что на встрече интервьюер уточнил следующие правила:

• Комнаты R1 и R2 работают с 09:00 до 18:00 UTC. UTC — единое время, используемое в этом примере. Начало и конец брони должны попадать в рабочий промежуток; закончить ровно в 18:00 можно.
• Длительность — целое число минут от 30 до 120 включительно. Количество участников — целое число от 1 до 10 включительно.
• Интервалы включают начало и не включают конец: бронь 10:00–11:00 не мешает брони 11:00–12:00. Пересекающиеся интервалы одной комнаты недопустимы. Другая комната проверяется отдельно.
• Запрос POST /bookings создаёт бронь для пользователя, чей действующий токен указан в запросе. Токен — условный ключ, по которому сервис распознаёт пользователя. Неизвестные поля и ошибки в обязательных полях отклоняются.
• Запрос GET /bookings/{id} показывает бронь её владельцу. Другому пользователю сервис не раскрывает запись и отвечает так же, как для несуществующего номера.

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

Если на настоящем интервью условие неполное, сначала спросите о часовом поясе, границах времени, правилах доступа и том, какой ответ должен вернуть сервер. Пока правило не определено, нельзя уверенно объявить найденное поведение ошибкой.

Задача 1. Какие значения длительности и числа участников проверить

Условие: составьте проверки для длительности брони от 30 до 120 минут и числа участников от 1 до 10. Назовите ожидаемый результат для каждого типа данных.

«Сначала разделю значения на допустимые и недопустимые. Затем проверю числа около границ. Для каждого примера оставлю остальные поля правильными, а комнату свободной».

Группа значений, для которых по правилу ожидается одинаковое поведение, называется классом эквивалентности. Например, целые числа от 30 до 120 образуют допустимую группу длительности; числа ниже и выше диапазона — две недопустимые группы. Отдельно нужны проверки отсутствующего поля, null — значения, обозначающего отсутствие данных в JSON, дробного числа и строки вместо числа.

Граничные значения — числа на краях диапазона и рядом с ними. Для длительности проверим ближайшие целые числа. Во всех строках отправляем запрос на 13:00 в свободную комнату R1 с действующим токеном A и тремя участниками.

Для участников аналогичная шестёрка — 0, 1, 2, 9, 10, 11. Значения 1 и 10 должны приниматься, 0 и 11 — отклоняться. Длительность для этих проверок оставляем равной 60 минутам. Для обоих полей отдельно проверяем дробное число, строку, null и отсутствие поля: по условию здесь ожидается 400 и отсутствие новой записи.

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

Проверьте и часы работы

При свободной комнате бронь 09:00–09:30 и бронь 17:30–18:00 допустимы. Интервал 08:59–09:29 начинается до открытия, а 17:31–18:01 заканчивается после закрытия: оба должны получить 400. Даты и время в этих примерах заданы в UTC.

Задача 2. Как проверить пересечение бронирований

Условие: в комнате R1 уже есть бронь 5 ноября 2026 года с 10:00 до 11:00 UTC. Комната R2 свободна. Какие новые брони допустимы?

«Сравню начало и конец новой встречи с занятой. Особое внимание уделю случаям, где одна бронь заканчивается в ту же минуту, когда начинается другая».

Предполагаем действующий токен, корректные поля и одну исходную бронь R1. В таблице время окончания рассчитано из начала и длительности. Каждый вариант рассматривается отдельно, с восстановленным исходным состоянием.

Случай 09:30–11:30 важен: начало и конец новой встречи лежат за пределами существующей, но внутри неё всё равно занята комната. Если проверять только попадание начала новой встречи в старую, такую ошибку можно пропустить.

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

Что будет при двух одновременных запросах

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

Задача 3. Как проверить создание брони через API

Условие: комната R1 свободна 5 ноября 2026 года в 13:00–14:00 UTC. Пользователь A отправляет запрос на бронь для трёх участников. Что должно вернуться и что ещё нужно проверить?

Для этого учебного API договоримся о конкретных ответах: успешное создание — 201, некорректные поля — 400, отсутствующий или недействительный токен — 401, неизвестная комната или недоступная запись — 404, занятое время — 409. Ошибки возвращаются в JSON с полем error; при 401 есть заголовок WWW-Authenticate.

Запрос состоит из метода и пути, заголовков и тела. POST здесь означает запрос на создание, Content-Type указывает формат тела, а Authorization передаёт токен. JSON — текстовый формат, в котором данные записаны как пары названий и значений.

POST /bookings HTTP/1.1
Host: booking.example.invalid
Authorization: Bearer TOKEN_A
Content-Type: application/json

{
  "roomId": "R1",
  "start": "2026-11-05T13:00:00Z",
  "durationMinutes": 60,
  "participants": 3
}

Один из возможных ответов при успешном создании выглядит так. Номер B1 присвоен сервисом; заголовок Location указывает путь к новой записи.

HTTP/1.1 201 Created
Content-Type: application/json
Location: /bookings/B1

{
  "id": "B1",
  "roomId": "R1",
  "start": "2026-11-05T13:00:00Z",
  "durationMinutes": 60,
  "participants": 3
}

Проверьте не только код 201, но и тело: номер появился, комната, время, длительность и число участников совпадают с запросом. По пути из Location владелец может получить созданную запись с ответом 200. Также проверьте формат ответа и то, что возникла одна бронь, а не несколько.

Для отрицательной проверки измените только длительность на 121. В этом примере ожидаются 400, JSON {"error":"invalid_request"} и отсутствие новой записи. Если послать запрос без токена и с неверной длительностью одновременно, по условию сначала сработает проверка токена: такой запрос не покажет отдельно, работает ли проверка длительности.

Коды из таблицы — не универсальный контракт всех сервисов. Например, другая система может описывать ошибку проверки данных иначе. Сначала выясняйте требования конкретного API; HTTP-код помогает понять категорию ответа, но сам по себе не доказывает правильность сохранённых данных.

Задача 4. Можно ли прочитать чужую бронь

Условие: пользователь A создал бронь с номером B1. Пользователь B знает этот номер и отправляет запрос со своим действующим токеном. Каким должен быть ответ?

Для учебного сервиса владелец получает запись, а другой пользователь — 404 с ошибкой not_found. Такой же формат ошибки возвращается для несуществующего номера. Отсутствующий или просроченный токен даёт 401 с заголовком WWW-Authenticate.

GET /bookings/B1 HTTP/1.1
Host: booking.example.invalid
Authorization: Bearer TOKEN_B

HTTP/1.1 404 Not Found
Content-Type: application/json

{ "error": "not_found" }

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

Здесь 404 выбран условием сервиса, чтобы не подтверждать наличие чужой записи. В других API для отказа в доступе может использоваться 403; точное ожидание нужно проверять по правилам продукта. Важно разделять две проверки: сервис распознал пользователя и сервис разрешил именно ему читать конкретную запись.

Задача 5. Как описать найденную ошибку

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

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

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

Что проверить, если времени на интервью мало

Скажите, что вы выбираете первые проверки по рискам и уточняете объём оставшейся работы. Например, для нашего сервиса начните так:

1. Создание свободной брони. Пользователь может выполнить основное действие, а данные сохранились верно.
2. Занятое и соседнее время. Пересечение отклоняется; бронь на границе допускается. Ошибка здесь мешает пользоваться комнатой или приводит к двойному бронированию.
3. Границы и типы обязательных полей. Хотя бы крайние допустимые и ближайшие недопустимые значения длительности и числа участников.
4. Доступ к чужой записи. Пользователь не получает чужие данные по известному номеру.

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

Как подготовиться к собеседованию тестировщика

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

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

Что проверить перед следующим собеседованием

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

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