Agile Testing – manifest

Agile Testing – manifest
In cadrul unuia din training-urile mele cineva m-a intrebat “Cum pot testerii sa supravietuiasca intr-un mediu Agile?”. Training-ul era pe o alta tema dar subiectul mi s-a parut unul foarte sensibil si din acest motiv m-am decis sa scriu textul de mai jos. Cred ca putem sa gasim raspunsuri la aceasta intrebare in cartea “The Testing Manifesto” scrisa de Karen Greaves si Samantha Laing ca o analogie la faimosul Agile Manifesto.

Agile_Testing_Manifesto_1.jpg

Pare interesant, dar este nevoie de mai multe explicatii. Puteti sa gasiti mai multe detalii in cartea “Growing Agile” scrisa de Greaves si Laing. Testarea Agile nu este testare traditionala dar in sprinturi ci o abordarea care trebuie sa schimbe complet modul in care echipa gandeste.

Punem pret pe testarea de-alungul proiectului in locul testarii la final de proiect

In mod traditional testarea este vazuta ca o etapa care se intampla la finalul procesului de dezvoltare. Insa in Agile testarea nu este o etapa ci o activitate care trebuie sa se intample in acelasi timp cu programarea, documentarea si restul activitatilor.

Daca exista coloane separate pentru testare pe task boards aceasta este un semn clar ca activitatea de testare este in continuare vazuta ca o etapa si activitatea testerilor este separata de munca restului echipei.

Agile_Testing_Manifesto_2.jpg

Agile coaches Karean Greaves si Samantha Laing recomanda o abordare diferita si anume ca sarcinile legate de testare sa treaca prin aceleasi etape ca restul de sarcini - "To Do", "In Process", "Done."

Puteti sa adaigati inca o coloana pentru verificarea sarcinilor daca vreti sa treceti la urmatorul nivel. Scopul acestei coloane este sa asigure faptul ca fiecare sarcina este revizuita de un alt membru al echipei imediat dupa ce este terminata. Peer reviews, chiar si cele minore, pot sa fie utilizate pentru programare, documentare sau test cases.

Agile_Testing_Manifesto_3.jpg

Punem pret pe prevenirea defectelor si mai putin pe descoperirea lor

“Cea mai mare victorie este cea care nu necesita o batalie” – acest proverb este atribuit lui Sun Tzu. L-am folosit pentru ca acelasi lucru se poate spune si despre bug-uri: prevenirea defectelor este mai importanta decat identificarea si corectarea lor.

Cum putem sa prevenim defectele? In primul rand trebuie sa incepem aceasta activitate cat mai devreme posibil deoarece majoritatea apar in etapa unde ne ocupam de cerinte.

De cele mai multe ori lucrurile decurg asa: oamenii fac presupuneri in legatura cu cerintele si implementeaza acele presupuneri inainte de a le clarifica. Aceste presupuneri sunt clarificate abia in momentul in care software-ul este testat si defectul este gasit. Ar fi mult mai productiv sa clarificam aceste presupuneri inainte de a scrie o singura linie de cod pentru a ne asigura ca toata lumea, client, programator sau tester a inteles acelasi lucru legat de modul in care un anumit software trebuie sa functioneze. Cel mai bun mod de a preveni defectele este sa punem intrebari chiar si intrebari pe care le-am considera stupide si la care toata lumea crede ca raspunsul este evident.

Autorii “Growing Agile” folosesc urmatorul exemplu. O echipa trebuia sa dezvolte un raport care sa arate datele legate de vanzari pe o perioada de 6 luni. Toata lumea credea ca intelege cerintele perfect si ca nu era nevoie de cine stie ce discutii.

Apoi Greaves si Laing s-au decis sa puna urmatorele intrebari:

  • Daca generez raportul pe 1 Februarie, datele din Februarie sunt incluse sau nu? Dar daca generez raportul pe 29 Februarie?
  • Cum ar trebui sa calculam media – medie lunara sau medie pe toate cele 6 luni?
  • Rezultatul acestei medii ar trebui stocat undeva sau calculat atunci?
  • Raportul trebuie stocat undeva sau este creat atunci cand cineva il selecteaza?
  • Pe baza carui camp este calculata media?
  • Cine o sa foloseasca raportul si de ce are nevoie de el?

A devenit clar ca nimeni nu se gandise la aceste aspecte inainte de a incepe implementarea si ca era nevoie de mai multe informatii inainte de a construi raportul. Ganditi-va de cata munca de refacere ar fi fost nevoie si cate defecte ar fi fost create daca se construia software-ul fara a avea raspunsurile la aceste intrebari.

Punem pret pe intelegerea a ceea ce inseamna testarea versus verificarea functionalitatii

Testerii care considera ca rolul lor este sa verifice daca un produs este conform cu specificatiile de cele mai multe ori nu sunt fani Agile. Si singurul lucru pe care il verifica in mod formal este cat de aproape au respectat developerii specificatiile. Acest lucru nu spune nimic despre calitatea unui produs sau daca isi indeplineste scopul.

Daca munca unui tester s-ar reduce doar la asta atunci majoritatea sarcinilor acestuia ar putea sa fie automatizate si nu ar mai fi nevoie de oameni in proces. Mai mult decat atat calculatoarele fac asta mai repede si mai bine, nu se plictisesc si nu au probleme de atentie. In testarea agile acest gen de verificari simple ar trebui automatizate in asa fel incat testerii sa fie liberi sa faca genul de sarcini pe care calculatoarele nu le pot face cum ar fi exploratory testing sau usability testing.

In Agile testerii trebuie sa fie avocatii consumatorilor, trebuie sa inteleaga cat mai bine cine sunt utilizatorii si ce incearca sa obtina in urma folosirii produsului. Testerii ar trebui sa fie reprezentantii clientilor in fiecare decizie de design, pentru a verifica daca caracteristicile sistemului satisfac nevoile reale ale clientilor – nu doar specificatiile.

Cand un client vreau o anumita functionalitate trebuie sa il intrebi “Cum iti vei da seama daca functioneaza?. Acest lucru te poate ajuta sa inteleaga ce vrea cu adevarat clientul.

Mai multe despre testarea Agile in urmatorul articol.

Victoria Slinyavchuk
Consultant on Software Testing

Share the knowledge