Здраво на сите! Јас се викам Јулија и сум тестер. Минатата година ти кажав за Багоделња - настан одржан во нашата компанија за чистење на заостанатите грешки. Ова е сосема остварлива опција за значително намалување (од 10 на 50% во различни тимови) за само еден ден.

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

Размислувајќи ги и запишавме прописите, испративме покана до сите канали во корпоративниот Slack, која не содржеше никакви ограничувања:

Како резултат на тоа, се пријавија околу 30 луѓе - и програмери и нетехнички специјалисти. Одвоивме цел работен ден за настанот, резервиравме голема сала за состаноци и организиравме ручеци во канцелариската менза.

Зошто?

Се чини дека секој тим ја тестира својата функционалност. Корисниците ни пријавуваат грешки. Зошто воопшто да се одржи таков настан?

Имавме неколку голови.

1. Воведете ги момците поблиску до сродните проекти/производи.
   Сега во нашата компанија сите работат во посебни тимови - единици. Тоа се проектни тимови кои работат на свој дел од функционалноста и не се секогаш целосно свесни за тоа што се случува во другите проекти.
2. Само запознајте ги колегите еден со друг.
   Имаме речиси 800 вработени во нашата канцеларија во Москва; не сите колеги се познаваат по видување.
3. Подобрете ја способноста на програмерите да наоѓаат грешки во нивните производи.
   Сега го промовираме Agile Testing и тренираме момци во оваа насока.
4. Вклучете повеќе од само технички специјалисти во тестирањето.
   Покрај техничкиот оддел, имаме многу колеги од други специјалности кои сакаа да зборуваат повеќе за тестирање, за тоа како правилно да пријавиме грешка за да добиваме помалку пораки како „Аааа... ништо не функционира“.
5. И, се разбира, најдете незгодни и неочигледни грешки.
   Сакав да им помогнам на тимовите да тестираат нови функции и да им дадам можност да ја погледнат имплементираната функционалност од поинаков агол.

Реализация

Нашиот ден се состоеше од неколку блокови:

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

(Ние исто така не заборавивме на паузите помеѓу сесиите и ручекот).

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

• Пријавувањето за настани е индивидуално, со што се решава проблемот да се исцеди целиот тим поради инерција доколку едно лице реши да не оди.
• Учесниците ги менуваат тимовите секоја сесија. Ова им овозможува на учесниците да доаѓаат и да си одат во секое време, а исто така можете да запознаете повеќе луѓе.
• Тимови две лица пред секоја сесија се формираат по случаен избор, ова го прави подинамичен и побрз.
• За воведените грешки сте наградени поени (од 3 до 10) во зависност од критичноста.
• Не се доделуваат поени за дупликати.
• Грешки мора да бидат поднесени од член на тимот според сите внатрешни стандарди.
• Барањата за функции се креираат во посебна задача и учествуваат во посебна номинација.
• Ревизорскиот тим ја следи усогласеноста со сите правила.

Други детали

• Првично, сакав да направам „напреден“ настан за тестирање, но ... Пријавени се доста момци од тимови кои не се производи (SMM, адвокати, односи со јавноста), моравме многу да ја поедноставиме содржината и да отстраниме сложени/профилни случаи.
• Поради работата на единиците во Жира во различни проекти, според нашиот тек, специјално креиравме посебен проект во кој поставивме шаблон за воведување грешки.
• За да ги пресметаат поени, тие планираа да користат табла на водачи што се ажурираше преку веб-куки, но нешто тргна наопаку и на крајот пресметката мораше да се направи рачно.

Сите запаѓаат во неволја кога организираат настани, а за да ви олеснам малку, ќе ви ги опишам нашите проблеми кои можете да ги избегнете.

На еден од говорниците одеднаш му се слошило и морал да најде нов.
Имав голема среќа што најдов замена од истиот тим во 9 часот наутро). Но, подобро е да не се потпирате на среќа и да имате резерва. Или бидете подготвени сами да го дадете потребниот извештај.

Немавме време да ја развиеме функционалноста, моравме да ги замениме блоковите.
За да избегнете фрлање цел блок, подобро е да имате резервен план.

Некои тестирани корисници паднаа, моравме брзо повторно да креираме нови.
Вкрстено проверете ги корисниците на тестот однапред или можете брзо да ги направите.

Речиси никој од момците за кои беше поедноставен форматот не дојде.
Нема потреба никого со сила да влечете. Понижете се.
Постои опција строго да се пропише форматот на настанот: „аматерски“/„напреден“ или да се подготват две опции одеднаш и да се одлучи која да се одржи после фактот.

Корисни организациски точки:

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

Наоди

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

Сите учесници добија слатки награди.

А победници се термоси, беџови, дуксери.

Што испадна интересно:

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

Што може да се подобри:

• правете помалку проекти и зголемете го времето на сесија на 1,5 часа;
• подгответе подароци/сувенири многу однапред (понекогаш одобрувањето/плаќањето трае еден месец);
• опуштете се и прифатете дека нешто нема да оди според планот и ќе има виша сила.

Осврти

Ана Бистрикова, системски администратор: „Милостината е многу едукативна за мене. Го научив процесот на тестирање и ја почувствував целата „болка“ на тестерите.
Отпрвин, за време на процесот на тестирање, како примерен корисник, ги проверувате главните точки: дали копчето кликнува, дали оди на страницата, дали изгледот е преместен. Но, подоцна сфаќате дека треба повеќе да размислувате надвор од рамката и да се обидете да ја „скршите“ апликацијата. Тестерите имаат тешка работа; не е доволно да „боцкате“ низ целиот интерфејс; треба да се обидете да размислувате надвор од кутијата и да бидете исклучително внимателни.
Впечатоците беа само позитивни, дури и сега, извесно време по настанот, гледам како се работи на баговите што ги најдов. Одлично е да се чувствувате вклучени во подобрувањето на производот ^_^.“

Дмитриј Селезнев, развивач на предниот дел: „Тестирањето во конкурентен режим во голема мера не мотивира да најдеме повеќе грешки). Ми се чини дека секој треба да се обиде да учествува во Багунтинг. Истражувачкото тестирање ви овозможува да ги најдете оние случаи што не се опишани во планот за тестирање. Плус, луѓето кои не го знаат проектот можат да дадат повратни информации за практичноста на услугата“.

Антонина Тачук, виш уредник: „Ми се допадна да се обидувам себеси како тестер. Ова е сосема поинаков стил на работа. Се обидувате да го скршите системот, а не да се дружите со него. Секогаш имавме можност да ги прашаме нашите колеги нешто за тестирањето. Научив повеќе за приоретизирање на грешки (на пример, навикнат сум да барам граматички грешки во текстовите, но „тежината“ на таква грешка е многу мала; и обратно, се покажа нешто што ми се чинеше не многу важно биде критична грешка, која веднаш беше поправена).
На настанот, момците дадоа резиме на теоријата за тестирање. Ова беше корисно за луѓе кои не се технички. И неколку дена подоцна се фатив себеси како мислам дека пишувам за поддршка на друга страница користејќи ја формулата „што-каде-кога“ и детално ги опишувам моите очекувања од страницата и реалноста“.

Заклучок

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

Се најдобро и помалку грешки!

Извор: www.habr.com