Postman и API-тестирование на собеседовании QA: что знать и как тренироваться
Вопросы про Postman быстро показывают разницу между «знаю слова про API» и «умею отправить запрос и понять ответ». Интервьюер смотрит не на кнопку Send, а на ход мысли.
- Метод и URL
- Auth и headers
- Body и параметры
- Статус, схема и данные
Что нужно уметь в Postman
Создать запрос, выбрать GET или POST, добавить query-параметры, отправить JSON в body, поставить Authorization header и прочитать status code с response body.
Для собеседования это важнее продвинутой автоматизации. Кандидат, который понимает один ответ, сильнее кандидата, который выучил названия вкладок.
Какие проверки ждут от тестировщика
У каждого API-ответа проверяй четыре слоя: код, структуру, значения и побочный эффект. 200 с неправильной суммой — баг. 422 с неправильным именем поля — тоже баг.
- Код ответа соответствует ситуации.
- Обязательные поля есть и имеют нужные типы.
- Важные значения соответствуют запросу и требованиям.
- Ошибки не показывают stack trace и внутренние пути.
- Повтор запроса не создаёт случайные дубли.
Проверки авторизации в API
Каждый защищённый запрос проверь с валидным токеном, без токена, с битым токеном и с токеном другого пользователя. Много серьёзных API-дефектов живёт именно в последнем случае.
Если endpoint возвращает данные, спрашивай: чьи это данные? Аутентификация говорит, кто ты; авторизация решает, что тебе можно видеть.
Типичные ошибки на интервью по Postman
Частые ошибки: отправлять только happy path, не смотреть body после 200, забывать headers и не сохранять точный запрос, на котором дефект воспроизвёлся.
Хорошая привычка: после подозрительного ответа сразу записывать method, path, body и response. Это уже половина багрепорта.
Практика перед собеседованием
Возьми любой учебный API и проверь один endpoint с валидными данными, без обязательного поля, с неверным типом, на границе, без токена и с id чужого объекта.
Если можешь объяснить ожидаемый ответ в каждом случае и написать один багрепорт по результату, ты готова к большинству junior-вопросов про Postman.
Реальные проверки в Tests, а не console.log
Каждый тест должен сообщать, какое обещание нарушено. Отдельные assertions быстрее локализуют причину, чем один большой блок. Сначала проверяй статус и тип ответа, затем схему и бизнес-значения; только после этого сохраняй id для следующего запроса.
Скрипт ниже не доказывает корректность заказа целиком, но создаёт хороший минимальный сигнал: ответ создан, JSON читается, обязательные поля имеют ожидаемый тип, сумма положительна, а id можно безопасно передать дальше.
pm.test("order created", () => pm.response.to.have.status(201));\n\nconst body = pm.response.json();\npm.test("contract and values", () => {\n pm.expect(body).to.have.property("id").that.is.a("number");\n pm.expect(body).to.have.property("status", "new");\n pm.expect(body.total).to.be.a("number").and.above(0);\n});\n\npm.collectionVariables.set("orderId", body.id);
Переменные, цепочки, Runner и CI
Выбирай минимальный scope: local для временного секрета, data variables для строки Runner, environment для адреса и окружения, collection для данных сценария. Не коммить реальные токены в exported collection. Созданные тестом записи помечай уникальным префиксом и удаляй в teardown, если это разрешено.
- Pre-request script создаёт уникальные данные или обновляет токен.
- Tests сохраняет id ответа только после проверки контракта.
- Следующий запрос использует {{orderId}} и проверяет тот же объект.
- Collection Runner повторяет сценарий по CSV/JSON-набору, включая negative data.
- Postman CLI или Newman запускает ту же коллекцию в CI и возвращает ненулевой exit code при падении.
Вопросы, которыми углубляют ответ на интервью
Будь готова не перечислять вкладки, а разобрать последствия. Почему тест на 200 слабый? Где хранить secret? Как отличить 401 от 403? Что произойдёт при повторе POST после timeout? Как проверить pagination, rate limit и чужой object id?
Сильный кандидат проговаривает oracle: откуда взят expected result. Это OpenAPI, acceptance criterion, RFC, запись после GET, состояние базы или согласованное бизнес-правило. Без oracle даже красивый скрипт лишь закрепляет текущее поведение.
Частые вопросы по Postman
Нужно ли учить JavaScript для собеседования manual QA?
Обычно достаточно прочитать JSON, объявить const, обратиться к полю, написать pm.test и pm.expect. Гораздо важнее объяснить, что и почему проверяет assertion. Требования конкретной вакансии могут быть выше.
Postman заменяет проверку базы данных?
Нет. API показывает внешний контракт. Для критичного side effect может понадобиться последующий GET, событие, запись в базе или проверка интеграции. Выбирай наблюдение, доступное на проекте и не нарушающее данные.
Чем Collection Runner отличается от Newman или Postman CLI?
Runner запускает коллекцию интерактивно в Postman. CLI-инструмент запускает её из терминала и CI, где важны environment, reporters и exit code. Проверки должны оставаться одинаковыми.
Postman — не навык сам по себе. Навык — заметить, что сервер обещал, и что он сделал на самом деле.