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

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

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

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

Защо?

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

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

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

Изпълнение

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

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

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

RћSЃRЅRѕRІRЅS <Rμ RїSЂR RІReR ° "F

• Записването за събития е индивидуално, което решава проблема с източването на целия екип по инерция, ако един човек реши да не отиде.
• Участниците сменят отборите си всяка сесия. Това позволява на участниците да идват и да си отиват по всяко време, а също така можете да се срещнете с повече хора.
• команди двама души преди всяка сесия се формират на случаен принцип, това го прави по-динамичен и по-бърз.
• За въведени грешки получавате награда точки (от 3 до 10) в зависимост от критичността.
• Не се присъждат точки за дубликати.
• Грешките трябва да се подават от член на екипа съгласно всички вътрешни стандарти.
• Заявките за характеристики се създават в отделна задача и участват в отделна номинация.
• Одитният екип следи за спазването на всички правила.

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

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

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

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

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

Някои тестови потребители отпаднаха, трябваше бързо да създадем отново нови.
Проверете тестовите потребители предварително или можете да ги направите бързо.

Почти никой от момчетата, за които форматът беше опростен, не дойде.
Няма нужда да влачите никого насила. Смирете се.
Има възможност за стриктно предписване на формата на събитието: „аматьорски“/„напреднали“ или да подготвите две опции наведнъж и да решите коя да проведете след факта.

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

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

резултати

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

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

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

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

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

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

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

Отзиви

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

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

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

Заключение

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

Всичко най-добро и по-малко грешки!

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