Как составить баг-репорт с помощью ИИ

Как составить баг-репорт с помощью ИИ: соберите наблюдения об одной ошибке, передайте модели окружение, предусловия, шаги, ожидаемый и фактический результат, повторяемость и приложения, затем вручную сверьте черновик с исходником. ИИ оформляет ваши данные и держит структуру; причину дефекта и результат исправления он не устанавливает.

Назначение документа и его границы

Итоговый документ описывает одну наблюдаемую ошибку и передаёт её разработчику в воспроизводимом виде. В руководстве BrowserStack баг-репорт определён как документ, который создают в ходе тестирования, чтобы выявить, описать и отследить дефекты приложения. Там же сказано, что разработчики предпочитают проверять такой отчёт, поскольку он даёт сводку недостатков, источников, решений и ожидаемого вывода. Практический вывод для автора: отчёт читают, чтобы повторить проблему и понять её, поэтому данные должны быть проверяемыми.

Границы начинаются там, где заканчиваются наблюдения. Причина дефекта, список затронутых браузеров, масштаб потерь данных и результат будущего исправления — это отдельные утверждения, для которых нужны собственные доказательства. В документации MDN сказано: прежде чем заводить баг браузера, следует подтвердить, что проблема действительно в браузере, и исключить другие варианты — ваш код, документацию, спецификацию. Тот же принцип работает для любого продукта: сначала сузьте источник, потом пишите.

BrowserStack отмечает, что создание подробного отчёта требует исследования, анализа и планирования. Это объясняет, зачем в процессе участвует ИИ: он берёт на себя оформление, пока вы собираете факты. Разделение ролей простое. Вы отвечаете за наблюдения и их проверку, модель — за структуру и формулировки.

Что входит в документ по версии BrowserStack: сведения о том, как дефект обнаружен, окружение, шаги воспроизведения, действия для устранения и ожидаемый результат. Этот перечень удобно использовать как чек-лист полноты. Если пункт не заполнен, отчёт вернётся с уточняющими вопросами.

Отдельно стоит зафиксировать, чего документ не делает. Он не назначает виновного, не заменяет триаж и не служит доказательством существования дефекта сам по себе. BrowserStack пишет, что отчёты помогают отслеживать статус проблем, расставлять приоритеты и управлять качеством, а также служат исторической записью для будущих обращений и аудитов. Это функции процесса, который начинается после публикации отчёта.

Сбор и проверка исходных данных

Сбор идёт до обращения к модели. Откройте проблемное место и зафиксируйте семь групп данных: окружение, предусловие, шаги, ожидаемый результат, фактический результат, повторяемость, приложения. Каждую группу проверьте на воспроизводимость: повторите шаги и убедитесь, что наблюдаете то же самое.

Окружение описывает систему, в которой вы работали: адрес тестового стенда, версия браузера, операционная система, номер сборки, конкретный путь или экран. Версия сборки важна, потому что дефект может быть уже исправлен в следующей. Путь нужен, чтобы разработчик попал на тот же экран без поиска.

Предусловие фиксирует состояние до первого шага: авторизован пользователь или нет, какие данные уже введены, какой режим включён. Предусловие отделяет вашу ситуацию от чужой и объясняет, почему у коллеги проблема не повторяется.

Шаги записывайте как последовательность действий, каждое из которых можно выполнить буквально. Формулировка «заполнить форму неправильно» не воспроизводима. Последовательность ввести адрес в поле email, оставить имя пустым, нажать кнопку отправки можно выполнить буквально.

Укажите источник ожидаемого результата: требование, макет или страницу документации. Если требование не сформулировано, отметьте это отдельно: отсутствие требования — самостоятельная проблема, и её стоит вынести в обсуждение.

Фактический результат описывает то, что вы видели, без интерпретации. «Поле очистилось» — наблюдение. «Скрипт потерял данные» — уже вывод о причине, и его нужно держать отдельно.

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

Приложения перечисляйте по именам файлов и отмечайте, какие из них действительно существуют. Скриншот, запись экрана и текст ошибки из консоли — разные типы доказательств, и каждый помогает по-своему.

Проверка исходных данных перед передачей модели занимает несколько минут и экономит цикл уточнений. Пройдите по списку и убедитесь, что каждое утверждение опирается на то, что вы наблюдали или прочитали в требовании. MDN советует создать минимальный тестовый пример, который воспроизводит проблему: он уменьшает вероятность того, что причина кроется в вашем коде или внешней зависимости. Для веб-задачи такой пример — отдельный небольшой файл без лишних зависимостей.

Готовый учебный артефакт BR-021

Ниже — заполненный учебный пример. Он показывает, как выглядит заполненный отчёт до передачи в трекер. Значения условные и служат образцом структуры.

BR-021. Форма очищает email после ошибки пустого имени

Окружение: тестовый сайт example.invalid, Chrome 138, Windows 11,
сборка 0.9.7, путь /request.
Предусловие: пользователь не авторизован.
Шаги:
1. Ввести demo@example.invalid в поле email.
2. Оставить поле имени пустым.
3. Нажать «Отправить».
Ожидаемый результат (учебное требование R-04): показать ошибку
для поля имени и сохранить введённый email.
Фактический результат: ошибка имени появилась, поле email очищено.
Повторяемость: в учебном наблюдении три раза из трёх.
Причина: неизвестна.
Влияние: email приходится вводить повторно.
Severity и priority: оставлены для триажа.
Приложение: br021-form.gif — в учебном примере не создано,
доказательством не является.

Разберём, что здесь сделано и почему. Окружение перечислено полностью, включая сборку и путь: разработчик может открыть тот же экран. Предусловие отделяет сценарий неавторизованного пользователя от остальных. Шаги пронумерованы и выполнимы буквально.

Ожидание привязано к требованию R-04. При расхождении команда может открыть это требование и проверить, как оно описывает сохранение email. Факт описан одним предложением и не содержит догадок о причине.

Повторяемость дана числом. Влияние сформулировано через действие пользователя: email приходится вводить повторно. Severity и priority оставлены для решения на триаже.

Строка про вложение честно сообщает, что файл не создан. Учебный пример не выдаёт несуществующий скриншот за доказательство. Если вы готовите реальный отчёт, приложите настоящий файл и укажите его имя.

Этот артефакт — образец формы. Корректность гипотетического BR-021 не доказывает существование реального дефекта и не подтверждает, что вложение создано.

Копируемый промпт с указанными входами

Промпт ниже оформляет ваши наблюдения в структуру отчёта. Замените квадратные скобки на свои данные и вставьте блок целиком.

Оформи мои наблюдения как баг-репорт для трекера.
Сохрани без изменений: версию сборки, путь, повторяемость,
номер требования. Разведи ожидаемый и фактический результат
отдельными полями. Не утверждай причину дефекта, поведение
в других браузерах и масштаб потерь. Если данных для поля нет,
оставь пометку «нет данных» и не додумывай.
Отметь, какие вложения существуют, а какие только заявлены.

Окружение: [адрес стенда, браузер и версия, ОС, сборка, путь]
Предусловие: [состояние пользователя и данных до шага 1]
Шаги: [нумерованный список действий]
Ожидаемый результат: [требование или макет]
Фактический результат: [что наблюдалось]
Повторяемость: [сколько раз из скольких]
Влияние: [что приходится делать пользователю]
Вложения: [имена файлов и статус]

Что менять под себя: блок входов в нижней части. Окружение, предусловие, шаги, ожидание, факт, повторяемость, влияние и вложения — восемь полей, каждое заполняется вашими данными. Если поле пустое, оставьте пометку вместо догадки.

Вариации той же задачи, если сценарий сложнее:

• Промпт для отчёта о дефекте в API: добавьте поля «метод и эндпоинт», «тело запроса», «код и тело ответа», «ожидаемый код».
• Промпт для отчёта о проблеме вёрстки: добавьте поля «разрешение экрана», «масштаб», «браузер и версия», «скриншот до и после».
• Промпт для отчёта о дефекте производительности: добавьте поля «объём данных», «время операции», «ожидаемое время», «профиль нагрузки».
• Промпт для отчёта о проблеме доступности: добавьте поля «используемая технология», «шаги навигации», «ожидаемое объявление», «фактическое поведение».
• Промпт для повторного отчёта после исправления: добавьте поля «версия с исправлением», «дата повтора», «результат повтора шагов».

Каждая вариация сохраняет главное правило: модель оформляет, автор проверяет. Не просите модель установить причину или предсказать результат исправления — эти утверждения требуют отдельного доказательства.

Отрицательный пример и неизвестные данные

Отрицательный пример показывает, как расширение данных портит отчёт. Формулировка «из-за JavaScript теряются заявки во всех браузерах» содержит три утверждения, которых нет в наблюдениях: названную причину, охват браузеров и масштаб потерь. Такое предложение нужно удалить целиком.

Почему это важно. Причина требует отладки, охват браузеров — отдельной матрицы тестов, масштаб потерь — данных о реальных пользователях. Ни одно из этих утверждений не следует из трёх шагов в одном браузере. Если оставить их в отчёте, разработчик потратит время на проверку гипотез, которые вы не проверяли.

Неизвестные данные оформляйте явно. В BR-021 причина помечена как неизвестная, severity и priority оставлены для триажа. Это корректная позиция: автор отчёта сообщает наблюдение, а оценку влияния и срочности дают те, кто отвечает за продукт.

BrowserStack в материале о severity и priority разводит эти понятия. Severity определяет техническая команда, часто независимо от бизнес-потребностей, опираясь на функциональность и производительность приложения. Priority определяют продуктовая команда, стейкхолдеры или руководство, учитывая срочность исправления относительно этапов проекта. Смешение этих ролей в одном поле создаёт путаницу при триаже.

Там же приведены примеры высокого severity: падение системы при запуске, потеря или повреждение данных, отказ ключевой функции вроде входа или обработки платежей. Примеры высокого priority: дефект, блокирующий оформление заказа, сломанный вход, сбой у ключевых пользователей. Эти примеры помогают понять логику оценки, но решение по конкретному отчёту остаётся за командой.

Ещё одна категория неизвестного — вложения. Если файл не создан, отметьте это. Учебный br021-form.gif не существует, и выдавать его за доказательство нельзя. В реальном отчёте приложите настоящий скриншот или запись и укажите имя файла.

Отдельно про поведение в других браузерах. MDN советует открыть минимальный тестовый пример в другом браузере: расхождение поведения повышает вероятность, что дело в браузере. Результат такой проверки можно вписать в отчёт после её выполнения. Пока проверка не сделана, поле остаётся пустым.

Проверка результата вручную по исходнику

После генерации черновика сверьте его с исходными данными. Проверка идёт по полям, и каждое поле имеет свой критерий.

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

Третье — наличие выводов о причине. Ищите слова «из-за», «потому что», «вследствие». Если они появились в черновике, а в ваших наблюдениях их не было, удалите предложение.

Четвёртое — масштаб. Формулировки «все пользователи», «во всех браузерах», «данные теряются» требуют доказательств, которых у автора одного наблюдения нет.

Полезно проверить и полноту. BrowserStack перечисляет элементы отчёта: как дефект обнаружен, окружение, шаги воспроизведения, действия для устранения, ожидаемый результат. Сверьте черновик с этим списком и добавьте пропущенное.

Документация GitHub описывает механику, которая помогает до публикации: при вводе заголовка и текста длиной от 100 символов система может предложить до трёх существующих issues, похожих на вашу. Подсказки не блокируют создание и служат сигналом проверить дубликаты. Если похожая проблема уже заведена, разумно дополнить её вместо создания новой.

Проверка по исходнику занимает меньше времени, чем цикл уточнений после публикации. Отчёт, в котором каждое утверждение прослеживается до наблюдения или требования, экономит время и автору, и разработчику.

Сохранение и согласование результата

Финальный шаг — публикация и согласование. Способов создания issue несколько, и документация GitHub предлагает выбрать удобный для вашего процесса. Права на создание есть у пользователей с доступом на чтение в репозитории, где включены issues.

Если в репозитории настроены шаблоны, при создании выбирается нужный тип. GitHub позволяет настраивать шаблоны для контрибьюторов, а формы issue поддерживают текстовые поля, выпадающие списки, чекбоксы и загрузку файлов; описываются они в YAML по схеме форм GitHub. Для репозитория можно задать шаблон по умолчанию, автоматический заголовок, назначение ответственных и метки.

Шаблон помогает не забыть поля, но не заменяет проверку. Заполненная форма с выдуманной причиной остаётся некачественным отчётом.

После публикации отчёт попадает в процесс триажа. Atlassian описывает шаблон отслеживания дефектов как централизованное место, где собираются все найденные проблемы вместе с ключевыми деталями: severity, версия и другие. Доски дают визуальное представление задач и помогают расставлять приоритеты, а бэклог служит хранилищем, из которого дефекты назначают и приоритизируют.

Согласование с командой включает несколько вопросов. Достаточно ли данных для воспроизведения. Верно ли определён severity. Кто берёт задачу в работу. Нужны ли дополнительные вложения. Эти вопросы обсуждают в комментариях к issue; согласованные уточнения затем вносят в отчёт.

Если дефект исправлен, нужен отдельный повтор шагов в реальном окружении. Исправление в новой сборке проверяется заново: те же шаги, тот же путь, тот же браузер. Результат повтора фиксируется отдельно от исходного отчёта.

Учебный BR-021 остаётся примером структуры. Он не является настоящим прогоном и не подтверждает поведение какого-либо продукта. Используйте его как образец формы, подставляя собственные проверенные данные.

Частые вопросы

Чем баг-репорт отличается от обычного сообщения об ошибке?
Баг-репорт — документ, который создают в ходе тестирования, чтобы выявить, описать и отследить дефекты приложения, по определению из руководства BrowserStack. Он содержит окружение, шаги воспроизведения, ожидаемый и фактический результат. Обычное сообщение часто ограничивается описанием симптома. Структура делает проблему воспроизводимой для разработчика.

Можно ли поручить ИИ определение причины дефекта?
Причину устанавливают при отладке с проверкой гипотез. В учебном BR-021 причина помечена как неизвестная, и это корректная позиция автора отчёта. Модель может предложить гипотезы, но в документ они попадают только после проверки. Иначе разработчик тратит время на непроверенные версии.

Что делать, если требование к поведению не сформулировано?
Ожидаемый результат берут из требования, макета или документации. Если источника нет, отметьте это отдельным пунктом: отсутствие требования — самостоятельная проблема. Обсудите её с продуктом до публикации отчёта. Так вы не выдаёте своё представление о правильном поведении за согласованное.

Как проверить, что дефект относится к браузеру?
MDN советует сначала подтвердить, что проблема действительно в браузере, и исключить ваш код, документацию и спецификацию. Затем создайте минимальный тестовый пример и откройте его в другом браузере: расхождение поведения повышает вероятность браузерного дефекта. Дополнительно проверяют приватное окно, отключённые расширения и очищенный кеш.

Кто определяет severity и priority?
Severity определяет техническая команда, опираясь на функциональность и производительность приложения, по материалу BrowserStack. Priority определяют продуктовая команда, стейкхолдеры или руководство, учитывая срочность относительно этапов проекта. Автор отчёта оставляет эти поля для триажа. Смешение ролей в одном поле создаёт путаницу при разборе.