Интересно ли заниматься тестированием API без работы с UI

Что проверяют

Совпадают ли ваши ожидания с реальной работой: в команде, где UI нет или он внутренний, тестировщик весь день смотрит на запросы, ответы и логи. И есть ли за словом «интересно» понимание предмета. Следом обычно просят рассказать, как вы протестируете конкретный метод, например создание заказа.

Как отвечать

Сначала честный ответ про интерес, потом доказательство, что вы понимаете, чем эта работа наполнена:

• контракт: статус-коды, схема ответа по OpenAPI или JSON Schema, обязательные поля и типы;
• бизнес-логика: расчёты, переходы статусов, права разных ролей, цепочки запросов (создал, прочитал, изменил, удалил);
• негативные сценарии: невалидные данные, запрос без токена, чужой ресурс, граничные значения, повторная отправка и идемпотентность;
• инструменты: Postman или Bruno для ручной работы, Newman для запуска коллекций в CI, для автотестов REST Assured на Java или pytest с requests/httpx на Python, WireMock для заглушек внешних сервисов, Pact для контрактных тестов;
• окружение: логи, запросы в базу для проверки записанного, очереди вроде Kafka, если сервис общается событиями.

Добавьте, почему вам это нравится по-настоящему: API-тесты быстрые и стабильные, баг ловится ближе к причине, а не через три слоя интерфейса. Приведите пример бага из практики, который UI бы не показал, например доступ к чужому объекту по подменённому идентификатору. Если опыта мало, скажите, что пробовали на учебном API, и назовите, что уже умеете.

Где спотыкаются

Отвечают «да, интересно» и больше ничего. Без конкретики это звучит как согласие на любую работу.

Сводят тестирование API к проверке, что пришёл код 200. Интервьюер спросит про тело ответа, состояние в базе и обработку ошибок, и ответ рассыплется.

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