Всем привет! Меня зовут Юлия и я тестировщик.
В прошлом году я рассказал вам о багодельня - в нашей компании проведено мероприятие по зачистке баглога.
Это вполне реальный вариант существенно снизить его (от 10 до 50% в разных командах) всего за один день.
Сегодня я хочу рассказать вам о нашем весеннем Багодельном формате - BUgHunting (БУХ).
В этот раз мы не исправляли старые ошибки, а искали новые и предлагали идеи по функциям.
Ниже под катом много подробностей об организации подобных мероприятий, наших результатах и отзывах участников.
Продумав и прописав регламент, мы разослали приглашение по всем каналам в корпоративном Slack, которое не содержало никаких ограничений: 
В результате записалось около 30 человек — как разработчиков, так и нетехнических специалистов.
На мероприятие мы выделили целый рабочий день, забронировали большой переговорный зал, организовали обеды в столовой офиса.
За что? Казалось бы, каждая команда тестирует свой функционал.
Пользователи сообщают нам об ошибках.
Зачем вообще проводить такое мероприятие? У нас было несколько целей.
- Познакомьте ребят поближе со смежными проектами/продуктами .
Сейчас в нашей компании все работают в отдельных командах – подразделениях.
Это проектные команды, которые работают над своей частью функционала и не всегда до конца осведомлены о том, что происходит в других проектах.
- Просто познакомьте своих коллег друг с другом .
В нашем московском офисе работает почти 800 сотрудников; не все коллеги знают друг друга в лицо.
- Улучшите возможности разработчиков находить ошибки в своих продуктах.
.Мы сейчас продвигаем Agile Testing и обучаем ребят этому направлению.
- Привлекайте к тестированию не только технических специалистов .
Помимо технического отдела, у нас есть много коллег из других специальностей, которые хотели больше поговорить о тестировании, о том, как правильно сообщить об ошибке, чтобы мы получали меньше сообщений типа «Аааа… ничего не работает».
- И, конечно же, находить хитрые и неочевидные ошибки.
.Я хотел помочь командам протестировать новые функции и дать им возможность взглянуть на реализованный функционал под другим углом.
- брифинг;
- небольшая лекция по тестированию, в которой мы затронули только основные моменты (цели и принципы тестирования и т.п.
);
- раздел о «правилах хорошего тона» при внесении ошибок ( здесь принципы хорошо описаны);
- четыре сессии тестирования проектов с высокоуровневым описанием сценариев; перед каждой сессией была короткая вводная лекция по проекту и разделение на команды;
- краткий обзор мероприятия;
- подведение итогов.
Основные правила
- Регистрация на мероприятия индивидуальная , что решает проблему слива всей команды по инерции, если один человек решит не идти.
- Участники меняют команды каждую сессию.
.Это позволяет участникам приходить и уходить в любое время, а также вы можете встретить больше людей.
- Команды два человека перед каждым сеансом формируются случайным образом , это делает его более динамичным и быстрым.
- За допущенные ошибки вы награждаетесь баллов (от 3 до 10) в зависимости от критичности .
- За дубликаты баллы не начисляются.
- Ошибки должны быть зарегистрированы членом команды в соответствии со всеми внутренними стандартами.
- Запросы функций создаются в отдельной задаче и участвуют в отдельной номинации.
- Аудиторская группа следит за соблюдением всех правил.
Другие детали
- Изначально я хотел сделать «продвинутое» тестирование, но.
Записалось довольно много ребят из непродуктовых команд (СММ, юристы, пиарщики), пришлось сильно упростить контент и убрать сложные/профильные кейсы .
- В связи с работой модулей в Jira в разных проектах, по нашему потоку, мы специально создали отдельный проект, в котором настроили шаблон для внесения ошибок.
- Для подсчета очков планировали использовать таблицу лидеров, которая обновлялась через вебхуки, но что-то пошло не так и в итоге подсчет пришлось проводить вручную.
Один из спикеров внезапно заболел и пришлось искать нового .
Мне дико повезло, что в 9 утра я нашел замену из той же команды).
Но лучше не надеяться на удачу и иметь запасной.
Либо будьте готовы предоставить необходимый отчет самостоятельно.
Не успели развернуть функционал, пришлось поменять блоки местами .
Чтобы не выбрасывать целый блок, лучше иметь запасной план.
Некоторые тестовые пользователи удалились, пришлось быстро заново создавать новых .
Перекрестно проверьте тестовых пользователей заранее или сделайте это быстро.
Из ребят, для которых упростили формат, почти никто не пришел.
.
Не надо никого тащить силой.
Смиритесь.
Есть возможность строго прописать формат мероприятия: «любительский»/«продвинутый», либо подготовить сразу два варианта и решить, какой провести постфактум.
Полезные организационные моменты:
- забронировать встречу заранее;
- расставьте столы, не забудьте про удлинители и сетевые фильтры (зарядки ноутбуков/телефонов может не хватить на целый день);
- автоматизировать процесс скоринга;
- подготовить рейтинговые таблицы;
- сделать бумажные раздаточные материалы с логинами и паролями тестовых пользователей, инструкциями по работе с Jira, скриптами;
- Не забудьте за неделю до мероприятия разослать напоминания, а также указать, что нужно взять с собой (ноутбуки/устройства);
- расскажите о мероприятии коллегам на демо-презентации, за обедом, за чашечкой кофе;
- договориться с девопсом ничего не обновлять и не выкатывать в этот день;
- подготовить спикеров;
- вести переговоры с владельцами функций и писать дополнительные сценарии для тестирования;
- заказать угощения (печенье/конфеты) на перекусы;
- не забудьте рассказать нам об итогах мероприятия.
Конечно, о некоторых из этих ошибок владельцы проекта уже знали.
Но были и неожиданные находки.
Все участники получили сладкие призы.
И победителями становятся термосы, значки, толстовки.
Что оказалось интересным:
- неожиданным для участников оказался формат жестких сессий, когда время ограничено и нельзя тратить много времени на размышления;
- успел протестировать десктопную, мобильную версию и приложения;
- мы рассматривали сразу много проектов, скучать было некогда;
- познакомился с разными коллегами, посмотрел их подходы к внедрению ошибок;
- почувствовал всю боль испытателей.
- делайте меньше проектов и увеличьте время сеанса до 1,5 часов;
- готовьте подарки/сувениры заранее (иногда согласование/оплата занимает месяц);
- расслабьтесь и смиритесь с тем, что что-то пойдет не по плану и возникнут форс-мажорные обстоятельства.
Анна Быстрикова, системный администратор: «Богадельня для меня очень познавательна.Я изучил процесс тестирования и почувствовал всю «боль» тестировщиков.
Сначала в процессе тестирования вы как примерный пользователь проверяете основные моменты: нажимается ли кнопка, переходит ли она на страницу, не съехала ли раскладка.
Но позже понимаешь, что нужно мыслить более нестандартно и попытаться «сломать» приложение.
У тестировщиков трудная работа; недостаточно «потыкать» по всему интерфейсу; вам нужно постараться мыслить нестандартно и быть предельно внимательным.
Впечатления остались только положительные, даже сейчас, спустя некоторое время после мероприятия, я вижу, как ведется работа над найденными мной ошибками.
Приятно чувствовать себя причастным к улучшению продукта ^_^».
Дмитрий Селезнев, фронтенд-разработчик : «Тестирование в соревновательном режиме очень мотивирует нас на поиск новых ошибок).Мне кажется, каждый должен попробовать поучаствовать в Багхантинге.
Исследовательское тестирование позволяет найти те случаи, которые не описаны в плане тестирования.
Плюс люди, не знающие проект, могут оставить отзыв об удобстве сервиса».
Антонина Татчук, старший редактор : «Мне понравилось попробовать себя в роли тестировщика.Заключение Если вы хотите разнообразить жизнь своего коллектива, по-новому взглянуть на функционал, устройте мини «Ешь свою собственную собачью еду» , тогда можно попробовать провести такое мероприятие, и тогда мы вместе его обсудим.Это совершенно другой стиль работы.
Вы пытаетесь сломать систему, а не подружиться с ней.
У нас всегда была возможность спросить коллег о тестировании.
Я узнал больше о приоритезации ошибок (например, я привык искать грамматические ошибки в текстах, но «вес» такого бага очень мал; и наоборот, то, что мне казалось не очень важным, оказалось это была критическая ошибка, которая была немедленно исправлена).
На мероприятии ребята дали изложение теории тестирования.
Это было полезно для нетехнических людей.
А через несколько дней поймал себя на мысли, что пишу в поддержку другого сайта по формуле «что-где-когда» и подробно описываю свои ожидания от сайта и реальность».
Всем добра и поменьше багов! Теги: #Управление разработкой #Хакатоны #тестирование #Тестирование веб-сервисов #Тестирование мобильных приложений #тестирование #Багодельня
-
Детская Психология
19 Oct, 24 -
Способы Поиска Цели. Роль Случая
19 Oct, 24 -
Корпоративный Сайт
19 Oct, 24 -
Бэкапить Или Не Бэкапить – Вот В Чем Вопрос
19 Oct, 24
