Bună ziua tuturor! Numele meu este Yulia și sunt testeri. Anul trecut v-am povestit despre Bugathon — un eveniment organizat de noi în companie pentru curățarea backlog-ului de bug-uri. Este o variantă perfect viabilă de a-l reduce semnificativ (în diferite echipe de la 10% până la 50%) într-o singură zi.

Astăzi vreau să vă povestesc despre formatul nostru primăvăratic al Bugathon-ului — BUgHunting (BUH). De data aceasta nu am reparat bug-uri vechi, ci am căutat altele noi și am propus idei pentru funcționalități. Sub titlu sunt multe detalii despre organizarea unor astfel de evenimente, rezultatele noastre și feedback-ul participanților.

După ce am gândit și redactat reglementările, am trimis o invitație în toate canalele din Slack-ul corporativ, în care nu erau restricții:

În cele din urmă, s-au înscris aproximativ 30 de persoane — atât dezvoltatori, cât și specialiști non-tehnici. Pentru eveniment s-a alocat o zi întreagă de lucru, am rezervat o sală mare de negocieri, iar prânzurile au fost organizate în baza cantinei oficiului.

De ce?

Ar părea că fiecare echipă testează funcționalitatea sa. Utilizatorii ne raportează bug-uri. De ce să organizăm un astfel de eveniment?

Obiectivele noastre au fost mai multe.

1. A familiariza colegii cu proiectele/producția înrudite mai îndeaproape.
   Acum, în compania noastră, toți lucrează în echipe separate — unități. Acestea sunt grupuri de proiect care dezvoltă partea lor de funcționalitate și nu sunt întotdeauna complet la curent cu ceea ce se întâmplă în alte proiecte.
2. A familiariza colegii între ei.
   Avem aproape 800 de angajați în biroul din Moscova, nu toți colegii se cunosc între ei.
3. A crește abilitățile de căutare a bug-urilor la dezvoltatori în propriile produse.
   În prezent promovăm Agile Testing și îi ajutăm pe colegi în această direcție.
4. A atrage la testare nu doar specialiști tehnici.
   În afară de departamentul tehnic, avem mulți colegi din alte specialități, cărora le-ar plăcea să le povestim mai multe despre testare, despre cum să raportăm corect bug-uri, astfel încât să primim mai puține mesaje de tipul "Aaaa... nu funcționează nimic".
5. Și, bineînțeles, să găsim bug-uri subtil și neclare.
   Ne-am dorit să ajutăm echipele cu testarea noilor funcționalități și să le oferim ocazia de a privi funcționalitatea implementată dintr-o altă perspectivă.

Implementarea

Ziua noastră a fost alcătuită din mai multe blocuri:

• briefing;
• o lectură scurtă despre testare, în care am abordat doar aspectele fundamentale (obiectivele și principiile testării și altele);
• o secțiune despre „regulile de bună conduită” în raport cu raportarea erorilor (aici principiile sunt bine descrise);
• patru sesiuni de testare pe proiecte cu scenarii descrise la un nivel înalt; înainte de fiecare sesiune a avut loc o scurtă prezentare introductivă despre proiect și repartizarea pe echipe;
• un scurt sondaj despre eveniment;
• sinteza concluziilor.

(Nici despre pauzele între sesiuni și prânz nu am uitat).

Reguli de bază

• Înregistrarea la evenimente este individuală, ceea ce rezolvă problema de a renunța la întreaga echipă dacă o persoană a decis să nu participe.
• La fiecare sesiune participanții schimbă echipa. Acest lucru permite participanților să vină și să plece în orice moment, și de asemenea, pot cunoaște un număr mai mare de persoane.
• Comenzi câte doi oameni înainte de fiecare sesiune sunt desemnați aleatoriu, ceea ce face ca totul să fie mai dinamic și mai rapid.
• Pentru erorile raportate se acordă puncte (între 3 și 10) în funcție de severitate.
• Nu se acordă puncte pentru duplicate.
• Erorile trebuie raportate de un membru al echipei conform tuturor standardelor interne.
• Cererea de funcții se raportează într-o sarcină separată și participă la o nominalizare distinctă.
• Echipa de audit monitorizează respectarea tuturor regulilor.

Alte detalii

• Inițial, ne-am dorit să organizăm un eveniment „avansat” de testare, dar deoarece s-au înscris suficienți oameni din echipe non-produse (SMM, avocați, PR), a trebuit să simplificăm foarte mult conținutul și să eliminăm cazuri complexe/professionale.
• Din cauza muncii unităților în Jira pe diferite proiecte conform fluxurilor lor, am creat un proiect separat, în care am configurat un șablon pentru raportarea erorilor.
• Pentru a contabiliza punctele, am planificat să folosim un leaderboard care să se actualizeze prin webhook-uri, dar ceva nu a mers bine și, în cele din urmă, contabilizarea a trebuit făcută manual.

Fiecare persoană implicată în organizarea evenimentelor dă peste obstacole și pentru a vă face viața un pic mai ușoară, voi descrie problemele noastre pe care le puteți evita.

Unul dintre vorbitori s-a îmbolnăvit brusc și a fost necesar să căutăm un nou.
Am avut o noroc fantastic că am găsit un înlocuitor din aceeași echipă la 9 dimineața). Dar e mai bine să nu te bazezi pe noroc și să ai un rezervă. Sau să fii tu însuți pregătit să susții prezentarea necesară.

Nu am reușit să lansăm funcționalitatea, a fost necesar să schimbăm blocurile între ele.
Pentru a nu arunca întregul bloc, este mai bine să aveți un plan de rezervă.

O parte dintre utilizatorii testați au abandonat, a trebuit să recreăm rapid altele..
Verificați utilizatorii testați dinainte sau aveți posibilitatea de a-i crea rapid.

Aproape nimeni dintre băieții pentru care am simplificat formatul nu a venit..
Nu trebuie să tragi pe nimeni cu forța. Acceptați.
Există opțiunea de a defini strict formatul evenimentului: „amator”/„avansat”, sau să pregătiți două variante și să decideți la fața locului care să fie desfășurată.

Aspecte organizatorice utile:

• rezervați sala de ședințe din timp;
• aranjați mesele, nu uitați de extensii și filtre de rețea (încărcătoarele pentru laptopuri/telefoane pentru o zi întreagă ar putea să nu fie suficiente);
• automatizați procesul de numărare a punctelor;
• pregătiți tabele de clasament;
• creați materiale tipărite cu numele de utilizator și parolele utilizatorilor testați, instrucțiuni de utilizare a Jira, scenarii;
• nu uitați să trimiteți memento-uri cu o săptămână înainte de eveniment, indicați suplimentar ce trebuie să aducă cu ei (laptopuri/dispozitive);
• vorbiți colegilor despre eveniment la prezentări, la prânzuri, la o ceașcă de cafea;
• stabiliți cu devops-urile să nu actualizeze nimic și să nu lanseze nimic în acea zi;
• pregătiți prezentatorii;
• stabiliți cu proprietarii caracteristicilor și elaborați mai multe scenarii pentru testare;
• comandați gustări (biscuiți/ciocolată) pentru gustări;
• nu uitați să raportați despre rezultatele evenimentului.

Rezultate

Într-o singură zi, băieții au reușit să testeze 4 proiecte și să raporteze 192 de erori (dintre care 134 unice) și 7 sarcini cu cereri de caracteristici. Desigur, unele dintre aceste erori erau deja cunoscute de către proprietarii proiectelor. Dar au fost și descoperiri neașteptate.

Toți participanții au primit premii dulci.

Iar câștigătorii — termosuri, insigne, hanorace.

Ce a fost interesant:

• pentru participanți, formatul sesiunilor stricte, când timpul era limitat și nu se putea pierde mult timp gândindu-se, a fost neașteptat;
• a fost posibil să testăm versiunea desktop, versiunea mobilă și aplicațiile;
• am văzut imediat multe proiecte, nu a fost timp de plictiseală;
• ne-am întâlnit cu diferiți colegi, am observat abordările lor la raportarea erorilor;
• am simțit durerea tuturor testerilor.

Ce se poate îmbunătăți:

• să facem mai puține proiecte și să creștem timpul sesiunii la 1,5 ore;
• să pregătiți cadouri/suveniruri cu mult înainte (uneori, aprobarea/plata se întinde pe o lună);
• să te relaxezi și să te împaci cu faptul că ceva nu va merge conform planului și vor apărea forțe majore.

Recenzii

Anna Bystrikova, administrator de sistem: „Pentru mine, Bug Hunting este foarte instructiv. Am învățat procesul de testare, am simțit toată 'durerea' testerilor.
La început, în procesul de testare, ca un utilizator obișnuit, verifici aspectele principale: dacă butonul funcționează, dacă se face trecerea pe pagină, dacă designul nu este stricat. Dar mai târziu înțelegi că trebuie să gândești mai neobișnuit și să încerci să 'spargi' aplicația. Testerii au o muncă dificilă, nu este suficient să te uiți doar prin tot interfața, trebuie să gândești în mod creativ și să fii extrem de atent.
Impresiile rămân doar pozitive, chiar acum, după ceva timp de la eveniment, observ cum se lucrează la bug-urile pe care le-am găsit. E grozav să te simți parte din îmbunătățirea produsului ^_^.”

Dmitry Seleznyov, dezvoltator front-end: „Testarea în mod competitiv motivează foarte mult să găsești mai multe bug-uri). Cred că toată lumea ar trebui să încerce să participe la Bug Hunting. Testarea exploratorie permite găsirea unor cazuri care nu sunt descrise în planul de testare. Plus, oamenii care nu cunosc proiectul pot oferi feedback privind utilizabilitatea serviciului”.

Antonina Tatchuk, editor senior: „Îmi place să încerc să fiu tester. Este un stil de lucru complet diferit. Încerci să 'spargi' sistemul, nu să te împrietenești cu el. Am avut întotdeauna ocazia să întreb colegii despre testare. Am învățat mai multe despre prioritizarea bug-urilor (de exemplu, eram obișnuită să caut greșeli gramaticale în texte, dar 'greutatea' unui astfel de bug este foarte mică; și invers, ceva care mi s-a părut nesemnificativ s-a dovedit a fi un bug critic, care a fost reparat imediat).
La eveniment, băieții au oferit o sinteză din teoria testării. A fost util pentru specialiștii non-tehnici. Apoi, după câteva zile, m-am surprins gândindu-mă că scriu la suportul unui alt site conform formulei 'ce-unde-când' și descriu în detaliu așteptările mele de la site și realitatea.”

Concluzie

Dacă doriți să diversificați viața echipei, să priviți funcționalitatea dintr-o perspectivă nouă, să organizați un mini „Mănâncă din mâncarea ta”, atunci poți încerca să organizezi un astfel de eveniment, iar apoi putem să-l discutăm împreună.

Toată lumea să aibă parte de bine și mai puține bug-uri!

Sursa: habr.com