Воспроизведение багов и баг-репорты

Баг-репорт из чата клиента редко похож на учебник: «форма не отправляется», скриншот без адресной строки, «иногда». Путь от такого сообщения до бага, который разработчик чинит за час, — работа QA. Codex ускоряет каждый шаг этого пути: читает логи, ищет код, проходит сценарий в браузере, пишет тест. Но порядок шагов задаёте вы.

Правило: сначала воспроизвести

Агенту нельзя начинать с исправления. Если он не воспроизвёл проблему, он починит то, что ему показалось, и уверенно отчитается. Порядок такой:

1. Воспроизвести на локальном стенде или в тестовом окружении.
2. Сократить шаги до минимального сценария.
3. Собрать доказательства.
4. Найти вероятную область кода.
5. Закрепить воспроизведение падающим тестом.
6. Оформить баг-репорт.

В статье OpenAI о harness engineering описан репозиторий, где агент по одному промпту воспроизводит баг, записывает видео, исправляет, проверяет исправление в запущенном приложении и записывает второе видео. Авторы оговариваются: такое поведение держится на инструментах и структуре конкретного репозитория и не переносится без сопоставимых вложений (Harness engineering). Для нас из этого важен принцип: доказательство «до» и «после» — часть работы, а не украшение.

Шаг 1–2. Воспроизведение с браузером

Баг из задачи (текст ниже). Используй браузер, стенд http://localhost:8001.
1. Попробуй воспроизвести по описанию. Если не получается — перечисли,
   какие условия могли отличаться (браузер, размер экрана, авторизация,
   данные, порядок действий), и проверь самые вероятные.
2. Когда воспроизведёшь — сократи шаги до минимума.
3. Не исправляй код. Ничего не отправляй больше трёх раз.

<текст из задачи в Kaiten>

Если баг не воспроизводится, это тоже результат: список проверенных условий экономит время следующему, кто возьмётся. Что делать с багами, которые проявляются «иногда», — в уроке «Нестабильные тесты: поиск причин».

Шаг 3. Доказательства

Хорошее доказательство однозначно указывает на проблему:

• консоль браузера — ошибка JavaScript в момент клика;
• сетевой запрос — что ушло на сервер и что вернулось, с кодом ответа;
• скриншот с видимым адресом и состоянием;
• строка лога сервера с временем, совпадающим со временем шага.

Во встроенном браузере ChatGPT desktop app консоль и сеть доступны в режиме разработчика, в Playwright MCP — через инструменты для консоли и сетевых запросов (точные имена — в README). Логи Laravel и OctoberCMS лежат в storage/logs.

Логи удобно отдавать агенту без интерактивной сессии. Если передать codex exec промпт и одновременно направить данные в stdin, они станут контекстом задачи (Non-interactive mode):

tail -n 500 storage/logs/system.log | codex exec \
  "Найди ошибки около 14:32 по московскому времени, связанные с отправкой формы заявки. \
   Для каждой: время, класс исключения, файл и строка, одно предложение о вероятной причине."

По умолчанию codex exec работает в песочнице только для чтения, так что такой разбор ничего не меняет в проекте.

Шаг 4. Где искать в коде

Инженеры OpenAI, по их гайду, вставляют в Codex стек-трейс и спрашивают, где живёт соответствующая логика, а после исправления — где ещё в коде может прятаться похожий баг (How OpenAI uses Codex). Второй вопрос особенно ценен для QA: он даёт список мест для регрессионной проверки.

Вот стек-трейс и минимальные шаги. Найди код, который отвечает за этот
сценарий, и объясни, почему возникает ошибка — как гипотезу, со ссылками
на строки. Затем найди другие места в проекте с тем же паттерном.
Код не меняй.

Шаг 5. Падающий тест

Воспроизведение, записанное в виде теста, — лучший баг-репорт: разработчик запускает одну команду и видит проблему. Попросите агента написать e2e- или API-тест, который сейчас падает именно из-за бага, и приложить вывод прогона. Проверьте, что тест падает по правильной причине: сообщение об ошибке должно говорить о баге, а не о сломанном локаторе или таймауте.

Дальше тест живёт в регресс-наборе: когда баг исправят, он позеленеет и будет охранять от повторения. Как вести исправление по этому тесту — в уроке «Баг: воспроизвести, починить, закрепить тестом».

Шаг 6. Баг-репорт

Шаблон удобно держать в навыке (см. урок «Настройка Codex под тестирование»), тогда все репорты в команде выглядят одинаково. Главное требование к тексту агента — разделять факты и гипотезы:

**Форма заявки на /contacts не отправляется, если телефон введён с пробелами**

Окружение: localhost:8001, Chromium, десктоп и мобильный размер.
Частота: 5 из 5.

Шаги:
1. Открыть /contacts.
2. Ввести имя «Тест», телефон «+7 999 123 45 67».
3. Нажать «Отправить».

Ожидаемо: заявка отправлена, показано сообщение об успехе.
Фактически: кнопка неактивна 1 секунду, затем ничего не происходит.

Доказательства: POST /api/leads → 500, в логе — исключение валидации
телефона (строка лога приложена), тест tests/e2e/lead-phone.spec.ts падает.

Гипотеза (не проверено): нормализация телефона не убирает пробелы.

Серьёзность и приоритет ставите вы — агент не знает, сколько заявок в день идёт через эту форму. И проверьте перед отправкой, что в репорт не попали токены, пароли и персональные данные из логов.

Мобильные приложения

Для нативных приложений браузер не поможет, но логи и крэш-репорты — да. Выгрузите отчёт о падении или лог устройства в файл и отдайте агенту вместе с исходниками приложения: он сопоставит стек с кодом и предложит минимальный сценарий. Скриншот экрана с ошибкой прикладывается к промпту как картинка (codex -i screen.png).