Как описать ошибку на сайте, чтобы разработчик смог её исправить

Что написать вместо «форма не работает»

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

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

Заголовок называет место и симптом

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

Ожидание и факт хранятся рядом

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

В примере формы ошибки GitHub отдельно названы Current Behavior, Expected Behavior, Steps To Reproduce и Environment — фактическое поведение, ожидаемое, шаги и окружение. Эти поля можно перевести и использовать в любом реестре. Покупать систему задач ради такого описания не требуется.

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

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

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

Адрес и шаги

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

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

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

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

Устройство и условия

В описании условий указывают браузер с версией, устройство и операционную систему, рабочий либо тестовый адрес и состояние входа в аккаунт. Если сбой происходит только на телефоне, полезна ориентация экрана и момент появления клавиатуры. Для ошибки, которая возникает нерегулярно, сохраняют время и часовой пояс. Это помогает сопоставить обращение с журналом сайта, где события могут отображаться иначе, чем на компьютере сотрудника. В примере GitHub есть выбор браузеров, включая Chrome, Firefox, Safari и Microsoft Edge, а версия самого продукта указана в отдельном поле Version.

Частота без придуманных процентов

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

Скриншот, запись экрана и технический журнал

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

Что оставить в кадре

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

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

Когда нужен файл HAR

Иногда исполнитель попросит запись сетевых запросов в HAR — формате, который сохраняет обмен браузера с сервером. Это уже дополнительный материал, а не обязательная часть каждого сообщения. В Chrome DevTools для него есть Export HAR (sanitized). Очищенный экспорт исключает, в частности, заголовки Cookie, Set-Cookie и Authorization. Передачу очищенного файла всё равно стоит поручить человеку, который сможет просмотреть адреса запросов и их содержимое: там могут остаться сведения, не удаляемые выбранным видом экспорта, хотя перечисленные секретные заголовки уже исключены. Жалобе на обрезанную подпись HAR не нужен. Я начинаю с адреса, шагов и снимка, а технический файл добавляю по конкретному запросу исполнителя, чтобы не собирать лишние данные и не усложнять первое обращение.

Что может предоставить сам разработчик

Если у команды есть автоматические тесты, она может приложить журнал их выполнения. В Playwright Trace Viewer доступны состояния страницы Before, Action и After — до действия, при его выполнении и после. Журнал помогает сопоставить клик с изменением страницы. Сотруднику компании не требуется создавать его вручную ради сообщения об ошибке.

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

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

Как вести запись до подтверждённого исправления

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

Срочность определяется последствиями

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

Чем закрывается ошибка

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

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

Почему расплывчатые жалобы обходятся дороже

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

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