Risk Analysis in Software Testing cu James Bach

Meetup-ul din octombrie 2016 de la Tabara de Testare Cluj a fost unul special: content owner a fost James Bach care a tinut o prezentare despre Risk Analysis in Software Testing.

In pregatirea pentru cursurile pe care le tine pentru testeri, James a incercat cu participantii un exercitiu privind riscurile, analiza lor si implicatiile pe care le au in testare. James si participantiiau cautat i dei de test pentru o masina autonoma de nivel 4, apoi au comparat notitele. Ce a iesit? Va lasam sa descoperiti singuri:

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