Să începem cu un grafic:
Datele au fost extrase folosind Google Trends cu următoarele filtre Worldwide, 2004 Present, All Categories, Web Search.
Ceea ce ne arată acest grafic în legătură cu căutarea pe internet pentru Agile şi SCRUM este o creștere considerabilă, ducând la momentul 2013 când DevOps a început să fie investigat. Pe lângă acest aspect, aţi mai putea observa că: linia pentru Testability este foarte greu de văzut. Se pare că mai nimeni nu este interesat şi de ceea ce este testabil.. De ce situaţia asta? Dacă vorbim despre DevOps, de exemplu, pe lângă schimbarea imperativă culturală, vorbim despre unelte, livrări automate sau scripturi. Dar e important să analizăm și modul cum testăm aceste unelte. Un script de livrare trebuie testat la fel ca orice aplicație software. SCRUM şi Agile vorbesc despre bucle rapide de feedback, testare automatizată. Dacă vrei să automatizezi ceva, sistemul trebuie să îţi permită să o faci.
Dar ce este conceptul de testability? Am ales într-o primă etapă o variantă mai schematizată de răspuns, și mai uşor de înţeles de cine lucrează în dezvoltarea de soft:
Apoi, putem apela la cea mai simplă definiţie din Wikipedia.
“Testabilitatea software este gradul în care un soft … poate fi testat în contextual dat”
Deci primul aspect pe care trebuie să îl luăm în calcul când vorbim despre Testability este contextul. Contextul înseamnă orice începând de la tehnologie până la oameni. Din punctul meu de vedere, este esențial să ia în considerare şi factorul uman. Pentru început, vom analiza acest concept din perspectiva tehnică. Acestea sunt componentele principale care ajută în evaluarea a ceea ce este testabil într-un soft:
Nivelul de control deținut asupra stării unei componente ce urmează a fi testate. (Dacă ai nevoie să testezi ceva trebuie să ai condiţiile pentru a o face.)
Eterogenitatea: Gradul în care utilizarea de tehnologii diferite necesită metode şi unelte de testare diverse (mai multe unelte necesită mai mult timp pentru învăţare).
Automatizarea: Gradul în care testarea automatizată este posibilă. (Dacă există o nevoie pentru automatizare trebuie să existe şi posibilitatea automatizării.)
Gradul în care este posibil să observi rezultatele testării (finale sau intermediare).
Separarea scopului: Gradul în care componenta ce urmează a fi testată are o singură și bine definită, funcţie. (Cu cât mai multe funcții, cu atât mai multe teste de regresie care trebuie făcute și cu atât mai mare şansa să apară o greșeală.)
Înțelegerea: Gradul în care componenta ce urmează să fie testată este documentată sau este auto-explicativă. (E uşor să testezi ce poţi înţelege uşor.)
În primul rând este camuflat. Camuflajul lui este ignoranţa sau indiferenţa. Până la urmă, noi suntem cei care îl facem greu de găsit. Seamănă cu oricare alt bug pentru că este înşelător. Când apare un bug în producţie de cele mai mute ori, credem că am uitat un caz de testare când de fapt nu am luat în considerare dimensiunea de a fi testabil. De foarte puţine ori, testability este găsit drept cauză a bug-urilor sau problemelor. Are picioare lungi pentru că este rapid. Ajunge foarte uşor în producţie mai ales dacă ce ai de testat este plictisitor sau repetitiv şi nu poate fi automatizat.
Ar mai fi multe de spus despre testability: în ce măsură impactează durata testarii, cum îi îmbunătăţeşte precizia. Dacă vrei să afli mai multe, îţi recomand ca punct de plecare Heuristics of Software Testability by James Bach.
Testability este un principiul al testării, şi cine nu are principii are bug-uri în producţie.
de Ovidiu Mățan
de Vasile Boris
de Paul Hrimiuc
