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

Отзиви

Анна Быстрикова, системен администратор: „Багодельнята за мен е много поучителна. Научих процеса на тестване, усетих цялата „болка“ на тестерите.
В началото на процеса на тестване, като примерен потребител, проверяваш основните моменти: натиска ли се бутона, преминава ли на страницата, не е ли разместен дизайнът. Но по-късно разбираш, че трябва да мислиш нестандартно и да опиташ да „счупиш“ приложението. Работата на тестерите не е лесна, не е достатъчно просто да ги пробиваш през целия интерфейс, трябва да се опитваш да мислиш извън рамките и да бъдеш изключително внимателен.
Впечатленията ми останаха само положителни, дори и в момента, след известно време след събитието, виждам как се работи по намерените от мен бъгове. Страхотно е да се чувстваш част от подобряване на продукта ^_^.”

Дмитрий Селезнёв, фронтенд разработчик: „Тестването в състезателен режим много мотивира да намериш повече бъгове). Смятам, че всеки трябва да пробва да участва в Багхантинга. Изследователското тестване позволява да намериш онези случаи, които не са описани в тестовия план. Освен това, хора, които не познават проекта, могат да дадат обратна връзка за удобството на услугата.”

Антонина Татчук, старши редактор: „Хареса ми да опитам да се поставя в ролята на тестер. Това е съвсем различен стил на работа. Опитваш се да счупиш системата, а не да си приятел с нея. Винаги имахме възможност да питаме колеги за тестването. Научих повече за приоритизирането на бъгове (например, свикнала съм да търся граматически грешки в текстовете, но „теглото“ на такъв бъг е много малко; и обратно, нещо, което ми се стори не много важно, в крайна сметка се оказа критичен бъг, който веднага беше поправен).
На събитието момчетата предоставиха обобщение на теоретичната част по тестването. Това беше полезно за не технически специалисти. А аз след няколко дни улавям себе си, че пиша в поддръжка на друг сайт по формулата „какво-къде-кога“ и подробно описвам моите очаквания от сайта и реалността.”

Заключение

Ако искате да разнообразите живота на екипа, да погледнете свежо на функционалността, да организирате мини «Яжте собствената си кучешка храна», можете да опитате да проведете такова събитие, а после можем заедно да го обсъдим.

На всички добри и по-малко бъгове!

Източник: habr.com