Всім привіт! Мене звуть Юля, і я тестувальник. Торік розповідала вам про Багодельню — захід, який ми проводимо в компанії для чищення беклогу багів. Це цілком життєздатний варіант значно зменшити його (у різних командах від 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", то можете спробувати провести такий захід, а потім можемо разом його обговорити.

Всім добра та менше багів!

Джерело: habr.com