In acest articol vom continua analiza noastra a principiilor de testare din The Testing Manifesto scris de Samantha Laing si Karen Greaves:

Punem pret pe construirea celui mai bun sistem versus a incerca sa il stricam

Acest principiu imi aduce aminte de urmatoarea poveste haioasa:

Un tester vine la interviul pentru un job. Cand intra in camera intervievatorul arata catre un scaun si ii spune sa ia loc. Cand acesta se aseaza scaunul se rupe. Moment in care intervievatorul ii spune “Felicitari, esti angajat!”

Este o poveste amuzanta dar este departe de ce se intampla in realitate. Desi exista o prejudecata ca rolul unui tester este in principal acela de a incerca sa strice sistemul, acest lucru nu este chiar atat de adevarat.

Intr-adevar oamenii care au aceste roluri sunt genul carora le place sa strice lucruri si sa gaseasca defecte. Un tester poate sa joace rolul unui utilizator care este orientat pe a gasi greseli in sistem dar acesta este doar unul din aspectele acestui tip job.

Testarea software pozitiva este la fel de importanta (daca nu chiar mai importanta) ca testarea negativa. Uneori testerii software, in special cei aflati la inceput, sunt prea entuziasti in a folosi teste negative: Ce s-ar intampla daca introducem 15 fractii? Ce s-ar putea intampla daca introducem un sir de 5000 de simboluri? Ce s-ar intampla daca trimitem un mesaj ce contine doar caractere speciale: "~!@#$%^&*()_+{}:;'`"?><[]""~!@#$%^&*()_+{}:;'`"?><[]"? Toate aceste lucruri sunt fascinante insa trebuie sa tinem minte obiectivul principal – de a dezvolta un produs care are o anumita valoare si care isi executa functiiile asa cum trebuie. Din acest motiv teste pozitive simple cum ar fi sa reproducem ceea ce ar face de fapt un utilizator sunt prioritatea.

Punem pret pe responsabilitatea echipei pentru calitatea produsului versus responsabilitatea testerului

La modul general, in agile faptul ca echipa este responsabila pentru calitate este un principiu fundamental.
Dar cati membrii ai echipei chiar simt aceasta responsabilitate comuna? Cand apare o problema ce faceti voi si ceilalti membri ai echipei? Incercati sa aratati ca altcineva este de vina sau va ganditi la ce ati fi putut face pentru a preveni sau corecta problema?

Daca avem o problema legata de calitate, dam vina pe anumiti testeri sau intreaga echipa isi asuma responsabilitatea?

In cele din urma trebuie sa intelegem ca nu testerii sunt cei responsabili de imbunatatirea calitatii. Ei au rolul de a identifica nivelul de calitate si de a informa partile interesate din proiect de aceste aspecte. Calitatea se atinge cu ajutorul tuturor echipelor implicate in proiect.

Victoria Slinyavchuk
Consultant on Software Testing