Postman на собеседовании QA: 12 вопросов по API-тестированию, которые задают джунам

«Я пришел на собеседование на позицию junior QA. Резюме — норм, курсы прошел, теорию знаю. Интервьюер открывает Postman и говорит: "Давайте протестируем вот этот API. Отправьте GET-запрос на /users." Я открываю Postman... и понимаю, что не знаю, куда вписывать URL. Серьезно. Я знал, что такое GET. Но в Postman я никогда не работал. Собеседование закончилось через 10 минут.»

Это реальная история Алексея, junior QA из Москвы.

И он не один.

Парадокс современных QA-джунов:

Вы проходите курсы. Учите теорию тестирования. Знаете, что такое REST API, HTTP-методы, статус-коды.

Но когда на собеседовании просят открыть Postman и отправить запрос — ступор.

Почему так происходит?

• Теория без практики: Курсы дают теорию, но мало практики с реальными API.

• Postman кажется сложным: На самом деле это самый простой инструмент для API-тестирования.

• Незнание базовых вопросов: Джуны не знают, что именно спрашивают на собеседованиях.

Реальность рынка QA в России (2025):

• 70-80% компаний требуют знание Postman для позиции junior QA

• API-тестирование — обязательный навык (не "желательно", а "обязательно")

• Postman — неофициальный стандарт для API-тестирования (используют 8+ млн разработчиков)

• Средняя зарплата junior QA с знанием Postman: 80,000-120,000₽/мес (Москва: 100,000-140,000₽)

Проблема:

На курсах вам говорят: «Postman — это инструмент для тестирования API.» И всё.

Но на собеседовании вас спрашивают:

• «В чем разница между PUT и PATCH?»

• «Как создать Environment Variable?»

• «Как автоматизировать тесты в Postman?»

• «Что вернет сервер при успешном DELETE-запросе?»

И если вы не знаете — отказ.

Эта статья для тех, кто:

1. Готовится к собеседованию на позицию junior QA

2. Хочет понять, что именно спрашивают про Postman

3. Нужны конкретные ответы на типовые вопросы

4. Хочет подготовиться за 1-2 недели

5. Не хочет провалить собеседование из-за незнания базовых вещей

Мы разберем:

• 12 самых частых вопросов про Postman и API-тестирование на собеседованиях

• Подробные ответы с примерами и скриншотами логики

• Частые ошибки джунов

• План подготовки за 1-2 недели

• Реальные истории успехов и провалов

Без воды. Только то, что реально спрашивают в 2025 году.

Что такое API-тестирование и зачем оно нужно

Прежде чем разбирать вопросы, давайте поймем: что такое API и зачем его тестировать?

Что такое API

API (Application Programming Interface) — это интерфейс, через который разные программы общаются друг с другом.

Простыми словами:

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

API работает так же:

• Клиент (фронтенд, мобильное приложение) отправляет запрос (request)

• API передает запрос на сервер (backend)

• Сервер обрабатывает запрос и отправляет ответ (response)

• Клиент получает ответ и показывает данные пользователю

Пример:

Вы открываете приложение ВКонтакте. Видите ленту постов. Откуда они взялись?

1. Приложение отправило запрос к API: GET /api/news_feed

2. Сервер ВК обработал запрос, взял посты из базы данных

3. Сервер вернул ответ (JSON с постами)

4. Приложение показало вам посты

API — это мост между фронтендом и бэкендом.

Что такое REST API

REST (Representational State Transfer) — это архитектурный стиль для создания API.

Основные принципы REST:

1. Клиент-серверная архитектура: Клиент и сервер независимы.

2. Без сохранения состояния (stateless): Каждый запрос содержит всю необходимую информацию. Сервер не помнит предыдущие запросы.

3. Единообразный интерфейс: Стандартные HTTP-методы (GET, POST, PUT, DELETE).

4. Ресурсы: Все данные представлены как ресурсы (пользователи, посты, заказы).

Пример REST API:

GET /api/users — получить список пользователей GET /api/users/123 — получить пользователя с ID 123 POST /api/users — создать нового пользователя PUT /api/users/123 — обновить пользователя с ID 123 DELETE /api/users/123 — удалить пользователя с ID 123

Зачем тестировать API

Почему API-тестирование важно?

1. Раннее обнаружение багов: API тестируется до того, как готов интерфейс. Баги находятся раньше.

2. Независимость от UI: Интерфейс может меняться, но API — стабилен. Тесты не ломаются.

3. Производительность: API-тесты работают быстрее UI-тестов (нет загрузки браузера, рендеринга).

4. Покрытие: Можно протестировать сценарии, которые сложно проверить через UI.

Что проверяют при API-тестировании?

Вывод: API-тестирование — это обязательный навык для QA в 2025 году. Без него не возьмут даже на junior позицию.

Postman: почему его спрашивают на собеседованиях

Postman — это самый популярный инструмент для тестирования API.

Что такое Postman

Postman — это приложение (desktop или web), которое позволяет:

• Отправлять HTTP-запросы к API (GET, POST, PUT, DELETE и т.д.)

• Просматривать ответы сервера (JSON, XML, HTML)

• Автоматизировать тесты (писать проверки на JavaScript)

• Создавать коллекции запросов

• Работать с переменными (environment, global)

• Запускать тесты через командную строку (Newman)

Почему Postman так популярен?

1. Бесплатный (есть платная версия, но базовые функции — бесплатны)

2. Простой интерфейс (интуитивно понятный)

3. Не требует программирования (для базовых задач)

4. Поддерживает автоматизацию (для продвинутых задач)

5. Кроссплатформенный (Windows, Mac, Linux, Web)

Почему Postman спрашивают на собеседованиях

Статистика:

• 70-80% компаний в России используют Postman для API-тестирования

• Обязательное требование для junior QA в большинстве вакансий

• 8+ миллионов пользователей по всему миру

Альтернативы Postman:

• SoapUI — сложнее, для SOAP API

• Insomnia — проще, но менее популярен

• REST Assured — для автоматизации на Java (не для ручного тестирования)

• cURL — консольный инструмент (для продвинутых)

Вывод: Если вы QA и не знаете Postman — вас не возьмут. Это как разработчик, который не знает Git.

12 вопросов по Postman и API-тестированию на собеседованиях

Теперь разберем 12 самых частых вопросов, которые задают junior QA на собеседованиях.

Вопрос 1: Что такое REST API и чем он отличается от SOAP?

Почему спрашивают:

Это базовый вопрос. Если вы не знаете разницу между REST и SOAP — собеседование закончено.

Ответ:

REST (Representational State Transfer) — архитектурный стиль для создания API, использует HTTP-методы и обычно возвращает данные в JSON.

SOAP (Simple Object Access Protocol) — протокол обмена данными, использует XML для сообщений.

Основные отличия:

Пример REST:

GET /api/users/123 Response: {"id": 123, "name": "Иван", "email": "ivan@mail.ru"}

Пример SOAP:

xml <soap:Envelope> <soap:Body> <GetUser> <UserId>123</UserId> </GetUser> </soap:Body> </soap:Envelope>

Когда использовать REST:

• Веб и мобильные приложения

• Простые CRUD операции (Create, Read, Update, Delete)

• Когда нужна скорость

Когда использовать SOAP:

• Банковские системы

• Когда нужна высокая безопасность

• Когда требуется строгий контракт (WSDL)

Вопрос 2: Какие HTTP-методы вы знаете? В чем разница между GET и POST?

Почему спрашивают:

Это фундаментальный вопрос. Если не знаете HTTP-методы — вы не сможете тестировать API.

Ответ:

Основные HTTP-методы:

Разница между GET и POST:

Пример GET:

GET /api/users?age=25&city=Moscow

Данные передаются в URL. Можно скопировать ссылку и отправить кому-то.

Пример POST:

POST /api/users Body: { "name": "Иван", "email": "ivan@mail.ru", "age": 25 }

Данные передаются в теле запроса. Нельзя скопировать как ссылку.

Идемпотентность:

• GET: Можно отправить 100 раз — результат один и тот же (получите одни и те же данные).

• POST: Отправили 100 раз — создали 100 пользователей.

Вопрос 3: Какие HTTP статус-коды вы знаете? Что означает 200, 404, 500?

Почему спрашивают:

Статус-коды — это язык общения с API. Если вы не знаете, что означает 404 — вы не сможете понять, что пошло не так.

Ответ:

HTTP статус-коды делятся на 5 классов:

Самые важные статус-коды для QA:

Что проверять при тестировании:

• GET /users/123 → Ожидаем 200 OK (если пользователь существует)

• GET /users/999 → Ожидаем 404 Not Found (если пользователя нет)

• POST /users → Ожидаем 201 Created (создан новый пользователь)

• DELETE /users/123 → Ожидаем 204 No Content (пользователь удален)

Частая ошибка джунов:

Ожидают 200 OK для всех успешных запросов. Но для POST должен быть 201 Created, а для DELETE — 204 No Content.

Вопрос 4: Что такое JSON? Чем он отличается от XML?

Почему спрашивают:

JSON — основной формат данных в REST API. Если вы не понимаете структуру JSON, вы не сможете проверить ответ сервера.

Ответ:

JSON (JavaScript Object Notation) — текстовый формат для обмена данными.

Пример JSON:

json { "id": 123, "name": "Иван", "age": 25, "email": "ivan@mail.ru", "is_active": true, "roles": ["user", "admin"], "address": { "city": "Москва", "street": "Ленина", "house": 10 } }

Структура JSON:

• Объект: { "key": "value" }

• Массив: ["item1", "item2"]

• Типы данных: string, number, boolean, null, object, array

XML (eXtensible Markup Language):

```xml 123 Иван 25 ivan@mail.ru true user admin
 

Москва Ленина 10

```

Разница:

Где используется JSON:

• REST API (99% случаев)

• Конфигурационные файлы (package.json)

• NoSQL базы данных (MongoDB)

Вопрос 5: Как создать коллекцию в Postman и зачем она нужна?

Почему спрашивают:

Collections — базовая функция Postman. Если вы не знаете, как создать коллекцию, вы не сможете организовать тесты.

Ответ:

Collection (Коллекция) — это группа запросов, объединенных по смыслу.

Зачем нужны коллекции:

1. Организация: Группировка запросов по функциональности (например, "User API", "Order API")

2. Повторное использование: Один раз настроили, используете много раз

3. Автоматизация: Можно запустить все запросы из коллекции одной кнопкой

4. Совместная работа: Можно экспортировать и поделиться с командой

Как создать коллекцию:

1. Открыть Postman

2. Нажать "New" → "Collection"

3. Ввести название: например, "User API Tests"

4. Добавить описание (опционально)

5. Сохранить

Структура коллекции:

User API Tests (коллекция) ├── Get all users (запрос) ├── Get user by ID (запрос) ├── Create user (запрос) ├── Update user (запрос) └── Delete user (запрос)

Как добавить запрос в коллекцию:

1. Создать новый запрос (New → Request)

2. Ввести название запроса

3. Выбрать коллекцию, куда сохранить

4. Настроить запрос (URL, метод, headers, body)

5. Сохранить

Как запустить всю коллекцию:

1. Открыть коллекцию

2. Нажать "Run" (или три точки → Run collection)

3. Выбрать, какие запросы запустить

4. Нажать "Run User API Tests"

5. Postman выполнит все запросы по очереди

Вывод: Collections — это как папки для файлов. Без них ваши запросы будут хаотичными.

Вопрос 6: Что такое Environment Variables и зачем они нужны?

Почему спрашивают:

Переменные окружения — ключевая функция Postman. Без них вы не сможете переключаться между тестовыми и продакшн-окружениями.

Ответ:

Environment Variables (Переменные окружения) — это переменные, которые хранят данные, используемые в запросах.

Зачем нужны:

1. Переключение между окружениями: dev, stage, production

2. Хранение токенов: Авторизационный токен, который меняется

3. Повторное использование: Не нужно везде менять URL вручную

Пример задачи:

У вас есть API с тремя окружениями:

• Dev: https://dev-api.example.com

• Stage: https://stage-api.example.com

• Prod: https://api.example.com

Вы хотите протестировать API на всех трех окружениях. Без переменных вам нужно создать 3 копии каждого запроса. С переменными — создаете одну коллекцию и переключаете окружение.

Как создать Environment:

1. Нажать на иконку "Environments" (справа вверху)

2. Нажать "Create Environment" (или "+")

3. Ввести название: например, "Dev Environment"

4. Добавить переменные:

5. base_url: https://dev-api.example.com

6. auth_token: your_token_here

7. Сохранить

Как использовать переменные в запросах:

Вместо:

GET https://dev-api.example.com/api/users

Пишете:

GET {{base_url}}/api/users

Postman автоматически подставит значение base_url из активного окружения.

Типы переменных в Postman:

Пример сценария:

1. Отправили POST /auth/login → Получили токен

2. Сохранили токен в переменную auth_token (через скрипт в Tests)

3. Используете токен во всех последующих запросах: Authorization: Bearer {{auth_token}}

Как установить переменную через скрипт:

javascript // В табе Tests pm.environment.set("auth_token", pm.response.json().token);

Вывод: Environment Variables — это как переменные в программировании. Один раз определил, используешь везде.

Вопрос 7: Как автоматизировать тесты в Postman?

Почему спрашивают:

Автоматизация — следующий уровень после ручного тестирования. Если вы знаете, как писать тесты в Postman, вы ценнее как специалист.

Ответ:

Автоматизация в Postman — это написание проверок (assertions) в табе Tests, которые выполняются после каждого запроса.

Что можно проверять:

1. Статус-код: Вернулся ли код 200?

2. Время ответа: Ответил ли сервер за < 500ms?

3. Тело ответа: Есть ли в ответе нужное поле?

4. Заголовки: Есть ли нужный header?

Язык: JavaScript (но не нужно быть программистом — есть готовые сниппеты)

Пример 1: Проверка статус-кода

javascript pm.test("Status code is 200", function () { pm.response.to.have.status(200); });

Пример 2: Проверка времени ответа

javascript pm.test("Response time is less than 500ms", function () { pm.expect(pm.response.responseTime).to.be.below(500); });

Пример 3: Проверка тела ответа

Ответ сервера:

json { "id": 123, "name": "Иван", "email": "ivan@mail.ru" }

Тест:

javascript pm.test("Response has required fields", function () { var jsonData = pm.response.json(); pm.expect(jsonData).to.have.property('id'); pm.expect(jsonData).to.have.property('name'); pm.expect(jsonData.name).to.eql('Иван'); });

Пример 4: Проверка массива

Ответ:

json [ {"id": 1, "name": "Иван"}, {"id": 2, "name": "Мария"} ]

Тест:

javascript pm.test("Array has 2 users", function () { var jsonData = pm.response.json(); pm.expect(jsonData).to.be.an('array'); pm.expect(jsonData.length).to.eql(2); });

Готовые сниппеты в Postman:

В табе "Tests" справа есть кнопки с готовыми шаблонами:

• Status code: Code is 200

• Response body: JSON value check

• Response time is less than 200ms

Как запустить автоматизированные тесты:

1. Создать коллекцию с запросами

2. Добавить тесты в каждый запрос (таб Tests)

3. Запустить коллекцию: Collection → Run

4. Postman выполнит все запросы и покажет результаты тестов

Вывод: Автоматизация в Postman — это просто. Даже без знания JavaScript можно использовать готовые сниппеты.

Вопрос 8: Что такое Pre-request Script и когда его использовать?

Почему спрашивают:

Pre-request Scripts — продвинутая функция. Если вы знаете, когда их использовать, вы не просто джун, а джун+.

Ответ:

Pre-request Script — это JavaScript-код, который выполняется до отправки запроса.

Зачем нужен:

1. Генерация динамических данных: timestamp, случайное число, UUID

2. Установка переменных: Перед запросом установить токен, который получили ранее

3. Подготовка данных: Создать хеш, подпись для авторизации

Пример 1: Генерация случайного email

Задача: При создании пользователя нужен уникальный email.

Pre-request Script:

javascript pm.environment.set("random_email", "user" + Math.random().toString(36).substring(7) + "@test.com");

Запрос:

POST /api/users Body: { "name": "Test User", "email": "{{random_email}}" }

Каждый раз будет генерироваться новый email: user7x2k9@test.com

Пример 2: Установка текущего времени

javascript pm.environment.set("timestamp", new Date().toISOString());

Использование:

json { "created_at": "{{timestamp}}" }

Пример 3: Получение токена перед запросом

Если токен хранится в переменной auth_token, но нужно проверить, не истек ли он:

javascript const token = pm.environment.get("auth_token"); if (!token) { // Если токена нет, отправить запрос на получение токена pm.sendRequest({ url: 'https://api.example.com/auth/login', method: 'POST', body: { mode: 'raw', raw: JSON.stringify({ username: 'test', password: 'test123' }) } }, function (err, res) { pm.environment.set("auth_token", res.json().token); }); }

Разница между Pre-request Script и Tests:

Вывод: Pre-request Scripts — для подготовки запроса. Tests — для проверки ответа.

Вопрос 9: Как проверить response body в Postman?

Почему спрашивают:

Проверка ответа — основная задача тестирования API. Если вы не знаете, как проверить response body, вы не сможете найти баги.

Ответ:

Response body — это данные, которые вернул сервер.

Форматы:

• JSON (99% случаев в REST API)

• XML

• HTML

• Plain text

Что проверять:

1. Наличие полей: Есть ли поле id, name, email?

2. Значения полей: name равно "Иван"?

3. Типы данных: id — число, name — строка?

4. Структура: Массив или объект?

5. Размер: Массив содержит 10 элементов?

Пример response:

json { "id": 123, "name": "Иван", "email": "ivan@mail.ru", "age": 25, "is_active": true }

Тесты:

```javascript pm.test("Response has all required fields", function () { var jsonData = pm.response.json();

// Проверка наличия полей
pm.expect(jsonData).to.have.property('id');
pm.expect(jsonData).to.have.property('name');
pm.expect(jsonData).to.have.property('email');

// Проверка значений
pm.expect(jsonData.name).to.eql('Иван');
pm.expect(jsonData.age).to.be.a('number');
pm.expect(jsonData.age).to.be.above(0);
pm.expect(jsonData.is_active).to.be.true;

// Проверка email (регулярное выражение)
pm.expect(jsonData.email).to.match(/^[^\s@]+@[^\s@]+\.[^\s@]+$/);

}); ```

Проверка массива:

Response:

json [ {"id": 1, "name": "Иван"}, {"id": 2, "name": "Мария"}, {"id": 3, "name": "Петр"} ]

Тест:

javascript pm.test("Array contains 3 users", function () { var jsonData = pm.response.json(); pm.expect(jsonData).to.be.an('array'); pm.expect(jsonData.length).to.eql(3); pm.expect(jsonData[0].name).to.eql('Иван'); });

Проверка вложенных объектов:

Response:

json { "user": { "id": 123, "profile": { "firstName": "Иван", "lastName": "Иванов" } } }

Тест:

javascript pm.test("Nested object check", function () { var jsonData = pm.response.json(); pm.expect(jsonData.user.profile.firstName).to.eql('Иван'); });

Вывод: Тестирование response body — это основа API-тестирования. Без этого навыка вы не сможете проверить, правильно ли работает API.

Вопрос 10: В чем разница между PUT и PATCH?

Почему спрашивают:

Многие джуны путают PUT и PATCH. Это частая ошибка, которая показывает, что вы не понимаете REST API.

Ответ:

PUT и PATCH — оба используются для обновления ресурса. Но работают по-разному.

PUT — полная замена ресурса.

PATCH — частичное обновление ресурса.

Пример:

Исходный ресурс (пользователь):

json { "id": 123, "name": "Иван", "email": "ivan@mail.ru", "age": 25 }

Задача: Изменить только email.

Вариант 1: PUT (полная замена)

PUT /api/users/123 Body: { "name": "Иван", "email": "new_email@mail.ru", "age": 25 }

Нужно отправить все поля, даже те, которые не меняются.

Если отправите только:

json { "email": "new_email@mail.ru" }

То name и age будут удалены (или установлены в null).

Вариант 2: PATCH (частичное обновление)

PATCH /api/users/123 Body: { "email": "new_email@mail.ru" }

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

Сравнение:

Идемпотентность:

• PUT: Отправили 10 раз → результат один и тот же (ресурс в том же состоянии).

• PATCH: Зависит от реализации. Может быть идемпотентным, может нет.

Когда использовать PUT:

• Когда нужно обновить весь ресурс

• Когда API требует все поля

Когда использовать PATCH:

• Когда нужно обновить один или несколько полей

• Когда не хотите отправлять все данные

Вывод: PUT = замена всего объекта. PATCH = изменение части объекта.

Вопрос 11: Что такое Authorization и как ее тестировать в Postman?

Почему спрашивают:

Большинство API требуют авторизации. Если вы не знаете, как работать с авторизацией, вы не сможете протестировать защищенные эндпоинты.

Ответ:

Authorization (Авторизация) — это проверка, имеет ли пользователь право доступа к ресурсу.

Типы авторизации в API:

Самый популярный: Bearer Token

Как работает:

1. Отправляете логин и пароль на /auth/login

2. Сервер возвращает токен (обычно JWT)

3. Используете токен во всех последующих запросах

Пример:

Шаг 1: Получить токен

``` POST /api/auth/login Body: { "username": "test", "password": "test123" }

Response: { "token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..." } ```

Шаг 2: Сохранить токен в переменную

В табе Tests:

javascript pm.environment.set("auth_token", pm.response.json().token);

Шаг 3: Использовать токен в запросах

В Postman:

1. Перейти на таб Authorization

2. Выбрать тип: Bearer Token

3. Вставить: {{auth_token}}

Или вручную в Headers:

Authorization: Bearer {{auth_token}}

Что тестировать:

1. Без токена → 401 Unauthorized

GET /api/users (без Authorization header) → Ожидаем: 401 Unauthorized

1. С неверным токеном → 401 Unauthorized

GET /api/users Authorization: Bearer wrong_token → Ожидаем: 401 Unauthorized

1. С валидным токеном → 200 OK

GET /api/users Authorization: Bearer {{auth_token}} → Ожидаем: 200 OK + данные

1. С истекшим токеном → 401 Unauthorized

(Токен, который истек) → Ожидаем: 401 Unauthorized

Basic Auth:

Логин и пароль отправляются в каждом запросе (в base64).

В Postman:

1. Таб Authorization → Type: Basic Auth

2. Ввести Username и Password

3. Postman автоматически создаст header: Authorization: Basic dXNlcjpwYXNz

OAuth 2.0:

Сложный протокол. Postman поддерживает OAuth 2.0:

1. Таб Authorization → Type: OAuth 2.0

2. Ввести параметры: Auth URL, Access Token URL, Client ID, Client Secret

3. Нажать "Get New Access Token"

4. Postman выполнит OAuth-флоу и получит токен

Вывод: Авторизация — обязательная часть API-тестирования. Без нее большинство эндпоинтов недоступны.

Вопрос 12: Как запустить коллекцию Postman через командную строку (Newman)?

Почему спрашивают:

Newman — это CLI (Command Line Interface) для Postman. Используется для запуска тестов в CI/CD. Если вы знаете Newman, вы понимаете автоматизацию.

Ответ:

Newman — это инструмент командной строки для запуска коллекций Postman.

Зачем нужен:

1. CI/CD интеграция: Запускать тесты при каждом коммите

2. Автоматизация: Запускать тесты по расписанию (cron)

3. Отчеты: Генерировать HTML-отчеты о результатах тестов

Установка Newman:

bash npm install -g newman

Как запустить коллекцию:

1. Экспортировать коллекцию из Postman:

2. Открыть коллекцию → три точки → Export

3. Сохранить как collection.json

4. Экспортировать окружение (если используете переменные):

5. Environment → три точки → Export

6. Сохранить как environment.json

7. Запустить через Newman:

bash newman run collection.json -e environment.json

Пример вывода:

``` → User API Tests GET Get all users ✓ Status code is 200 ✓ Response time is less than 500ms

POST Create user ✓ Status code is 201 ✓ Response has user ID

Генерация HTML-отчета:

bash newman run collection.json -e environment.json -r html

Создаст файл newman/report.html с красивым отчетом.

Интеграция с CI/CD (GitHub Actions):

yaml name: API Tests on: [push] jobs: test: runs-on: ubuntu-latest steps: - uses: actions/checkout@v2 - name: Install Newman run: npm install -g newman - name: Run Postman tests run: newman run collection.json -e environment.json

Вывод: Newman — это Postman в командной строке. Нужен для автоматизации и CI/CD.

Как подготовиться к собеседованию за 1-2 недели

У вас собеседование через 2 недели. Как подготовиться?

План подготовки (2 недели)

Неделя 1: Теория и базовые навыки

День 1-2: Изучить теорию

• Что такое API, REST API

• HTTP-методы (GET, POST, PUT, PATCH, DELETE)

• HTTP статус-коды (200, 201, 400, 401, 404, 500)

• JSON vs XML

Ресурсы:

• testengineer.ru/api-testing — на русском

• YouTube: "API тестирование для начинающих"

• Habr: статьи про REST API

День 3-5: Практика в Postman

• Установить Postman

• Создать первый запрос (GET)

• Создать коллекцию

• Работа с переменными (Environment Variables)

Практика:

Используйте публичные API для практики:

• JSONPlaceholder: https://jsonplaceholder.typicode.com (fake REST API)

• ReqRes: https://reqres.in (fake API для тестирования)

Задания:

1. GET-запрос: получить список пользователей

2. POST-запрос: создать пользователя

3. PUT-запрос: обновить пользователя

4. DELETE-запрос: удалить пользователя

День 6-7: Автоматизация тестов

• Писать тесты в табе Tests

• Проверка статус-кода

• Проверка response body

• Использование Pre-request Scripts

Неделя 2: Практика и подготовка к собеседованию

День 8-10: Продвинутые темы

• Authorization (Bearer Token, Basic Auth)

• Работа с Collections

• Newman (запуск через командную строку)

День 11-12: Практические задания

Создать полноценную коллекцию тестов для API:

1. Авторизация (получение токена)

2. CRUD операции (Create, Read, Update, Delete)

3. Автоматизированные тесты

4. Экспорт коллекции

День 13-14: Повторение и подготовка ответов

• Повторить 12 вопросов из этой статьи

• Подготовить ответы своими словами

• Попрактиковаться вслух (как на собеседовании)

Ресурсы для подготовки

Курсы (бесплатные):

• Stepik: "Тестирование REST API в Postman" — курс на русском

• YouTube: "Postman для начинающих QA" — видеоуроки

Документация:

• Официальная документация Postman: https://learning.postman.com

Практика:

• JSONPlaceholder: https://jsonplaceholder.typicode.com

• ReqRes: https://reqres.in

• HTTPBin: https://httpbin.org

Вывод: 2 недели достаточно, чтобы подготовиться к собеседованию на junior QA с знанием Postman.

Частые ошибки джунов на собеседованиях

Разберем типичные ошибки, которые делают junior QA.

Ошибка 1: Не понимают разницу между GET и POST

Проблема:

Интервьюер: «В чем разница между GET и POST?»

Джун: «GET получает данные, POST отправляет данные.»

Что не так:

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

Правильный ответ:

«GET используется для получения данных. Он идемпотентный, безопасный, данные передаются в URL, можно кэшировать. POST используется для создания ресурса. Не идемпотентный, данные передаются в теле запроса, не кэшируется.»

Ошибка 2: Не знают статус-коды

Проблема:

Интервьюер: «Какой статус-код вернет сервер при успешном создании пользователя?»

Джун: «200 OK.»

Что не так:

200 OK — это для GET. Для POST (создание) должен быть 201 Created.

Правильный ответ:

«201 Created — ресурс успешно создан. 200 OK — для GET-запросов.»

Ошибка 3: Не умеют работать с переменными

Проблема:

Интервьюер просит: «Создайте коллекцию, которая работает на dev и prod окружениях.»

Джун создает 2 коллекции (одну для dev, одну для prod) вместо использования Environment Variables.

Правильный подход:

Создать одну коллекцию, два окружения (Dev, Prod), использовать {{base_url}}.

Ошибка 4: Не проверяют response body

Проблема:

Джун отправляет запрос, видит статус 200, говорит: «Работает!»

Но не проверяет, что в ответе правильные данные.

Правильный подход:

Проверить:

• Статус-код

• Наличие нужных полей

• Правильность значений

• Структуру ответа

Ошибка 5: Не понимают, зачем нужна автоматизация

Проблема:

Интервьюер: «Зачем автоматизировать тесты в Postman?»

Джун: «Чтобы быстрее тестировать.»

Правильный ответ:

«Автоматизация позволяет:

1. Запускать тесты при каждом изменении кода (CI/CD)

2. Проверять большой объем данных

3. Регрессионное тестирование (убедиться, что старые функции работают)

4. Экономить время на ручном тестировании»

Таблица: Ошибки и как их избежать

Практическое задание на собеседовании

На собеседовании часто просят выполнить практическое задание.

Типичное задание

Задача:

«Вот API: https://reqres.in. Протестируйте его в Postman. Создайте коллекцию с автоматизированными тестами.»

Что нужно сделать:

1. Изучить документацию API: https://reqres.in

2. Создать коллекцию с запросами:

3. GET /api/users — получить список пользователей

4. GET /api/users/2 — получить конкретного пользователя

5. POST /api/users — создать пользователя

6. PUT /api/users/2 — обновить пользователя

7. DELETE /api/users/2 — удалить пользователя

8. Добавить автоматизированные тесты:

9. Проверка статус-кода

10. Проверка response body

11. Проверка времени ответа

12. Использовать переменные:

13. base_url: https://reqres.in

14. Сохранить user_id после создания пользователя

15. Экспортировать коллекцию и отправить интервьюеру

Пример решения

Запрос 1: GET список пользователей

GET {{base_url}}/api/users?page=2

Tests:

```javascript pm.test("Status code is 200", function () { pm.response.to.have.status(200); });

pm.test("Response has data array", function () { var jsonData = pm.response.json(); pm.expect(jsonData.data).to.be.an('array'); pm.expect(jsonData.data.length).to.be.above(0); }); ```

Запрос 2: POST создать пользователя

POST {{base_url}}/api/users Body: { "name": "Иван", "job": "QA Engineer" }

Tests:

```javascript pm.test("Status code is 201", function () { pm.response.to.have.status(201); });

pm.test("Response has id", function () { var jsonData = pm.response.json(); pm.expect(jsonData).to.have.property('id'); pm.environment.set("user_id", jsonData.id); // Сохраняем ID }); ```

Запрос 3: DELETE удалить пользователя

DELETE {{base_url}}/api/users/{{user_id}}

Tests:

javascript pm.test("Status code is 204", function () { pm.response.to.have.status(204); });

Что оценивает интервьюер:

• Умеете ли создавать запросы

• Используете ли переменные

• Пишете ли автоматизированные тесты

• Проверяете ли корректность данных

• Организуете ли коллекцию логично

Реальные истории: успехи и провалы

История 1: Провал из-за незнания базовых вещей (Алексей, Москва)

Ситуация:

Алексей прошел курсы по тестированию, знал теорию, но Postman открывал 2 раза.

Задание:

«Отправьте GET-запрос на /users и проверьте, что статус-код 200.»

Что произошло:

Алексей открыл Postman, но не знал, куда вписывать URL. Начал искать в меню. Интервьюер подождал 5 минут и сказал: «Спасибо, на этом всё.»

Урок: Практика важнее теории. Откройте Postman и поработайте с ним хотя бы 2-3 часа.

История 2: Успех благодаря подготовке (Мария, Санкт-Петербург)

Ситуация:

Мария готовилась 2 недели, решила 50+ запросов на JSONPlaceholder, создала 5 коллекций.

Задание:

«Протестируйте вот этот API. Создайте коллекцию с автоматизированными тестами.»

Что произошло:

Мария за 30 минут создала коллекцию с 5 запросами, добавила тесты, использовала переменные. Интервьюер был впечатлен. Получила оффер.

Урок: 2 недели практики = оффер.

История 3: Провал из-за незнания статус-кодов (Дмитрий, Новосибирск)

Ситуация:

Интервьюер: «Какой статус-код вернет сервер при успешном DELETE?»

Дмитрий: «200 OK.»

Интервьюер: «А еще варианты?»

Дмитрий: «...»

Правильный ответ: 204 No Content (или 200 OK с телом ответа).

Урок: Выучите базовые статус-коды. Это спрашивают на 100% собеседований.

Чек-лист подготовки к собеседованию

Теория (обязательно знать)

• [ ] Что такое API, REST API

• [ ] HTTP-методы: GET, POST, PUT, PATCH, DELETE

• [ ] Разница между PUT и PATCH

• [ ] HTTP статус-коды: 200, 201, 204, 400, 401, 403, 404, 500

• [ ] JSON: структура, типы данных

• [ ] Разница между JSON и XML

• [ ] Что такое идемпотентность

Postman (практические навыки)

• [ ] Создать GET-запрос

• [ ] Создать POST-запрос с телом (JSON)

• [ ] Создать PUT/PATCH-запрос

• [ ] Создать DELETE-запрос

• [ ] Создать коллекцию

• [ ] Добавить запросы в коллекцию

• [ ] Создать Environment с переменными

• [ ] Использовать переменные в запросах ({{variable}})

• [ ] Написать тест на проверку статус-кода

• [ ] Написать тест на проверку response body

• [ ] Использовать Pre-request Script

• [ ] Работать с Authorization (Bearer Token)

• [ ] Запустить коллекцию через Runner

• [ ] Экспортировать коллекцию

Дополнительно (плюс в карму)

• [ ] Знать, что такое Newman

• [ ] Понимать CI/CD интеграцию

• [ ] Знать разницу между SOAP и REST

• [ ] Понимать OAuth 2.0

Заключение: знание Postman = оффер

Вернемся к истории из начала.

Алексей провалил собеседование, потому что не открывал Postman до собеседования.

Что Алексей сделал после?

1. Установил Postman

2. Прошел курс на Stepik (10 часов)

3. Потренировался на JSONPlaceholder (создал 10 коллекций)

4. Пересдал собеседование в другой компании

5. Получил оффер

Мораль:

API-тестирование и Postman — это обязательные навыки для junior QA в 2025 году.

Без них вас не возьмут. С ними — у вас есть все шансы.

Хорошая новость:

Postman — это самый простой инструмент для изучения. 1-2 недели практики достаточно, чтобы уверенно пройти собеседование.

Что нужно сделать:

1. Выучить 12 вопросов из этой статьи

2. Потренироваться на публичных API (JSONPlaceholder, ReqRes)

3. Создать 5-10 коллекций с автоматизированными тестами

4. Понять базовые концепции: HTTP-методы, статус-коды, переменные

Финальные рекомендации:

Для тех, кто только начинает:

• Не бойтесь Postman — он простой

• Практикуйтесь каждый день (30 минут достаточно)

• Используйте публичные API для тренировки

Для тех, кто идет на собеседование:

• Повторите 12 вопросов

• Откройте Postman и отправьте хотя бы 10 разных запросов

• Подготовьте примеры коллекций, которые создавали

Для тех, кто хочет выделиться:

• Изучите Newman

• Поймите CI/CD интеграцию

• Создайте публичную коллекцию на Postman и поделитесь в резюме

API-тестирование — это будущее QA. Postman — это ваш билет в это будущее.

Практикуйтесь. Учитесь. Получайте офферы.

Удачи на собеседованиях!

А лучшие вакансии для тестировщиков ищите на hirehi.ru