Запись экрана для тестировщиков: инструменты и практики

Тестировщик нашёл баг. Написал в тикете: «При добавлении товара в корзину итоговая сумма не пересчитывается». Разработчик пробует воспроизвести — у него всё работает. Тикет возвращается с пометкой «не воспроизводится». Тестировщик тратит 15 минут на уточнение: «нет, только если сначала применить скидку, потом удалить один товар, а потом добавить новый». Ещё 10 минут на скриншоты.

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

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

Когда запись экрана необходима

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

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

Чеклист: что записать в видео-баг-репорте

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

Инструменты записи экрана для QA

У тестировщика другие требования к инструменту записи, чем у маркетолога. Главное — скорость запуска, минимум отвлечения от основной работы и удобный шеринг.

Для ручного тестирования веб-приложений Скрини оптимален: расширение всегда под рукой, запись начинается одним кликом, ссылка генерируется автоматически. Для автоматизации — встроенные средства Playwright или Cypress.

Лучшие практики записи для тестировщиков

1. Одно видео — один баг

Не записывай 10-минутную сессию тестирования и не вставляй одну ссылку во все тикеты. Разработчику придётся пересматривать всё видео, чтобы найти нужный момент. Правило: одно видео — один тикет.

2. Голосовой комментарий обязателен

Молчаливое видео, где курсор прыгает по экрану, мало чем отличается от набора скриншотов. Комментируй действия: «Нажимаю кнопку "Добавить"», «Жду загрузки», «Вот ошибка — ожидалось, что сумма пересчитается».

3. Показывай DevTools

Для веб-приложений консоль браузера — обязательный элемент. JavaScript-ошибки, неудачные сетевые запросы, предупреждения — всё это помогает разработчику быстрее найти причину бага. Открой DevTools (F12) до начала записи, переключись на вкладку Console.

4. Фиксируй окружение

В начале записи покажи или озвучь: браузер и версию, операционную систему, разрешение экрана. Это избавит от вопросов «а какой у тебя браузер?». В Chrome: Menu → Help → About Google Chrome показывает версию.

5. Проверяй воспроизводимость

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

Сценарии использования видео в QA

Запись экрана полезна не только для баг-репортов. Вот основные сценарии, где тестировщику пригодится видео.

Баг-репортинг

Основной сценарий. Нашёл баг — записал видео — приложил к тикету. Подробнее о структуре идеального видео-баг-репорта — в отдельной статье.

Регрессионное тестирование

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

Исследовательское тестирование

Записывай сессию исследовательского тестирования целиком (или большими фрагментами). После сессии просмотри запись и отметь найденные проблемы с таймкодами. Это позволяет не отвлекаться на оформление тикетов во время тестирования.

Документирование тестов

Видео прохождения тест-кейса — лучшая документация для нового члена команды. Вместо текстовых шагов «нажми сюда, потом сюда» — 2-минутное видео, которое показывает весь процесс.

Коммуникация с командой

Вместо длинного описания в Slack: «Я нашёл проблему в модуле оплаты...» — короткое видео с комментарием. Разработчик смотрит 30 секунд и сразу берёт в работу. Подробнее о видеокоммуникации — видеосообщения для работы.

Автоматическая запись видео при тестировании

Для автоматизированных тестов запись экрана можно настроить программно. Видео сохраняется только для упавших тестов — это помогает быстро понять причину падения.

Playwright

// playwright.config.ts
export default defineConfig({
  use: {
    video: 'retain-on-failure', // Видео только для упавших тестов
    screenshot: 'only-on-failure',
  },
});

Playwright записывает видео каждого теста и удаляет записи успешных прогонов. Для упавших тестов видео сохраняется в директории test-results — открыл файл и сразу видишь, что пошло не так.

Cypress

// cypress.config.js
module.exports = {
  video: true,
  videoCompression: 32,
  videosFolder: 'cypress/videos',
};

Cypress записывает видео всех прогонов (можно настроить только для CI). В Cypress Cloud видео доступны по ссылке — удобно для распределённых команд.

Рабочий процесс: видео в QA-команде

Как встроить запись экрана в ежедневный рабочий процесс QA-команды.

1. Обнаружение. Тестировщик находит баг в ходе ручного или исследовательского тестирования.
2. Запись. Нажимает горячую клавишу в расширении (Скрини, Awesome Screenshot), воспроизводит баг с голосовым комментарием, показывает DevTools. Останавливает запись — получает ссылку.
3. Оформление. Создаёт тикет в трекере: заголовок, шаги, ожидаемое/фактическое, окружение + ссылка на видео. Расставляет приоритет и severity.
4. Разработка. Разработчик смотрит видео, воспроизводит баг, фиксит. Если нужно уточнение — видео уже содержит 90% контекста, и переписка минимальна.

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

Частые ошибки

1. Запись всей сессии целиком. 30-минутное видео, где баг на 22-й минуте. Разработчик не будет пересматривать всё. Решение: начинай запись за 2–3 шага до бага.
2. Запись без звука. Курсор двигается по экрану, что-то происходит, непонятно что. Решение: включи микрофон и комментируй действия.
3. Конфиденциальные данные на экране. Пароли от staging, API-ключи в консоли, персональные данные пользователей. Решение: используй тестовые аккаунты, закрывай чувствительные данные.
4. Видео без текстового описания. Только ссылка в тикете, без заголовка, шагов и окружения. Решение: видео дополняет текст, а не заменяет его.
5. Забыл показать DevTools. Баг связан с JS-ошибкой, но консоль не открыта. Решение: открывай DevTools до начала записи.

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

Заключение

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