Problemi s automatizacijom ispitivanja i modernim osiguranjem kvalitete

Koji su neki uobičajeni problemi s automatizacijom testova u agilnim i DevOps-ima?

Suvremeni razvoj softvera i QA previše se usredotočuju na automatizaciju ispitivanja, a nedovoljno na istraživačka ispitivanja.

Objavljujemo li kvalitetniji softver s automatiziranijim testovima? Mislim da ne!

Nedavno sam naišao na objavu na mreži društvenih mreža koja kaže

Ono što danas vidim u većini događaja testiranja i osiguranja kvalitete su uglavnom DevOps, kontinuirana integracija i automatizacija ispitivanja.

Iako je to sve jako lijepo, vidim da je puno usranih test slučajeva automatizirano.



Vidim nekoliko bugova prijavljenih tijekom integracijskih testova i funkcionalnih testova, iako su svi automatizirani.

U UAT-u korisnici pronalaze sve više i više bugova jer ih testni timovi nisu uspjeli identificirati u prethodnim fazama.

Ako ne naučimo ljude kako pisati dobre test slučajeve, završit ćemo s potpuno automatiziranim ...

A moje tumačenje ... je 'sranje'. :-)

U svakom slučaju, da vidimo što je stvarno događa u svijetu moderne provjere kvalitete i automatizacije ispitivanja.

Problemi s modernim osiguranjem kvalitete

Većina 'Test automatizacije' u agilnom razvoju je u zastrašujućem stanju. Softverska industrija ulijeva ogromne svote novca kako bi angažirala 'stručnjake za automatizaciju ispitivanja' uglavnom kako bi stekla osjećaj samopouzdanja da je softver koji grade visokokvalitetan. Ipak, uočljive greške i / ili drugi problemi pronalaze se tijekom UAT-a ili provlačenja u proizvodna okruženja. I što ima?

Bilješka:Pod Automatizacijom testova uglavnom mislim na LUK Test automatizacija.

Automatizirano testiranje sada je u središtu svakog modernog procesa razvoja softvera. Njegova je svrha da Pomozite isporučiti visokokvalitetni softver na ponovljivoj osnovi, ali je li to stvarno?

Da li testeri još uvijek testiraju?

Istina je u tome da u većini agilnih timova testeri više ne testiraju.

Ručno testiranje izgubilo je svoju vrlinu zahvaljujući razvojnim praksama i kulturama poput agilnih i DevOps , koji su stvorili podjelu u QA prostoru - oni koji mogu kodirati i oni koji ne mogu.

Često ćete čuti stvari poput: 'Ja sam 100% inženjer automatizacije' ili '80% automatizacije 20% ručno', ili još gore, 'mrzim ručno testiranje'. Šokantno!

U DevOpsu nas vode do uvjerenja da sve treba automatizirati. Nema mjesta za ručnu intervenciju, na pr. ručno ispitivanje.

Danas se većina testera u agilnom timu bori da održi korak sa zahtjevom 'Test Automation'. Pritisak je potreban da se svaka priča u sprintu automatizira, a nema dovoljno vremena za temeljita istraživačka ispitivanja.

Problem je, posebno u agilnom razvoju, što QA uzimaju korisničku priču i automatiziraju njezine kriterije prihvaćanja. Pritom im je glavni i jedini fokus hrvati se sa svojim ograničenim vještinama kodiranja samo da bi test prošao.

Naravno, ovo stvara uski fokus kada vas zanima samo automatizacija testa i ako vidite kako prolazi u cjevovodu gradnje. To samo dokazuje ono što je bilo u kriterijima prihvaćanja - dobro ili ne - djeluje i skloni ste zaboraviti na veliku sliku.

Pad ručnog ispitivanja

Sve više i više 'tradicionalnih testera' prelazi na 'agilno testiranje' uzimajući neke lekcije kodiranja i postajući sve tehničkiji.

Nemojte me pogrešno shvatiti; ovo je sve dobro. Vjerujem da bismo kao testeri uvijek trebali težiti učenju novih i novih tehnologija kako bismo ostali snalažljivi. Trebali bismo razumjeti tehnološki skup ako želimo testirati sustav na visokom stupnju kvalitete.

Međutim, pravi razlog zašto većina ručnih testera poduzima ove inicijative je taj što postoji uvriježeno mišljenje da je 'automatizirano testiranje' superiornije od ručnog testiranja i hej, kodiranje je zabavno, zar ne?

Bilješka:Ručnim testiranjem jesam NE pozivajući se na stari školski način praćenja skripte i izvršavanja koraka. Mislim na takozvane 'istraživačke testere' - one koji rade pravo testiranje i znatiželjni su ispitati ponašanje sustava vježbajući zanimljive i promišljene scenarije.

Nažalost, čini se da postoji velik pad na tržištu istraživačkih testera. To je sasvim očito. Dovoljno je pokrenuti nekoliko upita za pretraživanje za 'ručni tester' i 'tester za automatizaciju' na bilo kojem web mjestu za posao i sami pogledajte rezultat.

Problemi s automatizacijom ispitivanja

Pogledajmo sada zašto većina napora u automatizaciji ispitivanja ne donosi nikakvu vrijednost.

Uobičajene pogreške koje vidim da se ponavljaju:

  • Pogrešno očekivanje automatiziranih testova
  • Automatizacija testova na pogrešnom sloju, u pogrešno vrijeme i pomoću pogrešnih alata
  • Automatizacija beskorisnih testova
  • Zanemarivanje važnih područja
  • Nedostaju ključni scenariji

Pogrešna očekivanja

Prije nekog vremena napisao sam blog post na zašto biste htjeli automatizirati test ? Ako ga niste pročitali, vrijedi ga pročitati.

Sažetak tog članka je da automatizirate testove koje želite redovito provoditi. Po definiciji, ovo su vaši regresijski testovi koji potvrđuju da sustav još uvijek funkcionira.

Međutim, ako automatizirane provjere pronađu puno problema s regresijom, preispitivat ću vještine programera i razvojni proces. UI automatizirani testovi ne smiju se [održavati na štetu] ili [nadoknađivati] zbog loših kodiranja.

Pogrešan sloj, pogrešni alati i pogrešno vrijeme

Većina 'inženjera za automatizaciju ispitivanja' u agilnim timovima, pogledaju korisničku priču i automatiziraju kriterije prihvaćanja. Većinu vremena to čini kombinacija selena i krastavca.

Moderne web aplikacije sada su jasno podijeljene između pozadine i sučelja. Zaštita se uglavnom sastoji od velikog broja REST web usluga ili API-ja s lako dostupnim krajnjim točkama.

Logika aplikacije može se testirati na API sloju. Međutim, većina inženjera automatizacije ispitivanja pribjegava provjeri valjanosti funkcionalnosti na sloju korisničkog sučelja koji je u najboljem slučaju glomazan.

Postoje alati za testiranje, kao što su Karate i budite sigurni, koji pojednostavljuju API testiranje. Te bismo alate trebali koristiti tijekom razvoja. Nažalost, neki inženjeri automatizacije ispitivanja to uopće ne znaju osnove HTTP-a , a kamoli moći pisati scenarije API testiranja.

Što se tiče automatizacije UI testova, Čempres je izvrstan alat. To je više poput TDD alata za front-end programere. Programeri dobivaju vrlo brzu povratnu informaciju o ponašanju novih komponenata korisničkog sučelja.

I karate i čempres služe kao 'alati za razvojni test', tj. Alati koji vode i podržavaju razvoj. Obje su lagane, lako se integriraju i mogu se pružiti povjerenje u razvoj .

Tada možemo koristiti selenij ili čempres za dizajniranje samo nekoliko scenarija koji izvršavaju sustav od kraja do kraja. Ovi scenariji čine naš lagani regresijski paket i osiguravaju ga povjerenje u kontinuitet poslovanja .

Nerijetko čujem stvari poput 'čekamo dok se značajka potpuno razvije i ne stabilizira, prije automatiziranja testova'. Bilo koji svjesni ispitivač zna da su nove značajke pogrešaka više od regresijskih. Veća je šansa za pronalaženje problema s trenutnom značajkom u razvoju od stabilne značajke.

Ako ćete vrijeme provoditi automatizirajući testove, radite ih paralelno s razvojem kada mogu pružiti veću vrijednost.

Automatizacija beskorisnih testova

Nemojte automatizirati svaki 'test' samo zbog njega. Uključite neki proces razmišljanja u igru. Proučite arhitektonske dijagrame na visokoj i niskoj razini. Pitajte što bi moglo poći po zlu. Ispitajte točke integracije i potražite potencijalne točke neuspjeha.

Zauzmite pristup automatizaciji zasnovan na riziku kao što biste (nadamo se) i sa svojim cjelokupnim pristupom testiranju. Koja je vjerojatnost da nešto ne uspije i kakav je utjecaj kvara? Ako je odgovor visok, tada bi te scenarije trebalo automatizirati i izvršavati u svakoj gradnji.

U svakom sprintu često na kraju napišemo automatizirane testove oko korisničkih priča za taj sprint i zaboravimo na integraciju s drugim značajkama. Postoje ili slabi ili nikakvi testovi integracije.

Sjetite se da automatizacija 'testova' zahtijeva vrijeme. Imajte na umu i da automatiziranjem testa zapravo ne testirate, već samo provjeravate ispunjava li dotična značajka neke kriterije prihvaćanja.

Vas Ne možete automatizirati testiranje, ali možete automatizirati provjeru poznatih činjenica.

Stoga, svaki put kad provedete automatizaciju 'testa', razmislite o vremenu koje gubite netestirajući!

Zanemarivanje važnih područja

Sve više vidim ovaj nemar od rođenja kulture DevOps.

U DevOpsu je cjevovod isporuke, zajedno sa skriptama za implementaciju, kralježnica razvoja i isporuke softvera, no oni se teško ikad testiraju.

U posljednjih nekoliko godina mogao bih lako reći da sam vidio puno više 'problema s okolišem' od funkcionalnih bugova. Problemi s okolinom kao što su problemi s CI poslužiteljem, skripte za implementaciju, testna okruženja itd.

Pitanja zaštite okoliša imaju ozbiljan utjecaj na razvoj i napore na ispitivanju. Oni troše puno vremena za programere i DevOps i masovno usporavaju proces implementacije, no nema obzira na testiranje i na taj način sprječavanje tih problema.

Prihvaćamo ih samo kao dio moderne isporuke softvera.

Ulažemo puno truda u automatizaciju funkcionalnog ponašanja i potpuno zanemarujemo „stvari“ koje su najvažnije. Još je gore što se moramo osloniti na testove selena kako bismo pokazali rade li implementacije ili ne!

Nedostaju ključni scenariji

Scenariji su kralj! Napokon, scenariji su ti koji otkrivaju bugove.

Često ozbiljan problem procuri u proizvodnju, jer nitko nije razmišljao o tom određenom scenariju. Broj izvršenih automatiziranih testova nije važan. Ako scenarij nije smišljen ili testiran, zakon zakona kaže da tamo postoji greška.

Nažalost, u većini agilnih razvojnih okruženja, ne posvećuje se dovoljno sve ove važne aktivnosti „Radionice scenarija“.

Problemi s postupkom

Pogledajmo kako se gore navedeni problemi očituju u tipičnom razvojnom scenariju:

  • Vlasnik proizvoda piše korisničke priče bez ikakvih ili minimalnih kriterija prihvaćanja.
  • Nema dovoljno vremena posvećenog sesijama usavršavanja priče za raspravu o različitim scenarijima za korisničku priču.
  • Kriteriji prihvaćanja tumače se kao ispitivanja prihvaćanja - Da, postoji razlika između njih dvoje !
  • Ispitivači automatiziraju samo kriterije prihvaćanja u korisničkim pričama uglavnom pomoću selena i / ili krastavca.
  • Automatsko testiranje gotovo je uvijek odgovornost „automatiziranih testera“.
  • Programeri nemaju pojma što je obuhvaćeno testnim paketima ili čak ne znaju kako izvršiti automatizirane testove.
  • Automatizirani testovi dodaju se u sve veći 'regresijski paket', pa svaki put izvode sve duže i duže.
  • UI automatizirani funkcionalni testovi integrirani su u izgradnju cjevovoda, što je dobro, ali ...

Programer pokreće jednostavnu promjenu i mora pričekati 30 minuta da automatizirani testovi postanu zeleni prije nego što se nova značajka ili ispravak programske pogreške mogu primijeniti u proizvodnji. Čekanje od 30 minuta je samo ako testovi prođu prvi put. Ako ne uspiju zbog nekih problema s testom ili okolinom, može potrajati duže.

Kako su automatizirani testovi aktivni, a QA istražuje slučajne kvarove, programer i / ili vlasnik proizvoda provjerili su novu implementaciju i rado je objavljuju, ali ne mogu jer izrada nije zelena.

Nakon nekog vremena, ili izrada postaje zelena ili se uprava frustrira neuspjelim testovima i svejedno donosi odluku o puštanju. Zatim, BOOM, nakon nekoliko minuta proizvodnje, došlo je do porasta u 500 pogrešaka poslužitelja.

Kvarovi na infrastrukturi

Čini se da neuspjesi pokazuju sličan obrazac

  • Neuspjeh u integracijskim točkama.
  • Neuspjeh u komunikaciji s aplikacijama treće strane.
  • Web usluge nisu 'gore' i zahtjevi za krajnje točke API-ja ne uspijevaju.
  • Pogrešna konfiguracija na jednom od VM-ova ili čvorova, što rezultira povremenim problemima.

Pa ipak, ne postoji postupak provjere ovih problema kao dio procesa razvoja ili isporuke.

Fokus inženjera za automatizaciju ispitivanja je automatizacija funkcionalnih testova. Nema fokusa na izvedbi, sigurnosti ili elastičnosti. A ispitivanja infrastrukture sigurno nema!

Sažetak

Došlo je vrijeme da se fokus usmjerimo s automatizacije funkcionalnih testova koji imaju male šanse uhvatiti funkcionalne probleme na ozbiljnija i uobičajena pitanja zaštite okoliša koja muče razvoj.

Test automatizacija, ako se učini pogrešno ili bez razmišljanja , je gubljenje vremena i nikome ne predstavlja vrijednost. Otkačeni automatizirani testovi mogu imati velike troškove održavanja i ometati razvoj. Na kraju, jedino rješenje je spremiti testove.

U suvremenom razvoju softvera, većina napora 'Test Automation Engineers' troši se boreći se s kodom za automatizaciju i pokrećući 'testove', umjesto da se usredotoče na pravilno testiranje i istraživanje sustava.

Za pisanje koda za automatizaciju doslovno nema dovoljno vremena i izvršiti istraživačka ispitivanja. Automatiziramo priču za pričom i zaboravljamo na integracijske testove, zaboravljamo na veliku sliku.

Često završimo s izvršavanjem tona automatiziranih testova, no istraživačko testiranje otkriva većinu bugova. Zatim retrospektivno pišemo automatizirani test za greške pronađene istraživačkim ispitivanjem, kako bismo uhvatili regresijske greške.

Trebali bismo biti selektivni u tome što automatizirati i prosuđivati ​​svoju odluku na temelju rizika. Što može poći po zlu, kakva je vjerojatnost da pođe po zlu i kakav će utjecaj imati na korisnika ili tvrtku ako pođe po zlu?

Ako se bavite 'Test Automation', nemojte koristiti Selenium za testiranje funkcionalnosti API-ja ili UI komponenti. Umjesto toga, koristite Selenium za automatizaciju samo nekoliko korisnih i poslovnih kritičnih scenarija kako biste pružili povjerenje u kontinuitet poslovanja prije svakog izdanja.

I na kraju, svaki put kad provedete automatizaciju 'testa', razmislite o vremenu koje gubite netestirajući!

Daljnje čitanje: