CheckcraftКак оформить баг-репорт API и передать ошибку разработчику
Ошибка видна у тестировщика, а у разработчика запрос работает. Для воспроизведения нужны те же условия, понятное ожидание и фактические данные. Соберём такое описание на небольшом примере.
Начать с проверяемого расхождения
Заголовок «API не работает» не показывает, что проверять. Для учебного примера подойдёт «Поле status содержит ERROR вместо ожидаемого OK». Укажите, откуда взято ожидание. Ниже используется готовый тест-кейс Checkcraft с двумя JSON. Это упражнение на проверку ответа, а не подтверждение сбоя реального сервиса.
Сохранить запрос и условия воспроизведения
Для своей ошибки запишите метод, адрес тестового окружения, параметры, тело запроса и версию сервиса. Добавьте необходимые предварительные условия и роль тестового пользователя. Если переносите запрос через cURL или коллекцию Postman, передавайте обезличенную копию. Получатель должен подставить собственные разрешённые учётные данные.
Показать ожидаемый и фактический ответ
В учебном правиле status должен быть строкой OK. Ответ с ERROR нарушает это правило, хотя сам JSON корректен. Приложите оба значения и путь поля. Если в своей системе получили HTTP 200, запишите его отдельно от содержимого ответа. Не добавляйте статус, длительность или traceId, которых вы не измеряли.
{"status":"ERROR","amount":100}Повторить учебную ошибку в Checkcraft
В редакторе тест-кейса импортируйте файл first-check.testcase.json по ссылке ниже. Откройте тест и вставьте правильный JSON через «Вставить данные для анализа», затем запустите тест-кейс. Повторите с JSON с ошибкой, сохранив правило. Ожидается, что вариант OK проходит, а ERROR даёт расхождение. Такая пара помогает проверить само правило до работы с чужим API.
Приложить отчёт и данные для повторного запуска
После HTTP-прогона в Checkcraft откройте «Анализ результатов» и сохраните HTML или TXT. Подробный отчёт помогает увидеть правило рядом с данными. Для другого тестировщика приложите экспорт тест-кейса и обезличенный ответ. Сам файл тест-кейса не заменяет запрос, окружение и доступы. Если проверка зависит от логов или БД, укажите связь с конкретной операцией и доступный получателю способ проверки.
Передать запрос без токенов и паролей
Проверьте Authorization, Cookie, API-ключи в URL, переменные окружения, тело ответа и вложенный отчёт. Замените секреты понятными заглушками. Если меняете идентификатор заказа, используйте одну замену в запросе, ответе и описании. Маскировка поля в интерфейсе не гарантирует, что значение исчезло из экспортированного файла. Откройте подготовленные вложения и проверьте их содержимое перед отправкой.
Скопировать шаблон баг-репорта API
Заполните шаблон своими наблюдениями. Если время, версия или идентификатор неизвестны, так и укажите. Для HTTP-сценария опишите фактическую отправку запроса. Для упражнения с готовым JSON укажите вставку данных в редактор, чтобы получатель не искал несуществующий сервер.
Название
[Поле и наблюдаемое расхождение]
Окружение и версия
[Тестовый стенд, версия сервиса, роль пользователя]
Исходные условия
[Подготовленные данные и требование]
Запрос или учебный файл
[Метод и адрес, безопасный cURL или имя JSON]
Воспроизведение
[Выполненные действия в их порядке]
Ожидаемый результат
[Путь поля, тип, значение и основание]
Фактический результат
[Ответ, несовпавшее поле, измеренный HTTP-статус]
Связь с операцией
[Время с часовым поясом, requestId или traceId при наличии]
Вложения
[Обезличенные данные, тест-кейс и отчёт]
Повтор после исправления
[Версия и результат повторения тех же шагов]Перепроверить после исправления
Повторите исходный запрос и прежние правила в сопоставимых условиях. Сохраните новый результат рядом с предыдущим. Postman и тесты в коде тоже позволяют оформить воспроизводимый дефект, а AI может помочь с черновиком описания. Фактический ответ и требование всё равно нужно сверить. На учебных файлах ниже можно самостоятельно проверить, хватает ли данных для повторения ошибки.
Повторить на готовых данных
Быстрый опыт ниже выполняется в редакторе тест-кейса. На снимках показан подробный отчёт из HTTP-прогона или Log-прогона. Для HTTP-прогона верните учебный JSON или XML из локального мока, выполните импортированный тест-кейс и откройте «Анализ результатов», «Детально», «Со структурами». Для Log-прогона загрузите учебные данные в источник логов, включите «Без запроса», выполните проверку и откройте «Детально», «Подробно».
Это существующие учебные данные и полученные при подготовке примеров текстовые отчёты. Они не являются кейсом внедрения у клиента.
Начните с примера по ссылкам и сопоставьте результат с требованием своей проверки.