Salutare tuturor! Numele meu este Yulia și sunt un tester. Anul trecut v-am povestit despre Bagodelnya - un eveniment desfășurat în compania noastră pentru a curăța stocul de erori. Aceasta este o opțiune complet viabilă pentru a o reduce semnificativ (de la 10 la 50% în echipe diferite) într-o singură zi.

Astăzi vreau să vă spun despre formatul nostru de primăvară Bagodelny - BUgHunting (BUH). De data aceasta nu am remediat erorile vechi, ci am căutat altele noi și am propus idei pentru funcții. Sub tăietură există multe detalii despre organizarea unor astfel de evenimente, rezultatele noastre și feedback-ul participanților.

După ce am gândit și scris regulamentul, am trimis o invitație către toate canalele din Slack corporativ, care nu conținea nicio restricție:

Drept urmare, s-au înscris aproximativ 30 de persoane - atât dezvoltatori, cât și specialiști non-tehnici. Am alocat o zi întreagă de lucru pentru eveniment, am rezervat o sală mare de ședințe și am organizat prânzuri în cantina biroului.

De ce?

S-ar părea că fiecare echipă își testează funcționalitatea. Utilizatorii ne raportează erori. De ce să organizăm un astfel de eveniment?

Aveam mai multe obiective.

1. Prezenți băieții mai aproape de proiecte/produse conexe.
   Acum, în compania noastră, toată lumea lucrează în echipe separate - unități. Acestea sunt echipe de proiect care lucrează pe propria lor parte a funcționalității și nu sunt întotdeauna pe deplin conștienți de ceea ce se întâmplă în alte proiecte.
2. Doar prezentați-vă colegii unii altora.
   Avem aproape 800 de angajați în biroul nostru din Moscova; nu toți colegii se cunosc din vedere.
3. Îmbunătățiți capacitatea dezvoltatorilor de a găsi erori în produsele lor.
   Acum promovăm Agile Testing și pregătim băieți în această direcție.
4. Implicați mai mult decât specialiști tehnici în testare.
   Pe lângă departamentul tehnic, avem mulți colegi din alte specialități care au vrut să vorbească mai mult despre testare, despre cum să raportăm corect un bug, astfel încât să primim mai puține mesaje de genul „Ahhh... nimic nu funcționează”.
5. Și, desigur, găsiți bug-uri complicate și neevidente.
   Am vrut să ajut echipele să testeze noi funcții și să le ofer oportunitatea de a privi funcționalitatea implementată dintr-un unghi diferit.

punerea în aplicare

Ziua noastră a constat din mai multe blocuri:

• briefing;
• o scurtă prelegere despre testare, în care am atins doar punctele principale (scopurile și principiile testării etc.);
• secțiunea privind „regulile bunelor maniere” atunci când introduceți erori (aici principiile sunt bine descrise);
• patru sesiuni de testare pentru proiecte cu scenarii descrise la nivel înalt; înainte de fiecare sesiune a avut loc o scurtă prelegere introductivă asupra proiectului și împărțirea în echipe;
• scurt sondaj asupra evenimentului;
• rezumând.

(De asemenea, nu am uitat de pauzele dintre ședințe și prânz).

Normele Fundamentale

• Înregistrarea la evenimente este individuală, care rezolvă problema scurgerii întregii echipe din cauza inerției dacă o persoană decide să nu meargă.
• Participanții schimbă echipe la fiecare sesiune. Acest lucru permite participanților să vină și să plece în orice moment și, de asemenea, puteți întâlni mai multe persoane.
• comenzi două persoane înainte de fiecare sesiune sunt formate aleatoriu, acest lucru îl face mai dinamic și mai rapid.
• Pentru bug-uri introduse sunteți premiat puncte (de la 3 la 10) în funcție de criticitate.
• Nu se acordă puncte pentru duplicate.
• Bug-urile trebuie depuse de un membru al echipei în conformitate cu toate standardele interne.
• Solicitările de caracteristici sunt create într-o sarcină separată și participă la o nominalizare separată.
• Echipa de audit monitorizează respectarea tuturor regulilor.

Alte detalii

• Inițial, am vrut să fac un eveniment de testare „avansat”, dar... S-au înscris destul de mulți băieți din echipe non-produs (SMM, avocați, PR), a trebuit să simplificăm foarte mult conținutul și să eliminăm cazuri complexe/de profil.
• Datorită muncii unităților din Jira în diferite proiecte, conform fluxului nostru, am creat special un proiect separat în care am configurat un șablon pentru introducerea bug-urilor.
• Pentru a calcula punctele, au plănuit să folosească un clasament care a fost actualizat prin webhook-uri, dar ceva a mers prost și, în final, calculul a trebuit să fie făcut manual.

Toată lumea are probleme atunci când organizează evenimente și pentru a vă ușura puțin, vă voi descrie problemele noastre pe care le puteți evita.

Unul dintre vorbitori s-a îmbolnăvit brusc și a trebuit să găsească unul nou.
Am fost extrem de norocos că am găsit un înlocuitor din aceeași echipă la 9 dimineața). Dar este mai bine să nu te bazezi pe noroc și să ai ceva de rezervă. Sau fii gata sa dai singur raportul necesar.

Nu am avut timp să lansăm funcționalitatea, a trebuit să schimbăm blocurile.
Pentru a evita aruncarea unui bloc întreg, este mai bine să aveți un plan de rezervă.

Unii utilizatori de testare au căzut, a trebuit să recreăm rapid alții noi.
Verificați în avans utilizatorii de testare sau puteți să le faceți rapid.

Aproape niciunul dintre tipii pentru care formatul a fost simplificat nu a venit.
Nu este nevoie să tragi pe nimeni cu forța. Smeriți-vă.
Există o opțiune de a prescrie cu strictețe formatul evenimentului: „amator”/“avansat”, sau pregătiți două opțiuni deodată și decideți pe care să o organizați după fapt.

Puncte organizatorice utile:

• rezervați o întâlnire în avans;
• aranjați mesele, nu uitați de prelungitoare și dispozitive de protecție la supratensiune (încărcarea laptopurilor/telefoanelor poate să nu fie suficientă pentru întreaga zi);
• automatizarea procesului de notare;
• pregătirea tabelelor de clasare;
• realizează fișe de hârtie cu autentificări și parole ale utilizatorilor de testare, instrucțiuni de lucru cu Jira, scripturi;
• Nu uitați să trimiteți mementouri cu o săptămână înainte de eveniment și, de asemenea, să indicați ce trebuie să luați cu dvs. (laptop-uri/dispozitive);
• spune-le colegilor despre eveniment la o demonstrație, la prânzuri, la o ceașcă de cafea;
• sunt de acord cu devopții să nu actualizeze sau să lanseze nimic în această zi;
• pregătiți difuzoare;
• negociați cu proprietarii de caracteristici și scrieți mai multe scenarii pentru testare;
• Comandă delicii (prăjituri/bomboane) pentru gustări;
• nu uitați să ne spuneți despre rezultatele evenimentului.

Constatări

Pe parcursul întregii zile, băieții au reușit să testeze 4 proiecte și să creeze 192 de erori (134 dintre ele unice) și 7 probleme cu solicitări de caracteristici. Desigur, proprietarii de proiecte știau deja despre unele dintre aceste erori. Dar au fost și descoperiri neașteptate.

Toți participanții au primit premii dulci.

Și câștigătorii sunt termosuri, insigne, hanorace.

Ce s-a dovedit interesant:

• participanților li s-a părut neașteptat formatul sesiunilor grele, când timpul este limitat și nu poți petrece mult timp pe gânduri;
• a reușit să testeze versiunea desktop, mobilă și aplicațiile;
• Ne-am uitat la multe proiecte deodată, nu era timp să ne plictisim;
• a întâlnit diferiți colegi, a analizat abordările lor în ceea ce privește introducerea bug-urilor;
• a simțit toată durerea testatorilor.

Ce poate fi îmbunătățit:

• faceți mai puține proiecte și creșteți timpul de sesiune la 1,5 ore;
• pregătiți cadouri/suveniruri cu mult în avans (uneori aprobarea/plata durează o lună);
• relaxeaza-te si accepta ca ceva nu va merge conform planului si va fi forta majora.

Review-uri

Anna Bystrikova, administrator de sistem: „Pomana este foarte educativă pentru mine. Am învățat procesul de testare și am simțit toată „durerea” testatorilor.
La început, în timpul procesului de testare, ca utilizator exemplar, verificați principalele puncte: dacă butonul face clic, dacă merge la pagină, dacă aspectul a fost mutat. Dar mai târziu îți dai seama că trebuie să te gândești mai mult în afara cutiei și să încerci să „spargi” aplicația. Testerii au o treabă dificilă; nu este suficient să „împingeți” toată interfața; trebuie să încercați să gândiți în afara cutiei și să fiți extrem de atenți.
Impresiile au fost doar pozitive, chiar și acum, la ceva timp după eveniment, văd cum se lucrează la bug-urile găsite. Este grozav să te simți implicat în îmbunătățirea produsului ^_^.”

Dmitri Seleznev, dezvoltator front-end: „Testarea în modul competitiv ne motivează foarte mult să găsim mai multe erori). Mi se pare că toată lumea ar trebui să încerce să participe la Baghunting. Testarea exploratorie vă permite să găsiți acele cazuri care nu sunt descrise în planul de testare. În plus, oamenii care nu cunosc proiectul pot oferi feedback cu privire la confortul serviciului.”

Antonina Tatchuk, redactor principal: „Mi-a plăcut să mă încerc ca tester. Acesta este un stil de lucru complet diferit. Încerci să spargi sistemul, nu să te împrietenești cu el. Întotdeauna am avut ocazia să-i întrebăm pe colegii noștri ceva despre testare. Am învățat mai multe despre prioritizarea erorilor (de exemplu, m-am obișnuit să caut erori gramaticale în texte, dar „greutatea” unui astfel de bug este foarte mică; și invers, ceva care mi se părea nu foarte important a ajuns să fie un bug critic, care a fost imediat remediat).
La eveniment, băieții au oferit un rezumat al teoriei testării. Acest lucru a fost util pentru persoanele netehnice. Și câteva zile mai târziu m-am surprins gândindu-mă că scriam în sprijinul unui alt site folosind formula „ce-unde-când” și descriind în detaliu așteptările mele de la site și realitate.”

Concluzie

Dacă vrei să diversifici viața echipei tale, aruncă o privire nouă asupra funcționalității, aranjează un mini „Mâncați propria mâncare pentru câini”, atunci puteți încerca să organizați un astfel de eveniment și apoi îl putem discuta împreună.

Toate cele bune și mai puține bug-uri!

Sursa: www.habr.com