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

Это узкий документальный процесс. Общие границы ввода и человеческого утверждения описаны в руководстве по использованию ИИ. Когда результат реально воспроизводится, переходите к отдельному процессу отладки с ИИ. Не смешивайте эти этапы: правдоподобная причина — не шаг воспроизведения, а аккуратно написанная процедура — не доказательство того, что её кто-то выполнил.

Ключевые выводы:

Сохраните исходные свидетельства, прежде чем переписывать отчёт.

Помечайте каждое утверждение как сообщённое, наблюдаемое, выведенное или неизвестное.

Явно указывайте окружение, исходное состояние, данные и время.

Минимальный тестовый пример полезнее длинного рассказа.

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

Итоговый пакет воспроизведения выполняет, дорабатывает и утверждает человек.

Как зафиксировать и очистить свидетельства?

Полезный баг-репорт может включать заголовок, текстовое описание, поля формы, комментарии, журналы, снимки экрана, видео или падение теста. Собирайте эти артефакты, не переписывая их незаметно. На GitHub задача служит местом для фиксации работы, а формы задач позволяют запрашивать структурированные сведения; поля могут требовать шаги воспроизведения, ожидаемое поведение и журналы.［1］［2］ Структура улучшает приём отчётов, но не доказывает, что каждое поле точно.

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

Создайте небольшой журнал приёма:

Поле	Что записать
ID отчёта	Стабильный номер задачи
Утверждение автора	Точное заявление или короткий цитируемый фрагмент
Свидетельство	Одобренный журнал, изображение, отметка времени видео или вывод теста
Время источника	Когда произошли событие и создание артефакта
Окружение	Продукт, версия, платформа, браузер или среда выполнения
Тип уверенности	Сообщено, наблюдалось, предположено, неизвестно
Чувствительные данные	Удалены, заменены, ограничены или отсутствуют

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

Как отделить факты от догадок?

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

Используйте запрос вроде:

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

«После нажатия “Сохранить” страница зависла» — сообщение. Видео с нажатием и зависшим состоянием — прямое свидетельство. «Это вызвала блокировка базы данных» остаётся гипотезой, пока отдельные доказательства её не подтвердят.

Сверьте извлечение с оригиналом. Удалите факты, которые нельзя проследить до артефакта или заявления. Противоречие — например, две разные версии приложения — относится к списку неизвестных, а не к усреднённому синтезу.

Опишите окружение и исходное состояние

Воспроизведение не удаётся, когда различается скрытое состояние. Запишите минимальное описание окружения, способное изменить результат:

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

Не превращайте «последнюю версию» в номер версии. Попросите автора отчёта узнать фактическое значение. Не выводите браузер по рамке снимка экрана, роль учётной записи — по имени пользователя, а проблему с сетью — по тайм-ауту. Если поле недоступно, пишите неизвестно и объясняйте, как тестировщик может получить значение.

Формулируйте предусловия как утверждения, которые можно проверить до шага 1. «Проект с названием „Пример“ существует, у тестировщика есть доступ редактора» лучше, чем «откройте свой проект». Если состояние дорого воссоздавать, ссылайтесь на очищенную фикстуру или процедуру подготовки, а не встраивайте конфиденциальные данные.

Как превратить баг-репорт в шаги воспроизведения с ИИ из атомарных действий?

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

Хорошая последовательность выглядит так:

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

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

Откуда брать ожидаемый и фактический результат?

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

Используйте одну точку наблюдения для обоих:

Точка	Ожидается	Фактически	Свидетельство
После нажатия «Сохранить»	Появляется подтверждение, статус становится «Сохранено»	Индикатор загрузки виден как минимум на протяжении записанного фрагмента видео	Видео E2, 00:18–00:31

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

Что делает тестовый пример минимальным?

MDN рекомендует при сообщении о проблемах браузера готовить минимальный автономный пример, потому что удаление постороннего кода облегчает изоляцию дефекта и обмен им.［3］ Минимальный не значит искусственный: каждый оставшийся входной элемент необходим, чтобы вызвать наблюдаемый результат.

Используйте ИИ, чтобы предложить очередь сокращений, а не объявлять их успешными:

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

Каждое сокращение должен запустить человек. Пометьте его сохранено, удалено или не проверено и сохраните наблюдаемый результат.

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

Добавьте точки наблюдения и матрицу запусков

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

Если свидетельства указывают на границу, связанную с окружением, создайте небольшую матрицу:

Переменная	Контроль	Кандидат	Результат
Версия	Предыдущая сборка	Сборка из отчёта	Не запускалось
Роль	Читатель	Редактор	Не запускалось
Данные	Пустая запись	Минимальная запись	Не запускалось

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

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

Рекомендации Mozilla по написанию багов также выделяют ясные шаги, фактический и ожидаемый результат.［4］ Добавьте два поля, особенно полезных при участии ИИ: реестр неизвестных и метку уверенности.

Определения уверенности должны описывать доказательства, а не уверенность модели:

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

Не позволяйте ИИ назначать статусы «Наблюдалось один раз» или «Повторяемо». Они требуют записанных доказательств выполнения человеком или автоматизированной системой. Высокая оценка уверенности языковой модели здесь не имеет значения.

Шаблон пакета воспроизведения

# Пакет воспроизведения
- ID отчёта:
- Область:
- Окружение и точные версии:
- Исходное состояние:
- Одобренная синтетическая фикстура:
- Предусловия:
- Неизвестные и противоречия:

## Шаги
1. [Действие]
   - Наблюдать:

## Результаты
- Точка наблюдения:
- Ожидаемый результат и источник:
- Сообщённый результат и свидетельство:
- Статус: Черновик
- Число запусков / порог:

## Доказательства
- ID артефакта, время и очищенное расположение:

## Передача
- Тестировщик:
- Владелец среды:
- Следующее решение:
- Утверждение человеком:

Попросите модель заполнять только поля, подтверждённые журналом свидетельств. Требуйте сохранять пустые поля и перечислять ссылки по ID свидетельств. Затем сверьте каждое заполненное поле с источником.

Выполните и утвердите пакет воспроизведения бага

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

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

Часто задаваемые вопросы (FAQ)

Может ли ИИ сам воспроизвести дефект?

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

Что делать с неполным отчётом?

Сохраните неизвестные и сформулируйте вопросы. Не выдумывайте версии, действия и ожидания ради полного шаблона.

Нужны ли снимки или видео?

Используйте их, если они разрешены и полезны, но добавляйте отметки времени и текстовое описание. Удаляйте личную и конфиденциальную информацию и не считайте визуальный контекст доказательством скрытого состояния.

Сколько запусков достаточно?

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

Чем воспроизведение отличается от диагностики?

Первое устанавливает наблюдаемый результат в известных условиях; второе проверяет гипотезы о причине. Держите эти утверждения и их утверждение раздельно.

Может ли ИИ сделать минимальный пример?

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

Как работать с чувствительными журналами?

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

Когда переходить к отладке?

Когда результат воспроизведения, окружение, свидетельства и неизвестные описаны достаточно явно, чтобы исследователь мог оценивать гипотезы, не переписывая историю.

Источники

Sources checked 29 августа 2026 г.

GitHub Docs, “Quickstart for GitHub Issues” — https://docs.github.com/en/issues/tracking-your-work-with-issues/learning-about-issues/quickstart
GitHub Docs, “Syntax for GitHub's form schema” — https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/syntax-for-githubs-form-schema
MDN Web Docs, “How to file a bug” — https://developer.mozilla.org/en-US/docs/Learn_web_development/Howto/Web_mechanics/File_browser_bugs
Mozilla Bugzilla, “Bug Writing Guidelines” — https://bugzilla.mozilla.org/page.cgi?id=bug-writing.html

Как превратить баг-репорт в шаги воспроизведения с ИИ