2 editii speciale la Tabara de Testare Bucuresti

In luna noiembrie am implinit 2 anisori!!! Deoarece era o editie aniversara ne-am decis ca aceasta intalnire sa fie una de socializare, sa ne bucuram impreuna de comunitatea pe care ati ajutat sa o cream, sa rasplatim cativa dintre membrii comunitatii mai activi si cu contributii speciale,bineinteles sa facem planuri pentru urmatorii 2 ani si sa ne bucuram de surpriza dulce pe care am avut-o.Ne-am intalnit la Have a Cigar Pub o locatie foarte draguta unde ne-am readus aminte de cateva lucruri pe care am reusit sa le realizam in ultimii 2 ani:

  • 400 membri chiar in ziua editiei aniversare – se pare ca devine o traditie sa ajungem la un numar rotund (anul trecut ajungeam la 300)
  • 26 de intalniri in cei 2 ani de Tabara de Testare Bucuresti
  • Realizarile membrilor Tabara de Testare: premiul pentru cea mai buna prezentare la SeeTest, participarea la concursuri de genul Software Testing World Cup, castigarea de bilete la Eurostar, scris carti despre calitate si lista poate continua.
  • O parte din membrii comunitatii ne-au readus aminte ce le place la Tabara de testare si de ce continua sa vina. Un mic exemplu:“ Eu vad in Tabara de Testare Bucuresti un grup de oameni prietenosi si pasionati de testare, care sunt dispusi sa te asculte si sa te ajute. Inca de la prima intalnire lunara la care am participat am fost incurajata sa ma implic in discutii si datorita lor am gasit raspunsul la unele intrebari ce ma rodeau de mult. ”

Multumim R/GA pentru sponsorizare si pentru toate bunatatile pe care le-am avut la aceasta intalnire.

2 anisori goodies cuttingthecake tdt grouptort

Dar surprizele nu s-au terminat aici, marele “cadou” de 2 anisori venind la urmatorul meetup din decembrie. Am avut placerea de a il avea ca invitat special pe Michael Boltonnu canteretul si nu actorul din “Office Space”, ci faimosul tester.

Cum ne asteptam la o participare foarte mare, intalnirea a avut loc la Tech Hub unde au fost aproximativ 100 de persoane(cea mai mare intalnire de pana acum referitor la numarul de participanti).

Michael ne-a delectat cu o prezentare despre “Masuratori si metrici” in care ne-a adus aminte ca totul incepe de la design si de faptul ca software development nu e o munca de fabrica. Michael a pus accentul si pe faptul ca oamenii au tendinta sa devina fixati pe numere si ca un numar de test case-uri rulate e un numar pe care se pot baza.

Ne-a fost aratat cum testerii ar putea folosi o poveste(descriere) in 3 parti care ar fi mult mai relevanta decat folosirea metricilor si a masuratorilor:

  • o poveste despre statusul produsului – ce face, ce probleme are si cum ar putea sa aiba probleme.
  • o poveste despre cum ai testat – cum ai recunoscut problemele,ce ai testat si nu ai testat, ce nu o sa testezi deloc
  • o poveste despre cat de buna a fost testarea – riscurile si costurile testarii sau de a nu testa, ce a facut testarea sa mearga mai repede sau mai incet, de ce ai nevoie si ce recomanzi.

Michael a continuat cu raspunsul la intrebarea: “De ce masuram”, cu modurile in care masuram precum si cu diferenta intre masuratori si metrici.
Un alt aspect important despre care a vorbit este numararea bug-urilor. Michael a vorbit despre timpul pe care il pierdem pentru a numara bugurile, pe cand am putea sa vedem din ce cauza s-a produs acel bug sau am putea ridica probleme care impiedica testarea.
Dupa cum va puteti da seama, numarul de subiecte atinse a fost mult mai mare decat relatarea mea asa ca va las cu prezentarea care poate fi gasita aici:
Measurements and Metrics .

De mentionat ca intalnirea a durat aproximativ 4 ore si am vrea sa multumim Optaros si TechHub pentru sponsorizare si gazduire.
Michael ne-a promis ca o sa mai vina ca invitat la intalnire noastre si nu putem spune ca de abia il asteptam din nou pe “scena” Tabara de Testare.

testing is the room photo strange ideas michael on stage the room michael 2

Am vrea sa ii multumim si lui Gabi Dobritescu pentru implicarea in Tabara de Testare in ultimii doi ani. Ne va fi dor de tine si ne vedem la Tabara de Testare Londra!!!

Asa ca de sfarsit de an nu pot decat sa va urez un an nou fericit si la cat mai multe impliniri.Ne vedem la anul cu forte proaspete si la cat mai multe intalniri Tabara de Testare Bucuresti.

Andrei Pirvulescu

P.S Prezentarea lui Michael Bolton a fost inregistrata si vom pune linkul in acest blog post.

Principii de testare – un duet reusit

Vara a luat sfarsit si cu ea s-au dus si intalnirile Test and Beer.

Toamna aceasta a inceput cu o premiera. Doi dintre colegii nostri, Dana Aonofriesei si Gabi Dobritescu, si-au unit fortele pentru prezentarea din septembrie.

Avand in spate experiente diferite au abordat o prezentare in paralel a principiilor de testare. Ne-au impartasit viziunea lor asupra fiecaruia, descriindu-ne problemele de care se lovesc si solutiile pe care le-au incercat.

Principiile atinse au fost:

  • Testarea exhaustiva – De multe ori echipele cu care lucram se asteapta la asa ceva de la noi, sau cel putin asta cred. Ce facem in acest caz? Dana ne-a povestit despre cum foloseste pairwise testing pentru a avea o acoperire buna in timp ce Gabi ne-a spus cum planifica si prioritizeaza in functie de timpul pe care il are la dispozitie.
We Have To Test Everything

We Have To Test Everything

  • Oracole folosite in testare – fac testarea mai grea sau mai usora? Cand si cat de des trebuie updatate?
  • Dependenta de context – am primit cateva exemple de cum influenteaza contextul in care va rula aplicatia tipul de problemele care pot sa apara in productie
  • Test to pass vs. test to fail  – un subiect ce a pornit cateva discutii. Ce e prioritar: sa verificam daca aplicatia se comporta conform cu specificatiile sau sa gasim the big, bad, ugly bugs?
  • Inceperea testarii cat mai devreme in cadrul ciclului de dezvoltare – este unul din primele lucruri pe care le aflam despre testare, cum costul unui bug creste cu cat este descoperit mai tarziu in cadrul ciclului de dezvoltare. Si totusi se intampla des ca testerii sa nu fie inclusi in definirea requirementurilor. Am primit de la Dana si Gabi cateva idei interesante despre cum am putea sa convingem echipa sa includa testarea in discutiile initiale.
  • Popularitatea testerului – Sunt mai importante soft skills sau technical skills pentru un tester? Parerile au fost ca de obicei impartite generand noi subiecte de discutie.

Si intalnirea nu s-a terminat aici. Ca de obicei am continuat discutiile despre testare. Multumim Optaros pentru sala si pizza.

Intalnirea din Octombrie este deja stabilita. Detaliile pot fi gasite pe meetup aici. Ne vedem acolo!

Va las cu cateva poze de la intalnire.

Andra Marin

 

Proiect din comunitate si estimari top-bottom

Meetupul nostru din luna mai a fost un pic diferit de celelalte intalniri, incepand cu o scurta prezentare despre un proiect din comunitate. Claudiu Draghia ne-a prezentat pe scurt 2 site-uri, unul dintre ele find practic un motor de cautare in anumite site-uri/bloguri de testare iar cel de-al doilea un RSS feed prezentand ultimele posturi de pe anumite bloguri.

Site-urile sunt urmatoarele:

De asemenea puteti sa lasati si sugestii pentru bloguri pe care le doriti incluse.

Prezentarea principala  a fost tinuta de catre Bogdan Cojocaru si a abordat subiectul “Top-bottom estimations”, practic estimarile care se fac in faza de RFQ/RFP(Request for Quotation/Request for Proposal). Bogdan a inceput prin a ne explica cum folosesti aceste estimari incepand cu Work Breakdown Structure(WBS ) pentru inceput la nivelul 1, unde trebuie sa adaugi intial toate fazele si activitatile majore de testare precum: system testing, integration testing, UAT s.a.m.d. De asemenea ne-au fost oferite si detalii despre ceea ce s-ar putea omite la acest nivel: activitati de suport ale proiectului, presupunerea ca toti testerii au aceleasi nivel de cunostiinte, coordonarea echipei, rapoarte zilnice sau saptamanale, acceptance testing.

La nivelul 2 al estimarilor, dupa cum ne spunea Bogdan, sub fiecare faza de test ar trebui adaugate modulele sau functionalitatile pe care le vei testa. La acest nivel de estimari top-bottom se poate intampla sa nu ai toate informatiile despre modulul respectiv dar pentru a da o estimare cat mai precisa trebuie sa incerci sa afli ce functionalitati are modulul respectiv: search, contact form, s.am.d. La urmatoarele nivele se continua cu breakdown-ul pana la cel mai mic nivel pana cand o estimare este posibila.

O sugestie importanta din timpul prezentarii referitoare la prerechizite si presupuneri a fost: strange informatii…in scris!  Doar atunci vor fi valide 🙂

De-a lungul prezentarii, ni s-au explicat si diferite metode de a folosi estimari corecte: “modjo” generator, peer review sau metoda Most optimistic, most likely, most pessimistic method(the three point estimation) si nu in cele din urma cea bazata pe experienta.

In timpul prezentarii ne-a fost readus aminte sa luam in calcul si faptul ca rularea de teste inseamna si raportarea defectului plus izolarea defectului, sa nu uitam de retestare in calculele noastre, prepararea datelor, review-ul documentatiei.

Beneficiile unei estimari bune in faza de RFQ/RFP nu au fost nici ele uitate si ni s-a adus aminte de faptul ca o estimare buna in aceasta faza te poate ajuta la obtinerea unui contract,  cum o estimare buna in faza de livrare te poate ajuta sa definesti asteptari realiste.

Dupa prezentarea “Top-Bottom estimations” ca de fiecare data au urmat discutii despre testare si despre prezentarile de la intalnirea noastra. Multumim Optaros pentru sala si pizza.

Prezentarile pot fi gasite la urmatorul link

Ne vedem la urmatoarea intalnire,

Andrei Pirvulescu