company_banner

Багодельня: BUgHunting. Как найти 200 багов за день

    Всем привет! Меня зовут Юля, и я тестировщик. В прошлом году рассказывала вам про Багодельню — мероприятие, проводимое у нас в компании для чистки бэклога багов. Это вполне жизнеспособный вариант значительно уменьшить его (в разных командах от 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 часов;
    • готовить подарки/сувениры сильно заранее (иногда согласование/оплата растягивается на месяц);
    • расслабиться и смириться с тем, что что-то пойдет не по плану и будут форс-мажоры.

    Отзывы


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

    image


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

    image


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


    Заключение


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


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

    Авито
    235,28
    У нас живут ваши объявления
    Поделиться публикацией

    Комментарии 7

      +3
      мы не фиксили старые баги, а искали новые и предлагали идеи для фич.

      Есть устоявшийся термин для подобного bug bash. В нашем случае нашли много мелких, не очень значимых багов. Если система достаточно сложная, то по идее лучший кандидат для поиска багов тот кто реально ей пользуется. А так даже программист её написавший, может не понимать что в реальной жизни люди идут не по той дорожке что он себе придумал.

      Сделайте хороший bug bounty — вам пользователи накидают таких багов, какие ваши тестеры никогда не придумают.

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

        Получается все эти баги были пропущены основными командами тестирования по проектам, анализировали с чем это связано? Может баги сложно воспроизводимые или времени не хватает.

          +2
          — получилось так, что благодаря свежим силам, количеству участников и их разному опыту смогли нашли как интересные и хитрые баги, которые пропустили(тут повлияло и отсутствие времени и замыленный взгляд) команды, так и незначительные ошибки;
          — какие-то фичи команды ещё толком не тестировали и к началу мероприятия мы их получили с пылу с жару;
          — основные команды уже знали о части багов, но т.к. они были заведены у них в собственных проектах в JIRA, участники их не видели. Чтобы не заставлять всех тратить время на поиск этих тасков по всей багтрекинговой системе, мы предложили заводить все баги в новом проекте JIRA с чистого листа;
          — были и дубли багов во время самого мероприятия.
          0
          Понятно что проводилось ознакомление с проектом. Но непонятно как потенциальные кандидаты ознакамливались с требованиями, особенно если они из другого проекта. И была ли процедура определения баг это или всё же фича? Сложилось впчатление что заводили все что нашли без розбирательства. Как все таки проходила процедура определения багов/фич?
            +1
            Мне кажется, не стоит заострять на этом вопросе внимание во время такого мероприятия. Если ребята решили что это баг, даже если это не так, то это повод для исследования момента UI/UX дизайнером. Возможно, у новых пользователей программы возникают такие же мысли.
            (Не имею отношения ни к авторам, ни к этому мероприятию)
              0
              Верно.
              Плюс мы кратко рассказывали про каждый проект перед началом сессий и всегда можно было задать вопросы команде аудита.
                0
                Спасибо за ответ. Теперь стало более понятно.

          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

          Самое читаемое