Test coverage – urmarirea nivelului de testare

Procesul de testare software in general este unul complex, iar complexitatea sa creste direct proportional cu cea a produselor software analizate. Numarul de functionalitati, feature-urile si posibilitati de folosire sunt si ele in continua dezvoltare, de aceea trebuie sa fim extrem de atenti atunci cand incepem sa testam un astfel de produs, sa urmarim in permanenta nivelul de testare, ce am verificat si ce nu.

Tocmai pentru ca este important sa stim ce am acoperit, ce mai trebuie sa testam si cand, a aparut in teorie si ulterior aplicat in practica conceptul de Test coverage.

Ce reprezinta conceptul de coverage?

Definit destul de simplu, asa cum ii spune si numele preluat din engleza, conceptul de ”coverage” se refera la cat de mult a fost acoperit dintr-un anumit scop. Mai precis, ne putem referi la Code coverage, care este o masura a numarului de linii de cod care acopera din punct de vedere tehnic cerintele de business ale produsului respectiv, sau la Test coverage – masura in care testarea a acoperit pana intr-un anume punct functionalitatile dezvoltate si implementate.

Astfel, conceptul de coverage se aplica atat in zona de Development, unde se dezvolta efectiv produsele software, cat si in cea de testare / QA, unde acestea sunt verificate si validate in vederea asigurarii calitatii pentru clienti.

De ce este nevoie de coverage?

Nevoia de a urmari constant aplicarea practica a conceptului teoretic de Test coverage este destul de simpla, dar extrem de importanta. Aceasta metrica ne releva in ce masura am reusit sa testam un anumit produs, un anumit feature sau o anumita versiune a unei potentiale aplicatii care va ajunge la un moment dat in mediul de Productie, adica la utilizatorii finali.

Prin Test coverage, avem o evidenta foarte clara a ce am reusit sa testam concret, ce mai avem de testat in continuare si sa planificam mult mai detaliat intregul proces de testare, sa prioritizam lucrurile extrem de urgente, si sa nu le omitem pe cele aparent banele dar care pot ascunde bug-uri in spate.

In lipsa unei evidente a notiunii de Test coverage, indiferent de modul, forma sau instrumentele folosite, exista numeroase riscuri care pot afecta semnificativ procesul de testare. In primul rand, exista riscul sa nu mai stim precis ce anume am testat si ce nu, unele functionalitati poate vor fi testate de 2 ori (de doi QA care nu stiau unul de munca altuia si au repetat procesul), iar altele deloc (considerand ca ”sigur s-a ocupat cineva si de asta”), ceea ce este grav intrucat se pot scapa multe defecte catre clienti. In al doilea rand, daca nu avem o evidenta asupra Test coverage, procesul de testare nu va fi eficient nici ca durata, existand riscul sa se depaseasca anumite deadline-uri iar lucrurile sa nu mai fie livrate la timp.

Urmarirea coerenta a conceptului de acoperire a testarii se traduce si in costuri financiare si de resurse mult mai mici din perspectiva rentabilitatii. Atunci cand trebuie sa organizezi si sa distribui eficient resursele, care in orice context sunt limitate, atunci si coverage-ul va fi unul mult mai bun pentru ca resursele umane, de timp si financiare vor fi folosite inteligent, nu haotic, iar rezultatele se vor vedea mult mai clar.

Metode pentru a asigura coverage-ul in testare

Exista mai multe instrumente prin care partea de coverage poate fi monitorizata constant si sa se intervina asupra ei cand e nevoie. Trebuie mentionat ca nu exista o reteta universala despre cum sa se realizeze aceasta metrica, sau o singura modalitate prin care aceasta este transpusa in practica. Exista mai multe solutii, iar partea practica depinde de la o echipa la alta, de la o compania mai mica la alta mai mare si tot asa.

De exemplu, pentru partea de Code coverage unde programatorii vor sa isi urmareasca mai bine munca deja depusa, exista mai multe tool-uri dedicate sau integrate care ii ajuta sa vada exact fiecare commit sau linie de cod, precum Jenkins, JUnit sau chiar IDE-ul Visual Studio Code, ca sa mentionam doar cateva exemple.

Pe partea de Test coverage, o prima metoda mai aplicata de a urmari fiecare cerinta de business si masura in care aceasta a fost verificata practic prin scenarii si cazuri de testare este Traceability Matrix, intalnita sub diverse denumiri (Requirement Traceability Matrix, Test Coverage Matrix etc.).

Aceasta este propriu-zis un document unde sunt sistematizate pe rand fiecare cerinta tehnica / functionalitate / feature si scenariile si/sau cazurile de test care o acopera, astfel incat sa se vada clar cine testeaza ce caz in ce moment si pe care cerinta. Este o metoda destul de buna si unitara pentru a mentine un nivel ordonat de testare, astfel incat toti membrii echipei sa aiba idee unde se situeaza si ce mai au de facut in continuare.

O alta metoda, ceva mai abstracta dar folosita in multe locuri este elaborarea unui Test Plan. Acesta este tot un document, precum Requirement Traceability Matrix, doar ca mult mai elaborat si mai detaliat, care cuprinde mult mai multe detalii legate de procesul de testare: scop, obiective specifice, strategii, tool-urile folosite, metode, dar si componentele care vor fi verificate in cadrul acestuia.

Aici se pot detalia mai exact cum se va granulariza munca totala astfel incat fiecare QA sa stie in ansamblu ce va avea de facut, cum si care sunt limitele de timp. Desigur, daca apar probleme pe parcurs, echipa va sti mai din timp si vor putea reorganiza procesul astfel incat sa nu ramana nimic neacoperit. Test Plan-ul ramane deci un document central fata de care se raporteaza in general validarea aplicatiilor.

Ca sfat general, este important sa maximizam pe cat posibil rata dee coverage a testarii, sa avem in vedere cat mai multe situatii pe care le pot intalni userii mai frecvent sau nu, la scenarii mai recurente sau mai deosebite ca flow de pasi.

Concluzii

In incheiere, conceptul de Test coverage se refera la o metrica ce urmareste nivelul de acoperire in practica a componentelor si feature-urilor unui produs software ce urmeaza sa ajunga la utilizatorii finali. Importanta acestui concept rezida in faptul ca el releva ce anume s-a testat (si cum), si cat a mai ramas de testat, astfel incat sa existe o monitorizare mai clara a task-urilor de testare si a resurselor implicate (umane, financiare, instrumente folosite etc.).

De asemenea, Test coverage-ul ajuta si la depistarea anumitor cazuri de testare care poate nu au fost luate in calcul initial.

Surse consultate si suplimentare

Detalii generale despre conceptul de Test coverage gasesti pe Guru99 si pe BrowserStack

Code coverage vs. Test coverage

Despre Test coverage matrix

Importanta pe care o are Traceability Matrix in testare

Despre Test Plan ca document de testare si coverage