Merenje kvaliteta testa automatizacije

Share

Kako ćemo zaista proceniti da je test framework u dobrom stanju? Senior test konsultant, Jana Đorđević iz Endave, ponudila nam je više odgovora na ovo pitanje, i tvrdi da ih se ne treba slepo držati, ali bi njoj zasigurno bilo jednostavnije da kreira ili održava različite framework-e da joj je neko dao baš ove savete pre 10 godina. Dok smo sa njom razmatrali testiranje softvera, postavilo se i pitanje kako proceniti da li je neki framework vredno korigovati, ulagati vreme u njegov oporavak ili pak odbaciti ga i pisati novi od prve linije koda.

Priča o bolesnom test framework-u

Na stolu iskusnog test konsultanta se nalazio izveštaj o stanju postojećeg test framework-a. Dok je tim prelistavao  njegove stranice, po izrazima lica bilo je jasno da vesti nisu dobre. Test framework o čijem se „zdravlju“ vodila polemika je bio u jako lošem stanju. Bilo je potrebno doneti odluku o njegovoj sudbini.

„Špageti kod“ je, kao i svaki takav, bio teško čitljiv. Javljali su se „flaky“ testovi, koji su u jednom momentu prolazili, u sledećem padali. Identični delovi koda su se pojavljivali na dosta mesta. Postojeće metode nisu potpuno jasno govorile čemu služe. Generički nazivi testova su izazivali dodatnu brigu. Kada bi test pao nije se sa sigurnošću moglo reći u čemu je tačno problem i na kom mestu. Sama analiza rezultata je oduzimala isuviše vremena. Na hiljade linija koda, a samo nekoliko dana je preostalo za odluku.

Ipak, sve to nije bilo veliko iznenađenje. Aplikacija je menjala i namenu i korisnike, a njen istorijat je bio jako dug. U tom vremenskom periodu menjali su se ljudi koji su radili na framework-u, samim tim su i njihove veštine i znanja bila različita. Jasno je da je inicijalnu zamisao bilo teško ispratiti. Dodatni razlog za ovakav nered bila je i promena tehnologije. Spregnutost koda činila je framework nepodobnim za izmene. Svaka izmena bi izazvala domino efekat i potrebu za prepravljanjem ostalih metoda ili testova u cilju zadržavanja istih funkcionalnosti. Održavanje je postalo noćna mora. Menadžeri vođeni pogrešnim motivima su forsirali ulaganje u razvoj novih testova, zarad održavanja framework-a. Odlagali su refaktorizaciju iznova i iznova za sledeći sprint, jer su druge stvari uvek bile prioritet. U početku je tolerisana neoptimalnost testova, iako spori, bili su tačni. Vremenom se broj takvih testova uvećao i izvršavanje regression-a je zahtevalo sve više vremena. Pored svega, semi-automatizacija je stupila na scenu, fajlovi za upload su podmetani ručno, zatim puštane skripte i ručno beleženi rezultati. Ovo je za posledicu imalo sve intenzivniju upotrebu manuelnog testiranja, a time i produženje release ciklusa. Održavanje samog framework-a je bila svačija i ničija odgovornost. Testovi su padali, jedan po jedan, dok po svemu sudeći nije nastupila tehnička smrt framework-a. Odluka je bila jasna, praviće se novi test framework od nule.

Test Framework zdrav kao dren

Prva faza je bila planiranje. Zajedno sa kolegama koje su imale iskustva na sličnim ili istim projektima potražila je odgovore na pitanja šta će se testirati, šta ne, čemu će aplikacija služiti, ko su njeni korisnici, kao i na pitanje ko će koristiti test framework. Oformili su tim koji ima potrebna znanja i veštine, uz to svima im je bilo potrebno da ponešto novo nauče. U realizaciju su uključili Product Owner-a, programere i DevOps inženjere. Razmotrili su kako sve da uvežu u CI (Continuous Integration) lanac. Product Owner-u i projekt menadžeru su stavili do znanja koliko je važno da test framework bude održavan i da je to prioritet. Odredili su člana tima koji će biti zadužen za održavanje i praćenje zdravlja framework-a. Biznis analisti su im dali jasnu sliku u kom pravcu će se aplikacija razvijati. Obavezali su se da će unapred planirati i obaveštavati tim na vreme o promenama u aplikaciji, koja se testira. Ovo su bili odlični temelji za građenje zdravog framework-a.

Kako se framework razvijao tako je rasla i pokrivenost testovima aplikacije. Inicijalno, testovima su pokrivene sve bazične funkcionalnosti, a iz sprinta u sprint razvoj svih novih funkcionalnosti je pratila automatizacija. Kako je vreme  izvršavanja automatizovanih testova značajno kraće od vremena potrebnog za ručno testiranje, EMTE (Equivalent Manual Test Effort) je postajao sve bolji. Pisanje novih testova je zahtevalo sve manje zahvata u test  framework-u, i postajalo je sve brže. Metode su pisane tako da budu pozivane što više puta. Sve više koda je bilo u  framework-u, a sve manje u samom testu. Pokrivenost aplikacije testovima je eksponencijalno rasla tokom vremena, jer je sve manje i manje vremena bilo potrebno za dodavanje novih testova. Bilo je potrebno samo pozvati metodu i data set. Ponovna upotreba koda je bila na visokom nivou. Poštovana je konvencija naziva testova, a čim bi test pao, odmah bi stupili u analizu. Sada je to bilo daleko jednostavnije, i tačno se znalo gde je potencijalni bag. Ukoliko bi se ispostavilo da je zaista u pitanju greška u kodu, odmah bi otvorili bag koji bi ubrzo bio rešen. Međutim  ako je rezultat testa bio lažno pozitivan, sam test bi bio ažuriran. Pouzdanost je bila na zavidnom nivou, u terminima  razlike procenta svih testova i procenta „false positive“ (lažna uzbuna) testova. „False negative“ testova nije bilo, jer su testovi pisani tako da tačno jedan niz koraka i validacija čini da test prođe. Dobrom organizacijom framework-a, vreme potrebno novom članu tima za pronalaženje artefakata (metoda, test izveštaja, konektora za bazu, jarova koje framework kreira i dr.) je bilo veoma kratko. Rezultat regression testiranja je bio relativno brzo dostupan, ali i dalje su želje tima bile idealnih nekoliko minuta. Sa ovakvim test framework-om nije bilo šanse da imaju bag, a da to ne znaju. Kod samih testova je bio čitljiv i lak za razumevanje, čak i onima koji nisu imali previše iskustva u kodiranju. Korišćenjem back door-ova, zarad povećanja testabilnosti aplikacije, postigla se nezavisnost testova od  stanja  prethodnog testa. Ovako napisane testove je bilo lako izvršavati u paraleli. Svaki test je testirao tačno jedan scenario. Precizno su bili određeni podaci sa kojima će se raditi, korišćeni su mock-ovi i stub-ovi radi nezavisnosti od drugih delova sistema. Dobra praksa koje su se držali, međusobono proveravajući pull request-ove i učenjem iz njih, rezultovala je novim idejama za unapređenje framework-a. Kvalitet koda i koding standardi bili su na visokom nivou, jer je tim koristio i alate za statičku analizu koda. Sve metrike su ukazivali na jedan jako kvalitetan test   framework.

Napredak je jasno dokumentaovan. Od prvog koraka je zapisano sve, razlog i način. Uvođenje novog člana tima u automatizaciju, što jeste neka vrsta testa kvaliteta framework-a, prolazi jako glatko – fidbek je bio jasan, framework   je „pucao od zdravlja“. Na kraju, postavilo se pitanje ko testira naše testove. Uz konsultaciju sa programerima, uvedeni su unit testovi za test framework koji će garantovati njegovu stabilnost. Sa ponosom su gledali izveštaje, koji su ih čekali nakon pauze za ručak. Framework je obavljao samostalno veliki deo posla, štedeo je vreme i fokus članova tima.

Meetup – Endava, Beograd

Stvorila se potreba i želja da se ovakva iskustva podele sa test zajednicom. Pred neočekivano velikim brojem kolega, 20. februara 2020. Jana je započela temu: „How do you measure quality of test automation?“, dok su organizatori nizali još dva-tri reda stolica kako bi se svi gosti udobno smestili.

Slavica Mastilovic Sulica Tekst Slika 1

Na beloj tabli je istaknuto stajao Slido preko koga su svi učesnici meetup-a mogli da se uključe u diskusiju, postave pitanja Jani ili odgovore na njena pitanja. Na ekranu su pitanja počela da se nižu i pre nego što je poželela gostima dobrodošlicu. Nakon skoro dva sata izlaganja, novih saznanja i informacija je bilo neverovatno mnogo. Objasnila je šta su simptomi bolesnog, a šta zdravog framework-a, šta su dobre metrike i odgovorila na gomilu pitanja. Posle svega je i dalje bilo onih koji su nestrpljivo čekali ispred Endavine sale da postave još po neko pitanje i razmene iskustva.

Snimak celog meetup-a možete pogledati ovde.

Tagovi:  #automatsko_testiranje_softvera   #framework_za_testiranje   #kvalitet_testa   #qa   #quality_assurance   #testing   #testiranje_softvera

Share

Prijavi se da prvi dobijaš nove blogove i vesti.

Оставите одговор

Slavica Mastilović Sulica

Software Tester @ Endava
mm

Slavica se priključila Endavi kao QA praktikant, gde je napredovala do pozicije Junior testera. Poslednjih nekoliko godina radi i kao profesor matematike i informatike u državnoj i privatnoj školi, uključujući i školu za nadarenu decu. Pohađala je više sertifikovanih kurseva Oracle akademije, među kojima su SQL, PLSQL i Java programiranje. Kada ne testira software, uživa u isprobavanju novih ukusa i jela različitih nacionalnih kuhinja, a rado posećuje javne događaje u kvalitetnom društvu.

Prijavi se da prvi dobijaš nove blogove i vesti.

Категорије