Назад

Выполнение проверок · Средняя

Проверить API-контракты

Убедиться, что frontend и backend одинаково понимают структуру запросов, ответов, ошибок и ограничений.

Выполнение проверок: визуальный контекст этапа
Аудиопересказ пунктаПолная версия материала для прослушивания
Прослушано 0%
Скачать

Быстро понять за 2 минуты

Убедиться, что frontend и backend одинаково понимают структуру запросов, ответов, ошибок и ограничений. На выходе: критичные endpoint проверены по контракту.

Главная пользаПроверка API-контрактов снижает риск ситуаций, когда интерфейс ломается не из-за логики, а из-за несовпадения формата данных или обработки ошибок.
Первое действиеСравните фактический ответ API с документацией или OpenAPI-схемой.
Готово, когдаКритичные endpoint проверены по контракту.

Контекст

Пункт относится к этапу «Выполнение проверок». Его задача — превратить рабочее действие в проверяемый результат. Он нужен до передачи результата разработчикам, менеджеру и владельцу продукта: иначе команда рискует проверять только успешный ответ 200.

ЦельПроверка API-контрактов снижает риск ситуаций, когда интерфейс ломается не из-за логики, а из-за несовпадения формата данных или обработки ошибок.
ДействиеСравните фактический ответ API с документацией или OpenAPI-схемой.
ПроверкаКритичные endpoint проверены по контракту.

Что это дает

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

Как выполнить

  1. Сравните фактический ответ API с документацией или OpenAPI-схемой.
  2. Проверьте обязательные поля, типы данных, коды ошибок, пустые ответы и права доступа.
  3. Зафиксируйте расхождения как дефекты или вопросы к контракту.

Критерии приемки

  • Критичные endpoint проверены по контракту.
  • Ошибки и пустые состояния возвращаются в ожидаемом формате.
  • Расхождения между документацией и фактом исправлены или согласованы.

Типичные ошибки

  • Проверять только успешный ответ 200.
  • Игнорировать ошибки авторизации и валидации.
  • Не проверять совместимость после изменения API.

Инструменты

PostmanOpenAPISwaggerDevToolscontract testing

Рабочий артефакт

Test run

Отчет проверки API-контрактов

Пример для подготовки функциональности к релизу: специалист начинает с действия «Сравните фактический ответ API с документацией или OpenAPI-схемой». Затем фиксирует результат в рабочем артефакте и передает его команде. Пункт считается выполненным только когда выполнено условие: «Критичные endpoint проверены по контракту».

  • Passed
  • Failed
  • Blocked
  • Retest

Контроль качества

Артефакт

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

Метрика проверки

Критичные endpoint проверены по контракту.

Когда пересматривать

После релизов, изменения требований, новых дефектов, ретестов и обновления критериев приемки.

Что передать дальше

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

Перед отметкой выполнено: Критичные endpoint проверены по контракту.

Как применять

Начинайте с риска для пользователя и продукта. Затем проверьте воспроизводимость, окружение, тестовые данные и доказательства. Хороший QA-пункт отвечает на три вопроса: какой риск закрываем, как воспроизводим результат и по каким критериям считаем проверку завершенной.

Режим обучения

Тест по теме

Проверка понимания

Ответьте на вопросы по материалу и получите итоговый отчет: что понято хорошо, а что стоит перечитать.

0/4ответов выбрано
1. Какой главный результат должен дать пункт «Проверить API-контракты»?
2. С какого действия логично начать выполнение?
3. Как понять, что тема действительно закрыта?
4. Какой ошибки стоит избегать в этой теме?
Материал подготовлен командойAriol.by