Ответ.

Ручное тестирование API — это процесс проверки работы программного интерфейса приложения без использования автоматизации, посредством специализированных инструментов, таких как Postman, Swagger или curl.

История вопроса

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

Проблема

Основные трудности связаны с:

необходимостью точного понимания структуры входных и выходных данных (JSON, XML и др.)
сложностью воспроизведения сложных сценариев (аутентификация, зависимость от состояния системы)
риском пропустить скрытые баги, неочевидные через UI

Решение

Успешное тестирование требует:

внимательной работы с документацией API
создания наборов ручных запросов, покрывающих разные параметры и сценарии ошибок
тестирования как позитивных, так и негативных сценариев (валидация данных, проверка авторизаций)

Ключевые особенности:

Возможность быстро проверить новый или изменённый эндпоинт без ожидания автоматизированных тестов
Гибкость в анализе аномалий и ошибок, когда результат неочевиден
Визуальный контроль над всеми стадиями запроса и ответа

Вопросы с подвохом.

Можно ли для ручного тестирования API использовать только UI, без инструментов типа Postman?

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

Достаточно ли отправить только один корректный запрос для проверки работы API-эндпоинта?

Нет, важно тестировать не только валидные запросы, но и все граничные, некорректные и редкие кейсы, иначе баги не будут найдены.

Нужно ли тестировать негативные сценарии отдельно или это лишняя работа?

Обязательно нужно. Важно убеждаться, что система корректно обрабатывает ошибки и отклоняет некорректные запросы, иначе безопасность и стабильность окажутся под угрозой.

Типовые ошибки и анти-паттерны

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

Пример из жизни

Негативный кейс

Тестировщик проверяет только успешный POST-запрос к API "создать пользователя" — отправляет корректный JSON, получает 200 OK, считает тест оконченным.

Плюсы:

Быстрая проверка основного сценария

Минусы:

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

Позитивный кейс

Тестировщик системно проверяет API "создать пользователя":

успех для валидного запроса
ошибки при пропуске обязательных параметров
ошибку при повторном создании
проверяет разные коды HTTP, сообщения об ошибках, валидацию email