API, или Application Programming Interface, - это интерфейс, через который одна программа обращается к другой по заранее согласованным правилам. Проще говоря, API определяет, что можно запросить у системы, какие данные нужно передать, что вернётся в ответ и как будут выглядеть ошибки.
Для QA это один из базовых слоёв продукта. Пользователь видит экран, кнопку и форму, но реальная логика обычно живёт глубже: в запросах, проверках прав, расчётах, интеграциях и изменении данных. Поэтому тестировщик, который не понимает API, почти всегда видит только поверхность.
Как это работает
В типовом сценарии клиент отправляет запрос к сервису, а сервис возвращает ответ. Клиентом может быть браузер, мобильное приложение, другой сервис или внешний партнёр. Сервис принимает запрос, валидирует данные, проверяет права, выполняет бизнес-логику и отдаёт результат.
- →Куда идёт запрос: endpoint или resource path.
- →Что именно происходит: method, например GET, POST, PATCH или DELETE.
- →Что передаётся вместе с запросом: headers, параметры, body, авторизация.
- →Что приходит назад: статус, headers, данные или описание ошибки.
Важно не сводить API к "URL и JSON". Это контракт взаимодействия между системами. Пока контракт соблюдается, внутренняя реализация сервиса может меняться.
Что важно QA
API особенно ценно тем, что позволяет проверять систему без лишнего визуального слоя. Это делает тестирование быстрее, точнее и полезнее для расследования.
- →Через API видно, какие данные реально ушли и что реально вернулось.
- →Через API проще проверять бизнес-логику, чем через UI.
- →Через API удобно строить негативные сценарии и edge cases.
- →Через API легче понять, проблема в интерфейсе, backend, авторизации, данных или интеграции.
Хорошая API-проверка - это не просто "дёрнуть эндпоинт". QA должен понимать, какие поля обязательны, какие роли допускаются, как сервис должен реагировать на невалидный ввод, какие side effects вызывает запрос и как ответ связан с тем, что потом увидит пользователь.
Где API встречается в продукте
Почти везде, где есть обмен данными между частями системы.
- →Web и mobile используют API, чтобы получать и изменять данные.
- →Внутренние сервисы используют API, чтобы работать друг с другом.
- →Внешние интеграции используют API для платежей, доставки, antifraud, email, SMS и аналитики.
- →Автотесты и служебные скрипты часто работают с продуктом именно через API, а не через экран.
Для QA API — это не “продвинутая тема на потом”, а базовый рабочий инструмент. Чем раньше ты начинаешь мыслить через API, тем быстрее перестаёшь тестировать только поверхность продукта.
Что ещё почитать
- →Внутри базы: HTTP и HTTPS - чтобы понять transport-слой API-взаимодействия.
- →Внутри базы: Методы, статус-коды, заголовки - чтобы научиться читать запрос и ответ как QA.
- →Внешний материал: MDN API glossary - короткое и точное определение API без лишней воды.
Если коротко, API для QA - это язык, на котором продукт разговаривает между своими частями. Как только тестировщик начинает видеть этот слой, качество его проверок резко растёт: он понимает не только что сломалось, но и где именно это произошло.