Sambata, 9 mai, ne-am intalnit la Cluj Hub sa participam la un hackathon de testare, primul de la TdT Cluj. Ieheeei!!

Cum am ajuns la ideea de hackathon de testare

Acum ceva timp m-am intalnit cu Alex de la ChallengeMe Club care era interesat de servicii de testare pentru a doua versiune a produsului la care a lucrat. El si colegii lui s-au gandit si la crowdsourced testing si asa mi-a venit ideea de a organiza un hackathon de testare la Tabara de Testare.

Optiunea de hackathon de testare mi s-a parut mai potrivita decat crowdsourced testing din mai multe motive:

• Majoritatea participantilor din comunitatea Tabara de Testare sunt testeri de meserie, cu experienta in domeniu si care lucreaza la abilitatile lor de testeri.
• Fiind membri intr-o comunitate care se intalneste fata in fata, putem fructifica avantajul prezentei fizice in acelasi loc a testerilor. Asta inseamna si ca putem comunica mai bine, astfel incat sa nu logam buguri duplicate. Aceasta configuratie colaborativa este foarte folositoare. Atunci cand invatam unii de la altii, ajungem mult mai departe cu testele decat fiecare pe cont propriu. Si mai ales ne ajuta sa facem scenarii in care ne corelam actiunile – aceasta a fost marea mea revelatie si voi reveni asupra ei pe parcursul articolului.
• De multe ori testerii care au participat la meetupurile TdT au cerut evenimente practice. Iar aceasta ocazie a fost perfecta. Pentru asta, am luat framework-ul lui Cem Kaner din cursul de Bug Advocacy numit IMGEA si, in cadrul hackathon-ului de testare, participantii au exersat inregistrarea bugurilor folosind aceasta abordare. IMGEA vine de la Isolate, Maximize, Generalize, Externalize, And say it clearly and dispassionatelly.

Formatul hackathon-ului de testare

Am plecat cu ideea ca adevaratul castig din eveniment sa fie invatarea. Pentru mine a fost important ca motivatia participarii la evenimentele TdT sa fie intrinseca: oamenii sa vina la aceasta intalnire pentru ca ei isi doresc sa invete, sa experimenteze si pentru ca le face placere, nu pentru niste premii. Aceasta motivatie poate fi pe termen lung si se autosustine. Premiile, care au constat in tricouri si agende cu TdT, au venit sa arate aprecierea noastra si nu sa fie o sursa de motivatie in sine. Si au fost pentru toti cei care au participat.

Despre aplicatie

ChallengeMe Club este o aplicatie a unui startup din Statele Unite in care se pot crea provocari (aka Challenges, de genul Ice bucket challenge sau “adevar sau provocare”, cum preferati). Utilizatorii pot crea aceste provocari, iar cei care le dau curs pot incarca dovezi foto si video. De asemenea, utilizatorii pot invita prietenii sa participe la provocari. Este o aplicatie nativa iOS, dezvoltata de Alex si a carui design este realizat de Vlad. Poza de alaturi ii surprinde pe cei doi in timpul hackathon-ului de testare.

Cum ne-am pregatit

Ca si oricare eveniment TdT, si acesta a presupus o serie de pregatiri si implicare din partea facilitatorilor. Asa ca, impreuna cu echipa de facilitatori, am discutat cum sa organizam acest hackathon de testare.

Adina s-a ocupat de coordonarea brainstorming-ului. Apoi, tot ea a preluat sarcina de a comanda carnetelele si tricourile. A configurat si a pregatit telefoanele si tabletele iOS pentru participantii care nu au putut aduce un telefon sau o tableta. S-a ocupat de comandarea mancarii si a gustarilor din timpul evenimentului. I-a trimis lui Alex UDID-urile pentru toate device-urile pentru buildul distribuit prin Crashlytics.

Eu m-am ocupat de discutiile cu cei de la Cluj Hub, de stabilirea intalnirilor cu Alex, de buget si mici cumparaturi. Tot eu am pregatit cafeaua la expresorul de la birou.

Impreuna cu Adina si cu Alex am facut programul si am stabilit niste repere orare, flow-uri de atins in aplicatie.

Simina a cautat in resursele lui Cem materialul care facea referire la IMGEA, framework-ul de logat buguri. Am ales sa mergem pe versiunea din 2008 pentru ca aceasta este versiunea sub licenta Creative Commons. Uterior Cem a lucrat la imbunatatirea acestui framework, care acum poarta numele de RIMGEN.

Ru ne-a creat o instanta de Mantis pe care sa logam bugurile.

Cei de la ChallengeMe Club au acoperit costurile locatiei, a mancarii si premiile pe care le-am dat participantilor.

Cum s-a desfasurat evenimentul

Din discutiile avute cu Alex si cu facilitatorii, am ajuns la urmatarea agenda: sa incepem cu o scurta descriere a Taberei, sa trecem prin framework-ul de logat buguri, Alex sa ne prezinte aplicatia, sa aplicam framework-ul testand aplicatia ChallengeMe Club si apoi sa urmarim impreuna ce am invatat; sa mancam impreuna la pranz si sa rasplatim participantii cu premii simbolice. Cu mici deviatii, le-am realizat pe toate.

Dimineata a inceput cam greu. Pregatirea cafelei a durat mai mult decat am estimat. Apoi, nu toti participantii au ajuns la ora anuntata, asa ca am decalat timpul de incepere cu jumatate de ora. La asta s-au mai adaugat intarzieri din motive tehnice (adaptoarele pentru videoproiector ne-au facut probleme). Dar cu toate aceste intarzieri la inceput, ceea ce a urmat a fost spectaculos.

Am prezentat ce inseamna Tabara de Testare, care e programul, si am trecut la IMGEA. Ne-am uitat la filmul in care Cem prezinta acest framework, dupa care am facut o scurta recapitulare inainte de a incepe.

Alex ne-a prezentat produsul si ne-a dat detalii despre asteptarile lui in legatura cu testarea.

Cea mai interesanta parte din punctul meu de vedere a fost scenariul comun. Discutasem cu Alex despre asta si ne-a zis ca e foarte important pentru el sa afle cum reactioneaza aplicatia cand sunt mai multe persoane pe acelasi challenge si fac diverse actiuni. Asa ca am decis ca primul scenariu de test sa fie facut de noi toti si sa ne corelam actiunile. Unul din participanti a creat un challenge si noi toti am inceput sa facem diverse actiuni in cadrul acestui scenariu. Cel mai util lucru a fost ca puteam sa discutam si sa ne sincronizam testele.

Si bugurile au inceput sa curga. Fiecare participant care nu era sigur de un anumit comportament vorbea cu Alex si cu Vlad (vi-l prezint tocmai pe cel care s-a ocupat de design-ul aplicatiei).

Apoi ne-am impartit in echipe si am testat functionalitati specifice. Fiecare echipa si-a ales o zona de interes. Si aici dovada: Adina care scrie pe flipchart ariile pe care sa ne concentram in timpul care a ramas!

Am incercat sa observ si comportamentul participantilor printre cautarile de buguri. La un moment dat, Cristi a venit cu urmatoarea problema: a schimbat ora de pe telefonul mobil si a vrut sa inteleaga cum ar trebui sa reactioneze aplicatia. I-am auzit pe Alex si pe Vlad discutand intre ei ca nu s-ar fi gandit niciodata la acest scenariu. Ada si cu Alex R au avut si niste sugestii legate de un flow din aplicatie, pe langa diversele buguri pe care le-au identificat. Am surprins si intrebarile lui Gabi puse foarte bine pentru a intelege cum ar trebui sa functioneze algoritmul de castigare a challenge-ului. Am observat-o pe Mihaela care era focusata pe aplicatie. Toti participantii au avut o atitudine foarte faina si au fost concentrati pe ce testau si multumiti de fiecare data cand gaseau un bug. Mi-a placut “cautarea verbala”: “a pus cineva bugul despre x?” si oamenii raspundeau. Din cand in cand aceasta cautare nu returna nici un rezultat, semn ca se putea inregistra un bug fara riscul de a introduce duplicate 😉

Au fost iPhone-uri de la versiunea 4 la 6 + iPad-uri. Am observat si un background la o tableta pe care scria: “Do not upgrade the IOS!” :))

La final am facut o sesiune de debriefing sa urmarim cum am aplicat framework-ul IMGEA. S-au mai clarificat dintre concepte si sper ca participantii au luat cu ei acest framework, ca una dintre abordarile structurate in investigarea si raportarea de buguri.

In timpul debriefing-ului, doi participanti au propus ca o abordare de viitor pentru testarea aplicatiei folosirea unei solutii de crowdsourced testing. Cred ca exista cazuri in care aceasta abordare poate sa fie de ajutor, insa a fost surprinzator pentru mine ca in contextul in care noi faceam ceva mai valoros decat asta, testerii au venit cu aceste sugestii. Mi s-a parut ironic ca eu am incercat sa ii conving pe cei de la ChallengeMe Club sa facem un hackathon de testare in loc de crowdsourced testing, iar unii participanti le-au propus chiar asta. Intrebarea lui Vlad care a urmat acestor comentarii mi s-a parut pertinenta: “Sa inteleg ca nu mai vreti sa testati voi?”.

Ii las pe testeri sa reflecteze la urmatoarele aspecte:

• care e contextul in care crowdsourced testing poate sa fie o optiune in testarea aplicatiilor software
• cat de important e pentru fiecare sa inteleaga contextul si problema inainte sa ofere solutii
• ce valoare a adus hackathon-ul de testare pe care l-am organizat la TdT, poate in lumina noilor informatii prezentate in acest articol

Ce a fost extraordinar, din punctul meu de vedere:

1. Un startup a avut un prim contact cu testarea si a fost ajutat sa isi verifice solutia de catre membrii comunitatii de testare din Cluj.
2. Testerii au avut ocazia sa exerseze practic un framework de investigare si raportare de buguri. Asta e un exercitiu practic pe care membrii l-au cerut.
3. O dovada ca diversitatea grupului de testare aduce valoare. Fiecare participant a avut o perspectiva diferita a aplicatiei si au fost gasite buguri variate.

Provocarea #HackathondeTestareTdT

Organizatori TdT din celelalte orase, am o provocare pentru voi! Ce spuneti, organizam cate un hackathon de testare in Bucuresti, Timisoara si Iasi cu ceea ce am invatat din editia de la Cluj?