Всем привет! Меня зовут Юля, и я тестировщик. В прошлом году рассказывала вам про Багодельню — мероприятие, проводимое у нас в компании для чистки бэклога багов. Это вполне жизнеспособный вариант значительно уменьшить его (в разных командах от 10 до 50%) всего за один день.

Сегодня я хочу рассказать вам про наш весенний формат Багодельни — BUgHunting (BUH). В этот раз мы не фиксили старые баги, а искали новые и предлагали идеи для фич. Под катом много подробностей про организацию таких мероприятий, наши результаты и отзывы участников.

Продумав и прописав регламент, мы разослали во все каналы в корпоративном Slack приглашалку, в которой не было никаких ограничений:

В итоге записалось около 30 человек — и разработчики, и не технические специалисты. На мероприятие выделили целый рабочий день, забронировали большую переговорку, а обеды организовали на базе офисной столовой.

Зачем?

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

Целей у нас было несколько.

1. Познакомить ребят со смежными проектами/продуктами ближе.
   Сейчас у нас в компании все работают в отдельных командах — юнитах. Это проектные группы, которые пилят свою часть функциональности и не всегда полностью в курсе, что происходит в других проектах.
2. Просто познакомить коллег между собой.
   У нас почти 800 сотрудников в московском офисе, не все коллеги знают друг друга в лицо.
3. Повысить навык поиска багов у разработчиков в своих продуктах.
   Мы сейчас продвигаем Agile Testing и прокачиваем ребят в этом направлении.
4. Привлечь к тестированию не только технических специалистов.
   Помимо технического отдела у нас есть много коллег других специальностей, которым хотелось больше рассказать о тестировании, о том как правильно багрепортить, чтобы мы получали меньше сообщений формата «Аааа… ничего не работает».
5. Ну и, конечно же, найти хитрые и неочевидные баги.
   Хотелось помочь командам с тестированием новых фич и дать возможность взглянуть на реализованную функциональность под другим углом.

Реализация

Наш день состоял из нескольких блоков:

• брифинг;
• краткая лекция по тестированию, на которой мы затронули только основные моменты (цели и принципы тестирования и пр.);
• секция по «правилам хорошего тона» при заведении багов (тут хорошо описаны принципы);
• четыре сессии тестирования по проектам с высокоуровнево описанными сценариями; перед каждой сессией была краткая вводная лекция по проекту и распределение на команды;
• краткий опрос по мероприятию;
• подведение итогов.

(Про перерывы между сессиями и обед мы тоже не забыли).

Основные правила

• Регистрация на мероприятия индивидуальная, что решает проблему слива по инерции всей команды, если один человек решил не пойти.
• Каждую сессию участники меняют команду. Это позволяет участникам уходить и приходить в любое время, а ещё можно познакомиться с большим количеством человек.
• Команды по два человека перед каждой сессией формируются случайным способом, так получается динамичнее и быстрее.
• За заведенные баги начисляются баллы (от 3 до 10) в зависимости от критичности.
• За дубли очки не начисляются.
• Баги должны заводиться членом команды по всем внутренним стандартам.
• Фичареквесты заводятся в отдельной задаче и участвуют в отдельной номинации.
• За соблюдением всех правил следит команда аудита.

Другие детали

• Первоначально хотелось сделать «продвинутое» мероприятие по тестированию, но т.к. записалось достаточно много ребят из непродуктовых команд (SMM, юристы, PR), пришлось сильно упрощать контент и убирать сложные/профильные кейсы.
• Из-за работы юнитов в Jira в разных проектах по своим флоу мы специально сделали отдельный проект, в котором настроили шаблон для заведения багов.
• Для подсчета очков планировали использовать лидерборд, который обновлялся через вебхуки, но что-то пошло не так и в итоге подсчет пришлось делать вручную.

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

Один из докладчиков внезапно заболел и пришлось искать нового.
Мне дико повезло, что я нашла замену из той же команды в 9 утра). Но лучше не полагаться на удачу и иметь запасного. Или самому быть готовым рассказать нужный доклад.

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

Дропнулась часть тестовых пользователей, пришлось быстро пересоздавать новых.
Перепроверьте тестовых пользователей заранее или имейте возможность быстро их сделать.

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

Полезные организационные моменты:

• забронируйте переговорку заранее;
• расставьте столы, не забудьте про удлинители и сетевые фильтры (зарядки ноутов/телефонов на целый день может не хватить);
• автоматизируйте процесс подсчета очков;
• подготовьте рейтинговые таблицы;
• сделайте бумажные раздатки с логинами и паролями тестовых пользователей, инструкцией по работе с Jira, сценариями;
• не забудьте за неделю до мероприятия разослать напоминалки, дополнительно укажите, что необходимо взять с собой (ноуты/девайсы);
• рассказывайте коллегам про мероприятие на демо, на обедах, за чашечкой кофе;
• договоритесь с девопсами ничего не обновлять и не выкатывать в этот день;
• подготовьте докладчиков;
• договоритесь с владельцами фич и пропишите побольше сценариев для тестирования;
• закажите вкусняшки (печеньки/конфеты) для перекусов;
• не забудьте рассказать об итогах мероприятия.

Результаты

За целый день ребята успели протестировать 4 проекта и завести 192 бага (из них 134 уникальных) и 7 задач с фичареквестами. Конечно, про часть этих багов владельцы проектов уже знали. Но были и неожиданные находки.

Все участники получили сладкие призы.

А победители — термосы, значки, толстовки.

Что получилось интересно:

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

Что можно улучшить:

• делать меньше проектов и увеличить время сессии до 1,5 часов;
• готовить подарки/сувениры сильно заранее (иногда согласование/оплата растягивается на месяц);
• расслабиться и смириться с тем, что что-то пойдет не по плану и будут форс-мажоры.

Отзывы

Анна Быстрикова, системный администратор: «Багодельня для меня очень познавательна. Узнала процесс тестирования, прочувствовала всю "боль" тестировщиков.
Поначалу в процессе тестирования, как примерный пользователь, проверяешь основные моменты: тыкается ли кнопочка, переходит ли на страницу, не съехала ли верстка. Но позже понимаешь, что надо мыслить более нестандартно и пытаться "сломать" приложение. У тестировщиков непростая работа, мало "протыкивать" по всему интерфейсу, нужно стараться мыслить нешаблонно и быть крайне внимательным.
Впечатления остались только положительные, даже сейчас, спустя какое-то время после мероприятия, я вижу как ведется работа по найденным мной багам. Круто ощущать себя причастным к улучшению продукта ^_^».

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

Антонина Татчук, старший редактор: «Мне понравилось попробовать себя в роли тестировщика. Это совсем другой стиль работы. Ты пытаешься сломать систему, а не подружиться с ней. У нас всегда была возможность спросить что-то у коллег про тестирование. Узнала больше о приоритезации багов (например, я привыкла высматривать в текстах грамматические ошибки, но «вес» у такого бага очень маленький; и наоборот, что-то, что показалось мне не очень важным, оказалось в итоге критическим багом, который сразу же починили).
На мероприятии ребята дали выжимку из теории тестирования. Это было полезно для нетехнических специалистов. А я через несколько дней поймала себя на мысли, что пишу в поддержку другого сайта по формуле «что-где-когда» и подробно описываю свои ожидания от сайта и реальность».

Заключение

Если вы хотите разнообразить жизнь команды, посмотреть свежим взглядом на функциональность, устроить мини «Eat your own dog food», то можете попробовать провести такое мероприятие, а потом можем вместе его обсудить.

Всем добра и меньше багов!

Автор: J_eve

Источник