Într-un context DevOps, testarea a evoluat și va continua să evolueze trecând de la un rol făcut de o singură persoană la taskuri de testare făcute de toată lumea din echipă. Motivul pentru o astfel de schimbare este dat chiar de scopul principal al unei echipe DevOps , care este acela de a găsi cea mai rapidă cale de la o idee către lansarea acesteia în producție. În acest context, pentru a avea un produs de calitate și cu cât mai puține defecte, gata de lansare în orice moment, trebuie ca toată lumea să includă testarea (în diverse forme) în responsabilitățile de zi cu zi. Pe scurt, toată lumea trebuie să facă testare într-un astfel de mediu. Aceasta este prima transformare a testării.
Într-un astfel de mediu de tip "Continuous Everything" singurul mod de a obține un astfel de proces este prin dezvoltarea testării automate pe toate nivelele produsului (de la unit testing la acceptanță). Testarea automată presupune cunoștințe tehnice cel puțin medii (programare, arhitectură, baze de date, etc.) și, prin acoperirea tot mai mare și preluarea unor taskuri de la tester, deschide calea acestuia de a se orienta spre o înțelegere mai bună a utilizatorului sau grupului țintă căruia îi este adresat produsul dezvoltat.
Transformarea unui rol atrage după sine foarte multe consecințe care afectează echipele sau oamenii. Este în același timp și un moment oportun de a identifica noi direcții de pregătire și o ocazie bună să definim cine și ce trebuie să știe pentru a asigura o calitate bună a produselor dezvoltate.
Mai departe, analizăm două posibile riscuri ridicate de această transformare, care pot avea un impact semnificativ în rezultatele unui proces de testare. De asemenea, vom lua în considerare și propuneri de temperare a acestora.
Primul risc se referă la subiectivismul și erorile de logică care influențează modul în care se alege ce se testează sau cu ce valori se testează sau strategia de testare.
Al doilea risc îl reprezintă posibila lipsă de claritate în ce privește rolul testerului într-o astfel de echipă în care mai multe persoane fac testare ca parte a jobului de dezvoltare sau de administrare.
Subiectivismul este generat de fluiditatea rolurilor în echipele DevOps, mai exact de trecerea la testare automată și integrarea testerului în echipa de dezvoltare și de complexitatea utilizatorilor sau soluțiilor implementate.
Într-un mediu în care toată lumea face testare, există o probabilitate mare ca scenariile alese să fie afectate de erori de logică sau de subiectivism. Ce înseamnă asta? Poate însemna, de exemplu, că persoana care dezvoltă o anumită componentă va tinde să aleagă scenarii de testare care vor demonstra că implementarea făcută este corectă. Ceea ce este foarte diferit de a testa corectitudinea implementării. Este o situație normală care se poate întâmplă unui programator, unui inginer de sistem, unui administrator de rețea și în general oricărei persoane care construiește un sistem și apoi dorește să verifice sistemul respectiv.
O listă posibilă de cauze include distorsiunile cognitive și erorile logice. Majoritatea duc la decizii rapide și involuntare care afectează procesul de analiză sau de generare de idei chiar înainte ca acesta să înceapă. În mod concret, alegerea unui scenariu de testare este predeterminată de acești factori și scade probabilitatea găsirii unui defect.
Aceasta presupune ca toată echipa să aibă cunoștințe, cel puțin de bază, despre tipuri de testare și tehnici de design ale testelor. Cu o concentrare sporită pe înțelegerea cât mai bună a cazurilor în care o tehnică sau alta este mai eficientă, atât în situațiile generale, cât și în cele specifice domeniului din care face parte produsul/serviciul dezvoltat.
Această învățare este importantă pentru că fără aceste concepte, unei persoane îi este greu sau imposibil să aleagă un design eficient din posibilități pe care nu le înțelege. Cel mai probabil este să execute doar testele pe care le înțelege, ceea ce înseamnă un risc mai mare să atingă doar o anumită categorie de bug-uri. Această situație este cunoscută, la modul general, sub denumirea de "availability heuristic" și a fost studiată de către Daniel Kahneman și Amos Tversky începând cu 1960 [Gilovich, Thomas; Griffin, Dale; Kahneman, Daniel (2002-07-08). Heuristics and Biases: The Psychology of Intuitive Judgment].
Așadar, prima recomandare este ca toată echipa, indiferent de rolul pe care îl are (mai ales într-o echipă multi funcțională) să treacă printr-un training de testare.
Învățarea de statistică și probabilități pentru diminuarea efectelor prejudecăților
A doua recomandare înseamnă învățarea/aprofundarea probabilităților și matematicii (în special lucrul cu mulțimi/grupuri și matrice).
Motivul acestei recomandări ține chiar de modul în care se aleg cazurile sau valorile cu care se testează. Deseori se aleg doar valorile cele mai probabile pentru dezvoltatorul sau testerul care urmează să scrie scenariul de testare, ceea ce este o greșeală pentru că ar trebui alese cele mai probabile cazuri pentru grupul de utilizatori care vor folosi aplicația. Acesta este doar un exemplu în care subiectivismul, erorile logice și silogismele afectează posibilitatea de a descoperi erori relevante pentru utilizatori.
Ceea ce am descris mai sus este util mai ales pentru scrierea testelor automate (sau automatizate?). Dar dacă se execută doar testare automată, atunci se ajunge din nou într-o situație interesantă: când există un număr mare de utilizatori este foarte probabil ca unii dintre ei să facă acțiuni foarte creative, diverse prin aplicație. De obicei, astfel de acțiuni/cazuri nu sunt luate în considerare de testarea automată și în multe situații sunt foarte greu de automatizat.
În această situație, soluția este testarea bazată pe experiență în care cel care testează are libertatea de a fi creativ, de a genera cazuri de test ciudate, paradoxale, puțin probabile și de a-și explora mai mult curiozitatea în direcția lui "Ce-ar fi dacă ...?".
Înțelegerea nevoilor de bază ale utilizatorului este un element esențial într-o echipă DevOps care are ca scop să parcurgă cât mai repede și cât mai bine drumul de la o idee/cerință de business la o lansare cu succes.
În această situație, alegerea cazurilor de testare, a metricilor de acoperire, devine în mod necesar legată de capacitatea testerului de a înțelege cât mai bine nevoile utilizatorului și de a decide cea mai mică arie de testat ce asigură cea mai mare acoperire de riscuri (zone predispuse la erori).
Rolul testerului ar trebui să evolueze mai ales către o specializare în testarea bazată pe experiență, generarea creativă de cazuri de test și înțelegerea foarte bună a utilizatorilor produsului dezvoltat.
Pe măsură ce instrumentele de testare vor evalua, testarea automată va ajunge și ea să fie făcută cât mai repede și complet integrată în toate fazele și nivelele unui produs indiferent de metodologia de implementare.
În acest context, pentru a avea o viteză mare în implementarea și lansarea unor soluții IT, a fi tester devine un job strategic.
de Mihai Varga
de Călin Diniș , Mihai Tentis
