Как быстрее репортить баги с помощью записи экрана (гайд для QA)

Почему только текстовые баг-репорты не работают

Письменные шаги воспроизведения кажутся полными тому, кто их писал, потому что он уже знает, что произошло. Разработчик, который их читает, — нет. «Нажмите "Сохранить" на странице профиля» не говорит, что перед этим вы поменяли email, что запрос длился восемь секунд и что ошибка мелькнула на полсекунды перед перезагрузкой страницы.

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

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

Шаблон баг-репорта, который сочетает текст и видео

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

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

1. Воспроизведите баг один раз перед записью. Убедитесь, что знаете шаги. Запись того, как вы ищете баг, в пять раз длиннее записи того, как вы его вызываете.
2. Начинайте с известного состояния. Начните запись на странице, которую разработчик узнает, с видимым адресом — а не посреди сценария.
3. Записывайте нужную область. Окно браузера или приложения, а не весь 4K-рабочий стол с открытыми Slack и почтой. Запись области держит фокус и не сливает посторонние данные.
4. Откройте DevTools, если баг в вебе. С видимой вкладкой Console или Network запись зафиксирует красную ошибку или неудачный запрос ровно в момент бага.
5. Коротко комментируйте. «Меняю email, нажимаю "Сохранить" — и вот 500». Ваш голос подсказывает разработчику, чего вы ждали на каждом шаге. Включите микрофон и говорите коротко.
6. Задержитесь на сломанном состоянии. Когда баг появляется, не двигайтесь две секунды, чтобы его было видно без покадровой перемотки.
7. Держитесь в пределах минуты. Вырежьте ожидание и неудачные попытки. Если баг требует долгой подготовки, опишите её текстом, а запишите только момент вызова.

Скриншоты: до сих пор самый быстрый способ репортить визуальные баги

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

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

Видео, GIF или скриншот?

• Скриншот — статичные визуальные баги: вёрстка, стили, тексты, неправильные данные на странице.
• GIF (до ~10 секунд) — короткие баги взаимодействия: состояние при наведении, сломанная анимация, список, который закрывается слишком рано. GIF сами играют в GitHub, Jira и Linear, так что разработчик видит баг, ничего не открывая.
• Видео с голосом — всё, что имеет несколько шагов, зависит от таймингов или требует объяснений: сценарии, гонки состояний, нестабильные ошибки.

Как QA-команды используют DashShot для баг-репортов

DashShot — наш продукт; вот как он ложится именно на этот процесс.

• Скриншоты: горячая клавиша, выделяете участок, отмечаете стрелками, рамками и нумерованными выносками, пикселизируете чувствительные данные — ссылка уже в буфере, остаётся вставить в тикет. Расширение Chrome также снимает страницы с прокруткой целиком и веб-приложения, которые прокручиваются внутри панели.
• Записи: запись области, окна или вкладки с микрофоном, вырезаете ожидание и вставляете ссылку. Разработчики открывают её в браузере без аккаунта. Для коротких взаимодействий — запись GIF до 12 секунд.
• Репорты из голоса: после записи расскажите о баге вслух — что делали, чего ждали, что случилось, — и DashShot превратит это в структурированную задачу с контекстом, ожидаемым результатом и критериями успеха. Разработчик получает ссылку со статусом и комментариями.
• Пошаговая документация из видео: для сложных путей воспроизведения DashShot может превратить запись в страницу со скриншотами и описанием каждого шага.

Скриншоты бесплатны, а бесплатный тариф также записывает до 5 минут на видео и даёт 10 AI-действий в месяц для голосовых задач и документации; Pro снимает эти ограничения. Подробности — на страницах запись экрана и скриншоты.

Типичные ошибки, из-за которых записи багов бесполезны

• Запись без видимого адреса или окружения. Разработчику приходится спрашивать, какая страница и какая сборка.
• Пять минут видео ради десятисекундного бага. Никто его не перематывает; обрежьте перед отправкой.
• Без звука, когда он важен. Если баг — «это длится слишком долго», скажите, сколько обычно.
• Видео вместо текста, а не вместе с ним. Заголовок, шаги и «ожидаемо/фактически» всё равно должны быть в тикете, чтобы его можно было найти.
• Чувствительные данные в кадре. Записи реальных клиентов, API-ключи в DevTools, внутренние чаты в углу. Записывайте область и пикселизируйте скриншоты.
• Вложение на 200 МБ. Таск-трекеры плохо тянут большие файлы; ссылка легче и открывается сразу.

Что это даёт

Хорошая запись бага делается на минуту дольше, чем текстовый репорт, и экономит разработчику десять минут на воспроизведение плюс круг вопросов. За спринт это складывается в дни. А главное — баги исправляют с первого раза, потому что тот, кто исправляет, видел ровно то, что видел тот, кто репортил.