— cum se aplică procesul de a aduce organizare și ușor de Bug Bash Cremona

Important: acesta este un pas cu pas al modului de organizare a unui bug bash. Mai multe despre beneficiile utilizării sale la QuintoAndar pot fi găsite în articolul „Cum bug bashing a schimbat frecvent și în mod constant mentalitatea echipei față de calitate și conexiune construită la QuintoAndar”.

introducere

Bug Bash este o metodologie de testare, definită inițial de Ron Patton în cartea sa Software Testing în 2001. Această abordare a testării a fost utilă pentru diferite echipe de la QuintoAndar și, ca rezultat, am creat un proces de optimizare a aplicării sale.

Bug ce?!

am auzit prima dată termenul de bug bash la interviul meu de recrutare la QuintoAndar și a sunat bine. Mai târziu, am căutat online mai multe informații doar pentru a afla că aceasta a fost o practică destul de răspândită, folosită de multe companii cu un lucru în comun: un mediu agil. Bug Bash este o metodologie de testare definită inițial de Ron Patton, 2001. În cartea sa „testarea Software-ului”, el descrie bug bash ca o procedură în care toți oamenii implicați în ciclul de dezvoltare al produsului, își lasă deoparte sarcinile obișnuite de zi cu zi și „pun pe produs”. Deci, toți cei care au avut cumva un cuvânt de spus despre produs — de la definiție la design; de la dezvoltare la marketing — ar trebui să fie în aceeași cameră, testând caracteristica, în cât mai multe moduri posibil înainte de a o lansa.

aduce echipa — de la părțile interesate la dezvoltare — mai aproape pentru a acoperi cât mai multe scenarii de testare posibil și, prin urmare, reducerea șanselor unei eliberări defecte. Recunoscând că aceasta ar putea fi o alternativă viabilă și valoroasă la ritmul nostru rapid și intens de lucru, am început să introducem încet conceptul în echipă, îmbunătățind și adaptând întotdeauna abordarea în funcție de nevoile funcției.

Heaven, tu ești?

sună ca un vis, dar dacă ați condus vreodată un Bug bash, probabil știți cât de haotic poate ajunge să adune atât de multe profiluri diferite într-o cameră: unii oameni ridică îndoieli cu privire la faptul că este un bug sau nu, alții întreabă unde să raporteze constatările, alții au probleme cu accesarea sistemului, toată lumea discută cum să urmărească și să acorde prioritate remedierilor de erori în timp ce testează și așa mai departe. Fără o pregătire minimă, șansele sunt că detaliile importante vor fi pierdute între întrebări și post-it-uri, oamenii vor fi frustrați pentru că nu sunt ascultați și, în cele din urmă, care ar trebui să fie cel mai productiv timp găsirea de bug-uri se poate dovedi ca o pierdere de timp pentru întreaga echipă.

pe lângă complexitatea inerentă a coordonării unui bug bash, am avut și provocarea de a aplica conceptul pe un produs care oferă o soluție completă de afaceri: de la căutarea proprietății la administrarea închirierii. Asta înseamnă livrabile back-end și front-end pe parcursul întregii experiențe a utilizatorului. Prin urmare, aici, la QuintoAndar, era imperativ să existe un proces flexibil și adaptabil care să se potrivească ambelor scenarii.

știam că există — și încă este — o mare provocare în fața noastră: Noțiuni de bază pentru a ști cum să aplice Bash bug în mod eficient în diferite contexte. Aveam nevoie de o elice. Adică, un proces lin, cu instrumente esențiale și robuste pentru centralizare, care a fost suficient de adaptabil pentru a fi utilizat la validarea diferitelor tipuri de livrări.

deci, întrebându-ne despre realizările de mai sus, am creat un proces axat pe combinarea punctelor cheie de testare împreună cu elementele cheie ale raportării erorilor, cât mai simplificat posibil, fără a compromite eficiența acestuia.

după cum sa menționat, fundamentele pentru o bash bug bun include o fază de pregătire în care persoana de asigurare a calității, stabilește condițiile de testare, oferind testeri temporare cu instrumente care fac abilitățile lor de testare evaluate. Există trei pași principali pentru o configurare bună:

Pasul 1: Creați o foaie de calcul pentru a centraliza toate constatările

În primul rând: avem nevoie de toată lumea pe aceeași pagină. Literalmente! Când încercați să cartografiați problemele, este fundamental să raportați totul pe un singur document. Aceasta ar putea însemna o notă comună, un document text, un carton uriaș. Am decis să folosim o foaie de calcul în care să putem oferi și o îndrumare vizuală a ceea ce a fost testat. Această alegere a fost o colaborare cu designerul de produse al echipei, care descrie beneficiile pentru Design în sine în articolul „design de produs & Bug bash: cum să validați interfețele și calitatea asigurați-vă livrarea de la capăt la capăt”.

o foaie de calcul permite, de asemenea, ca procesul să fie ușor automatizat pentru a fi mai lin și mai funcțional. Într-o foaie de calcul bug bash, avem trei file: participanți, Bug bash, raport automat.

un scurt videoclip care arată interacțiuni pe o foaie de calcul. Există trei file pe foaia de calcul și primele interacțiuni sunt pe prima filă, denumită „participanți”. Șase coloane („cine testează”,” Contact cu produsul”,” utilizator simulat”,” Tip dispozitiv”,” Marcă dispozitiv „și” Browser”) fiind câmp unul câte unul, selectând o opțiune din meniurile sale derulante.

deoarece aplicațiile pentru utilizatorii finali ale QuintoAndar sunt în mare parte bazate pe web, testarea trebuie să includă diferite dispozitive mobile și desktop. Uneori, problema este legată de dispozitiv, ceea ce face ca dezvăluirea sa să fie indispensabilă. Așa că am creat fila” participanți”, în care fiecare tester sau participant al bug bash introduce informații precum numele, utilizatorul simulat, browserul, marca dispozitivului și tipul dispozitivului. Acestea sunt informațiile de bază de care avem nevoie pentru a începe investigarea — sau remedierea — problemei. Odată ce aceste informații sunt completate, putem continua.

în a doua filă „Bug bash” combinăm elementele de testare și raportare a erorilor. O imagine a contextului care urmează să fie testat în prima coloană este urmată de trei coloane în care testerul introduce numele testerului, o descriere detaliată a problemei găsite, precum și o imagine a acesteia, dacă este cazul. În acest fel, dacă există îndoieli cu privire la raport, știm pe cine să întrebăm și să economisim timp. Acest lucru este deosebit de valoros atunci când asigurăm livrările front-end, deoarece putem valida produsul final în raport cu aspectul proiectat. Dacă validăm livrările back-end, imaginea front-end este de obicei înlocuită cu un flux de lucru care explică ce se întâmplă pe back-end. În acest fel, ținem oamenii la curent cu contextul, chiar dacă nu este vizibil testabil. Oamenii vor testa produsul și vor raporta toate problemele, îmbunătățirile și îndoielile din această filă. Când timpul de testare este de până, Echipa va trece peste problemele raportate, revizuirea și discutarea ceea ce are sens să fie incluse în faza de fixare.

un scurt videoclip se afișează a doua interacțiune setată în a doua filă numită „Bug Bash”. În prima coloană, există o captură de ecran a unei părți a site-ului web urmată de alte coloane numite „cine a găsit-o ?”, „Titlul emisiunii”, „descrierea problemei”, „captură de ecran”și ” raport”. Videoclipul arată că fiecare câmp este completat tastând.

datorită acestei etape de evaluare și prioritizare a gravității, întreaga echipă va fi conștientă de toate problemele găsite și le va selecta pe cele legate de acel ciclu de dezvoltare pentru raportare. Acest lucru va optimiza faza de raportare și va evita întâlnirile de urmărire pentru a acorda prioritate problemelor.

a treia și ultima filă din foaia de calcul, denumită „Raport automat”, este cheia pentru a ține pasul cu viteza proceselor noastre. Conține un script care preia toate informațiile din ultimele două file și creează automat un raport de problemă pe placa noastră Jira. Aceasta înseamnă că nu s-au pierdut informații în faza procesului de raportare. Acest lucru previne o mulțime de reprelucrare și face întregul proces mult mai eficient. Scriptul este personalizabil, astfel încât este posibil să adăugați mai multe câmpuri care urmează să fie raportate.

un scurt videoclip care arată ultimele interacțiuni pe foaia de calcul. În fila ” Raport automat „există un buton numit”creare”. Deasupra butonului, există acreditări de utilizator. Apoi, utilizatorul accesează editorul Scrip din meniul Instrumente și apoi este afișată o altă fereastră cu detaliile scriptului. O Scanare rapidă prin script și apoi înapoi la fila „Auto report”, utilizatorul face clic pe butonul „Creare” și scriptul este executat.

Pasul 2: Creați o prezentare de context

pentru a fi eficient, amploarea produsului care urmează să fie testat trebuie să fie foarte bine definită pentru toți cei implicați în procesul de testare. Domeniul de aplicare ar trebui să se limiteze la caracteristica(caracteristicile) adăugată (adăugate) în intervalul de timp sau în ciclul de dezvoltare respectiv. Cu cât oamenii sunt mai clari cu privire la domeniul de aplicare al acelei ceremonii de testare, cu atât mai puțin veți răspunde dacă aceasta este o problemă de eroare sau moștenire. Este deosebit de important să avem această prezentare în cazul în care părțile interesate sau outsideri de echipă participă la testare, deoarece este posibil să nu aibă claritatea pe care o au oamenii din interiorul dezvoltării în sine.

Pasul 3: rezervați o cameră și trimiteți zile de invitație înainte

aranjați o cameră pentru a se potrivi unui grup mare de oameni, în timp ce, de asemenea, minding calendarul oamenilor nu este întotdeauna atât de simplu. Ar putea dura mult timp pentru a se potrivi cu calendarul tuturor sau pentru a avea o cameră suficient de mare disponibilă, așa că rămâneți în față. La invitație, împărtășiți prezentarea contextului împreună cu foaia de calcul bug bash și asigurați-vă că ați dat permisiunea necesară tuturor participanților. Un alt aspect foarte important al loviturilor de bug-uri este timpul. Asigurați-vă că economisiți cel puțin 1h 30m ( o oră și jumătate) pentru a investi în această ceremonie. Poate părea mult, dar nu este atunci când există atât de mulți oameni diferiți care folosesc produsul și interacționează pentru a obține o abordare mai bună a experienței utilizatorului.