Здравейте на всички! Аз съм Юлия и съм тестер. Миналата година ви разказах за Багодельня — събитие, провеждано в нашата компания за почистване на беклога от бъгове. Това е напълно жизнеспособен вариант значително да го намалим (в различни екипи от 10 до 50%) само за един ден.

Днес искам да ви разкажа за нашия пролетен формат на Багодельня — BUgHunting (BUH). Този път не се занимавахме със стари бъгове, а търсехме нови и предлагахме идеи за функции. Под кат имаме много подробности относно организацията на такива събития, нашите резултати и отзиви на участниците.

След като обмислихме и написахме регламента, изпратихме поканата във всички канали на корпоративния Slack, в която нямаше никакви ограничения:

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

Защо?

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

Имахме няколко цели.

1. Да запознаем колегите с близките проекти/продукти.
   В момента при нас в компанията всички работят в отделни екипи — юнити. Това са проектни групи, които разработват своята част от функционалността и не винаги са напълно в течение какво се случва в другите проекти.
2. Просто да запознаем колегите помежду им.
   Имаме почти 800 служители в московския офис и не всички колеги се познават лично.
3. Да повишим умението за търсене на бъгове у разработчиците в техните продукти.
   В момента популяризираме Agile Testing и обучаваме хората в тази насока.
4. Да привлечем към тестването не само технически специалисти.
   Освен техническия отдел при нас има много колеги от други специалности, на които искахме да разкажем повече за тестването, как правилно да правят репорти за бъгове, за да получаваме по-малко съобщения от формата «Аааа… нищо не работи».
5. И разбира се, да намерим хитри и неочевидни бъгове.
   Искахме да помогнем на екипите с тестването на новите функции и да им дадем възможност да погледнат реализираната функционалност от друг ъгъл.

Реализация

Нашият ден се състоеше от няколко блока:

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

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

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

• Регистрацията за събитията е индивидуална, което решава проблема с отсъствието на целия екип, ако един човек реши да не идва.
• На всяка сесия участниците сменят екипа. Това позволява на участниците да идват и си отиват по всяко време, а също така могат да се запознаят с много хора.
• Отбори по двама души преди всяка сесия се формират случайно, така става по-динамично и бързо.
• За създадените бъгове се начисляват точки (от 3 до 10) в зависимост от критичността.
• За дубли точки не се начисляват.
• Бъговете трябва да бъдат създадени от член на екипа по всички вътрешни стандарти.
• Фичъри (feature requests) се създават в отделна задача и участват в отделна номинация.
• Спазването на всички правила се наблюдава от екипа за одит.

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

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

Всеки, който организира събития, среща трудности, и за да ви е малко по-лесно, ще опиша нашите проблеми, които можете да избегнете.

Един от докладчиците внезапно се разболя и се наложи да търсим нов..
Имах невероятен късмет, че намерих замяна от същия екип в 9 сутринта). Но по-добре е да не разчитате на късмета и да имате резервен вариант. Или сами да сте готови да представите необходимата лекция.

Не успяхме да изведем функционалността, наложи се да сменяме блоковете местата.
За да не изхвърлите целия блок, по-добре е да имате резервен план.

Част от тестовите потребители се изключиха, наложи се бързо да създам нови..
Проверете тестовите потребители предварително или имайте възможност бързо да ги направите.

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

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

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

Резултати

През целия ден момчетата успяха да тестват 4 проекта и да задействат 192 бага (от които 134 уникални) и 7 задачи с искания за функции. Разбира се, собствениците на проектите вече знаеха за част от тези багове. Но имаше и неочаквани находки.

Всички участници получиха сладки награди.

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

Какво се оказа интересно:

• за участниците формата на строгите сесии, когато времето е ограничено и не можете да отделите много време за обмисляне, беше неочаквано;
• успяхме да тестваме десктоп, мобилна версия и приложения;
• видяхме веднага много проекти, нямаше време да се отегчим;
• запознахме се с различни колеги, видяхме техния подход при създаването на багове;
• усетихме цялата болка на тестерите.

Какво може да се подобри:

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

Отзиви

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

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

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

Заключение

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

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

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