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

Визуальный баг-репорт - это практика фиксировать то, что было на экране, и то, что знал браузер, в момент, когда человек решил сообщить о проблеме. Отчёт и есть свидетельство, а не описание свидетельства.

Что на самом деле в нём лежит

Слово “визуальный” его недооценивает. Картинка - это то, что человек замечает; большая часть пользы в том, что браузер делал за этой картинкой.

Визуальный баг-репорт обычно несёт часть этого или всё сразу:

  • Скриншот или запись страницы такой, какой её увидел отправитель, часто с чем-то нарисованным поверх, чтобы указать на проблему.
  • Окружение: браузер и его версия, операционная система, размер экрана. Факты, которые решают, универсален ли дефект или принадлежит одной конфигурации.
  • Вывод консоли, включая ошибку, которая была напечатана, пока в консоль никто не смотрел.
  • Сетевой лог: какие запросы делала страница, что вернулось, сколько это заняло. Часто ответом оказывается 403, которого никто не видел.
  • Что делал отправитель: клики, ввод в формы и переходы по страницам, которые к этому привели, по порядку.

Именно последнее превращает отчёт в инструкцию. Шаги воспроизведения, написанные по памяти, - это реконструкция; записанная последовательность - это протокол.

Чем он отличается от session replay

Эти две вещи путают, в том числе и мы сами: наш продукт называется Session Replay, и это имя мы выбрали сами, а категория эта не наша.

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

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

Session replay
Всегда включён, все посетители, просматривается потом, чтобы найти проблемы, о которых никто не сообщал
Визуальный баг-репорт
Начинается, когда человек сообщает, фиксирует один случай, уходит тому, кто может починить

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

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

Где это неподходящий инструмент

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

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

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

Как это выглядит на практике

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

Session Replay

Бесплатное расширение для Chrome. Один клик на странице, которая ведёт себя неправильно, фиксирует скриншот, консоль и сетевой лог и выдаёт вам ссылку, чтобы вставить её в тикет.

Установить расширение

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

Если вы выбираете между ними

Спросите себя, на какой вопрос вы пытаетесь ответить.

Если это “почему люди бросают эту форму”, вам нужна аналитика, и session replay относится к этому семейству. Если это “почему это сломалось у этого человека”, вам нужно зафиксировать случай и отправить его кому-то, и это баг-репортинг. Команды, которым нужно и то и другое, обычно используют оба, а путаница между ними приводит к просмотру четырёхсот записей ради одной, которую кто-то мог бы отдать вам за пятнадцать секунд.

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