Bug Bash: как организовать продуктивную сессию

Bug bash — командная сессия тестирования, обычно 1-2 часа. Все — разработчики, QA, дизайнеры, продакт, маркетолог — одновременно тестируют продукт. Найденные баги фиксируются в спец-документе. По итогу команда видит реальное состояние продукта глазами «случайных» пользователей.

Делается раз в спринт перед релизом или в milestone-моменты. Но половина команд делает bug bash впустую — потому что плохо подготовлен. Гайд.

Зачем bug bash

— Выявить usability-проблемы. QA тестируют по сценарию, не по интуиции — пропускают UX-баги. — Свежий взгляд. Разработчик который писал фичу — слепой к её проблемам. — Привлечь не-QA. Маркетолог напишет про неловкий wording. Дизайнер — про rendering. — Командное ощущение продукта. Все на 2 часа становятся пользователями.

Что обязательно подготовить (за день до)

1. Документ для багов

Простая Google Sheet или Notion table:

Title	Severity	Steps	Screenshot	Reporter

Чтобы записывать быстро.

2. Test environment

Чистая среда, новые тестовые аккаунты для каждого участника, документ с креденшелами.

3. Browser/device coverage

Распредели: «Вася — iOS Safari, Маша — Chrome Windows, Петя — Android Chrome». Иначе все будут на одном.

4. Награды (опционально, но мотивирует)

«Самый креативный баг», «Самый critical», «Самый детальный bug-report». Простые призы — кофе, мерч, час free time.

Как запустить (день X)

— Kickoff 10 минут: «Тестируем X. Регистрируем баги в Y. Длится 90 минут. Цель — найти как можно больше реальных проблем, не теоретических».

— Назначь focus area для каждого участника. Маркетолог — onboarding flow. Дизайнер — animations. Senior dev — concurrent actions. Иначе все будут тыкать одно и то же.

— Live channel в Slack — для быстрых вопросов, обсуждения дублей.

— Halfway check: на 45-й минуте короткий sync — у кого что, есть ли блокеры. 5 минут.

— Stop time: в конце — стоп, не растягивай. Усталость снижает качество.

Сразу после

— Триадж багов в команде. По каждому: реальный? Severity? Owner? Когда фикс?

— Сборка дубликатов. 5 человек нашли один и тот же баг — это сигнал, что баг очевидный. Сделай master ticket, остальные закрывай как duplicates.

— Признание heroes. Лучшие баги — назвать имена. Это даёт стимул на следующий раз.

Антипаттерны

❌ Bug bash без триаджа. Нашли 50 багов → положили в Jira → забыли. Половина не фиксится никогда.

❌ Только QA участвует. Тогда это не bug bash, а обычный test cycle. Цель — вовлечение всей команды.

❌ Слишком сложный продукт без onboarding’a. Junior разработчик не знает где у вас профиль настроек → 30 минут потеряны на поиск. Подготовь cheat sheet.

❌ Без timeboxa. «Тестируем сколько найдём» → все растягивают на 4 часа → выгорают.

❌ Reward только critical-найденным. Тогда все тыкают где могут уронить — реальная usability игнорируется. Также награждай самый usable feedback.

Частота

— Перед major release: обязательно. — Раз в месяц: для активных продуктов. — Раз в спринт: чрезмерно — устают.

Что делать сейчас

✅ Если в команде никогда не делали bug bash — предложи. Скажи менеджеру «попробуем 1 час, если не зайдёт — больше не повторяем».

✅ Подготовь template — Google Sheet который reuse-ишь каждый раз.

✅ Через 3 bug bash — посмотри статистику. Стали баги в продакшене реже? Если да — продолжай. Если нет — что-то не так в процессе.

Подробнее: Ministry of Testing — Bug Bash guide.