Uobičajene zablude automatizacije testa

U ovom ćemo članku ispitati neke od najčešćih zabluda o automatizaciji ispitivanja i kako one sprječavaju organizacije da uspiju u automatizaciji ispitivanja.

Nije teško zamisliti blagodati automatiziranog testiranja uz razvoj proizvoda - brža izdanja, povećana pokrivenost testima, često izvršavanje testova, brže povratne informacije razvojnom timu, samo da nabrojimo neke, ali mnoge organizacije nisu poduzele taj korak ili su otporan na ulaganje u automatizaciju ispitivanja.

Test zablude automatizacije

Vjerojatno najteži i najizazovniji aspekt bilo kojeg pothvata automatizacije jest razumijevanje ograničenja automatiziranog testiranja i postavljanje realnih ciljeva i očekivanja kako bi se izbjegla razočaranja. Imajući to na umu, pogledajmo neke od najčešćih nesporazuma i mitova o automatizaciji testova:

Automatizirano testiranje je bolje od ručnog testiranja

Pozivajući se na post na blogu Michaela Boltona Testiranje naspram provjere , automatizirano testiranje zapravo nije testiranje. To je provjera činjenica. Kad razumijemo sustav, to razumijevanje možemo provesti u oblicima provjera, a zatim pokretanjem automatiziranih provjera potvrdimo svoje razumijevanje. S druge strane, testiranje je istražna vježba u kojoj želimo istraživanjem dobiti nove informacije o sustavu koji se ispituje.

Testiranje zahtijeva da čovjek dobro prosudi o upotrebljivosti sustava. Anomalije možemo uočiti kad nismo predviđali. Ne bismo trebali biti popustljivi prema jednima ili drugima, jer su obje metode potrebne da bi se dobio uvid u kvalitetu prijave.

Postizanje 100% automatiziranog testiranja

Kao što ne postoji praktičan način postizanja 100% pokrivenosti testom (zbog beskrajnih mogućih permutacija), isto vrijedi i za automatizaciju ispitivanja. Pokrivenost testovima možemo povećati izvođenjem automatiziranih testova s ​​više podataka, više konfiguracija, pokrivajući čitav niz operativnih sustava, preglednika, ali postizanje 100% još uvijek je nerealan cilj. Što se tiče automatiziranog testiranja, više testova ne znači nužno bolju kvalitetu ili veće samopouzdanje. Sve ovisi o tome koliko je dobar test osmišljen. Umjesto da ciljate na potpuno pokrivanje, usredotočite se na najvažnije područje funkcionalnosti koje je presudno za poslovanje.



Brzi povrat ulaganja

Kada implementiramo rješenje za automatizaciju testa, postoje i druge međusobno povezane razvojne aktivnosti, a ne samo skriptiranje test slučajeva. Obično treba razviti okvir koji može podržati dogovorene operacije koje su korisne i značajne za poslovanje, poput odabira testnog slučaja, izvještavanja, upravljanja podacima itd.

Razvoj okvira je samostalni projekt i zahtijeva vješte programere i treba vremena za izgradnju. Čak i kada je postavljen potpuno funkcionalni okvir, skriptiranje automatiziranih provjera u početku traje duže od ručnog izvršavanja istog testa. Stoga kada su nam potrebne brze povratne informacije o novoj značajci koja je upravo razvijena, ručno provjeravanje obično je brže od automatizacije testa. Međutim, ROI se vraća dugoročno kada trebamo provoditi iste testove u redovitim intervalima.

Veća stopa otkrivanja nedostataka automatiziranim provjerama

Iako su mnoga rješenja za automatizaciju dobavljača koja se isporučuju iz vlastite proizvodnje i koja su domaća, vrlo sofisticirana i vrlo sposobna za izvođenje složenih operacija, nikada se neće moći natjecati s inteligencijom ljudskog ispitivača koji može primijetiti neočekivane anomalije u aplikaciji tijekom istraživanja ili izvršavanje skupa skriptiranih testova protiv testiranog sustava. Ironično je što ljudi očekuju da će automatizirano testiranje pronaći puno bugova zbog navodno povećanog pokrivanja testovima, ali u stvarnosti to nije slučaj.

Istina, automatizirani testovi dobro pronalaze probleme s regresijom - nakon što je nova značajka dodana u postojeću bazu koda, moramo osigurati da nismo pokvarili trenutnu funkcionalnost i da nam trebaju te informacije brzo - ali, broj problema s regresijom, u većini slučajeva obično je daleko manje od nove funkcionalnosti koja se razvija.

Treba imati na umu i to da automatizirane provjere provjeravaju samo ono što je programirala provjeravati osoba koja je napisala skriptu. Scenariji su dobri kao i osoba koja ih je napisala. Sve automatizirane provjere mogu sretno proći, ali glavne nedostatke mogu proći neprimijećeno što može stvoriti lažni dojam o kvaliteti proizvoda. U osnovi provjera može dokazati postojanje nedostataka, ali ne i njihovu odsutnost.

Zahtijevamo samo automatizaciju jediničnog ispitivanja

Dakle, ako je vjerojatnost pronalaska nedostataka veća kod testiranja novih značajki, zašto ne bismo pokrenuli naše automatizirane testove protiv nove funkcionalnosti kako se razvija? Pa, ovo je donekle slučaj s timovima koji vježbaju TDD .

Programeri prvo napišu jedinični test, gledaju ga kako ne uspijeva, a zatim napišu dovoljno koda da prođu jedinstveni test i ciklus se ponavlja dok se ne isporuči željena funkcionalnost. U osnovi, ovi automatizirani jedinični testovi provjeravaju novu funkcionalnost i s vremenom čine jedinstveni regresijski paket koji se izvodi više puta kako se nova funkcionalnost isporučuje.

No, tu postoji upozorenje. Iako se TDD jako potiče i snažna je razvojna praksa u kvaliteti gradnje od temelja, jedinični testovi samo su dobri u pronalaženju pogrešaka programera, a ne kvarova. Puno je veći aspekt ispitivanja koji se događa kada su sve komponente povezane i čine sustav.

Zapravo, mnoge organizacije imaju većinu svojih automatiziranih provjera na sloju korisničkog sučelja sustava. Međutim, skriptiranje automatiziranih provjera za korisničko sučelje ili sustav, dok se značajke razvijaju, u najboljem je slučaju zastrašujući zadatak, jer nova funkcionalnost tijekom razvoja može biti nestabilna (podložna mnogim promjenama). Također, očekivana funkcionalnost možda neće biti poznata kasnije, pa se ne potiče trošenje vremena na automatizaciju promjene funkcije.

Zahtijevamo samo automatizaciju korisničkog sučelja sustava

Postoje vrijednosti u pokretanju automatiziranih provjera na razini korisničkog sučelja i sustava. Uvidimo što korisnik doživljava u interakciji s aplikacijom; možemo testirati protoke od kraja do kraja i 3rdstranačka integracija kada nismo mogli testirati drugačije; također možemo demonstrirati testove klijentima i krajnjim korisnicima kako bi mogli steći osjećaj pokrivenosti testovima. Međutim, oslanjanje isključivo na automatizirane provjere na sloju korisničkog sučelja ima svoje probleme.

UI se neprestano mijenja radi poboljšanja vizualnog dizajna i upotrebljivosti, a automatske provjere ne uspiju zbog promjena u korisničkom sučelju, a ne zbog promjena u funkcionalnosti, može stvoriti lažni dojam o stanju aplikacije.

UI automatizirane provjere također su mnogo sporije u brzini izvršavanja nego na jedinici ili API sloju i zbog toga je povratna petlja timu spora. Može proći nekoliko sati prije nego što se kvar uoči i prijavi natrag programerima. A kad nešto pođe po zlu, analiza uzroka traje dulje jer nije lako uočljivo gdje se nalazi greška.

Razumijevanje konteksta svakog testa i na kojem sloju test treba automatizirati je važno. Automatizacija testa trebala bi biti dio razvojne aktivnosti, tako da je čitav tim odgovoran za automatizaciju testa, a programeri pišu izvršavanje jediničnih testova, a programeri softvera u testu koji izvršavaju i održavaju testove prihvaćanja na API-ju i / ili korisničkom sučelju.

Gubljenje vjere i povjerenja u automatizaciju ispitivanja

Ovaj posljednji nije mit o automatizaciji ispitivanja, već nuspojava kada automatizacija testa pođe po zlu. Provodite mnogo sati razvijajući savršeno rješenje za automatizaciju testa, koristeći najbolje alate i najbolje prakse, ali ako automatizirane provjere ne pomažu timu, to je bezvrijedno.

Ako tim nema vidljivosti ili znanja o tome što se automatizira i izvršava, ili puštaju sa strahom od nepoznatog ili dupliciraju svoje napore regresijskog testiranja. Ako su automatizirane provjere nesigurne, spore, daju isprekidane rezultate, to može zbuniti tim više od pružanja sigurnosne mreže i jačanja samopouzdanja.

Ne bojte se uklanjanja automatiziranih provjera koje uvijek propadaju ili daju nedosljedne rezultate. Umjesto toga, težite čistom i pouzdanom nizu testova koji mogu dati točne naznake ispravnosti aplikacije.

Zaključak

Test automatizacija dugoročno je ulaganje. Trebat će vremena i stručnosti u razvoju i održavanju okvira za automatizaciju ispitivanja i automatiziranih skripti. Automatizacija ispitivanja nije jednokratni napor kada isporučite rješenje i pustite ga da radi. Potrebno je stalno praćenje i ažuriranje.

Umjesto da namjeravamo zamijeniti ručne provjere kvalitete ili očekivati ​​da će automatizirane provjere pronaći puno nedostataka, trebali bismo umjesto toga prihvatiti prednosti koje tim donosi, kao što je oslobađanje vremena osiguranja kvalitete za više istraživačkih ispitivanja gdje su šanse za otkrivanje nedostataka povećane, ili korištenje automatiziranih skripte za stvaranje testnih podataka koji se mogu koristiti za ručno testiranje.

Razumijevanje ograničenja i postavljanje realnih očekivanja važno je za prevladavanje ovih mitova o automatizaciji ispitivanja.