Liigu edasi põhisisu juurde
Öine linnavaade

Ära karda testide automatiseerimist

Tanel Tromp

Kas koodivabalt on võimalik teste automatiseerida?

Tänases tööjõuturu situatsioonis võib osutuda üsna parajaks pähkliks leida oma meeskonda inimene, kes on hea testija ning oskab lisaks sellele veel koodi kirjutada, töötamata seejuures arendajana. Mõni aasta tagasi testijana tööd alustades vaatas piltlikult öeldes iga ukse tagant, mis ma avasin, vastu klausel “testide automatiseerimine”.

 

Aina enam räägiti siis, ja räägitakse praegugi, vajadusest luua agiilses arenduses automatiseeritud testide raamistik, mis vabastaks ja säästaks aega ning raha. Mulle kui UX-taustaga töötajale ei tundunud “scriptide” kirjutamine testide loomiseks kuidagi mõistliku ega julgustava väljavaatena, kuigi testimine ise tundus olevat igati põnev ja sobiv  tegevusala.  

 

Niisiis hakkasin otsima tööriista, millega saaksin luua veebilahendustele automaatteste täiesti koodivabalt ning millel oleks lisaks kasutajasõbralik kasutajaliides – tundus loogiline, et minu vajadustega testijaid on rohkem.

 

Mõningate otsingute ja katsete järel erinevate tööriistadega (nt Katalon, Selenium ) jõudsin EndTestini, millel olid olemas just need põhiomadused, mida alustava automaattestide loojana vajasin:

 

  • koodivaba - ei pea oskama koodi kirjutada ja seetõttu on kiire õppimiskõver;
  • kasutajasõbralik kasutajaliides ja selle seadistamine - tööriist on kognitiivselt ja intuitiivselt kiiresti omandatav ning suhteliselt frustratsioonivaba;
  • korralik kasutajatugi – olles hädas tehniliste nüanssidega, ei pea minema foorumisse muret kurtma või Googlest vastust otsima, mis on ajakulukas.

 

Paljude nn vabavaraliste ehk koodivabade automaattestide tarkvarade probleemid on minu hinnangul seotud just kahe viimase nimetatud põhjusega. EndTestiga sain aga kiiresti “kohalt minema” ja esimesed automaattestidki loodud, kuigi mul puudus varasemalt igasugune kokkupuude automaattestimisega.

 

 

Miks teste automatiseerida?

Ei ole suurt vahet, kas olla testija, tooteomaniku, lõppkasutaja või tarkvaraarendaja rollis - testide automatiseerimine on kõigipoolselt väga oodatav tegevus. Lõppude lõpuks on kõigi osapoolte seisukohast äärmiselt frustreeriv olukord, kus “kõik on katki läinud” ja “miski ei tööta enam” ning kõige selle “juhuslik” avastamine, mis võimendab üldist ebakindlust tootekvaliteedi suhtes. 

 

Automaattestide põhisisuks on minu hinnagul olla arenduse käigus tekkivate (uute) vigade avastamisel üks samm eespool lõppkasutajast ja ka tooteomanikust. Sisuliselt jooksutab automaattestimise tarkvara regressioonitestide komplekte, mis kontrollivad, et (lisa)arenduse käigus ei ole tekkinud varasemas koodis vigu.

 

Näiteks kui arendatakse uus sisselogimise meetod, siis varasemad sisselogimise meetodid peavad peale lisaarendust töötama endiselt korrektselt. Käsitsi kõiki regressiooniteste läbi testida on väga ajakulukas ja vaevarikas (suisa demotiveeriv) ning nende kulukuse kõver on püsivalt tõusev ehk projekti suurusega kasvab proportsionaalselt ka käsitestimise kulu.

 

Automaattestidele kuluv aeg aga stabiliseerub ühel hetkel, sest testide hulk küll kasvab, kuid kõik varasemad testid jooksevad “automaatselt”.

"automaattestimise vs käsitestimise kulukuse kasv-kahanemine ajas ehk ROI "

 

Joonis 1: automaattestimise vs käsitestimise kulukuse kasv-kahanemine ajas

 

 

Millist otsest kasu saab tooteomanik testide automatiseerimisest?

Lisaks eelpool kirjeldatule saab tooteomanik läbi automaattestide kindluse, et arendatud toode töötab nõuetekohaselt ning selle kindlakstegemiseks ei pea ta igal hommikul värisevate kätega domeeninime sisestama või arglikult postkasti piiluma, kas mõni pahane kasutaja on mõnest veast teada andnud.

 

Korralikud automaattestimise tarkvarad saab integreerida nii e-kirjade raportite saatmise kui ka näiteks igapäevase automaatse aruande saatmisega suhtluskanalitesse (nt Slack). Seda on võimalik seadistada, kas teade saadetakse testide jooksmisel või ainult vigaste testide jooksmisel ning “halbade üllatuste” hulk peaks vähenema õige kiiresti.


"näide tooteomaniku “Tugi” Slacki kanalisse EndTesti poolt automaatselt saadetud aruandest testi ebaõnnestumisel"

Kuvatõmmis 1: näide tooteomaniku “Tugi” Slacki kanalisse EndTesti poolt automaatselt saadetud aruandest testi ebaõnnestumisel

 

 

Miks tuleb testida automaattestidega kasutajaliidese visuaalsust ehk väljanägemist?

EndTest on oma sisult graafilise kasutajaliidese (GUI) automaattestimise tööriist. Lisaks töötavale funktsionaalsuse kontrollile, on minu EndTesti põhikasutusalaks kontrollida võrdluse abil, kahes erinevas ajaraamistikus, veebilahenduse kasutajaliidese (või äpi) nõuetekohast visuaalset pilti ehk väljanägemist.

 

Graafilised veebirakendused on täna visuaalsemad kui kunagi varem – visuaalsus ja disain ise on järjest olulisemad. Teisisõnu, see kuidas info või funktsionaalsus on visuaalselt esitatud mingi nupu, teksti, vihjemulli, otsingukasti vms kujul, on metoodiliselt läbimõeldud ja analüüsitud kasutajakogemuse lähtepunktist ning toetab kasutaja eesmärgilist käitumist.

 

Seetõttu on visuaalsuse “säilimine” arenduse käigus ja stabiilsus kasutajaliideses väga olulised. Näiteks pelgalt API ”schema validation” automaattestidega ei piisa kasutajaliidese kontrollimisest (nt kas mingi töövoog või element on lehel olemas), kuna need testid läbivad ka juhul, kui kõik stiilid (CSS) on puudu ja kuigi tegelikult lõppkasutaja rakendust sisuliselt kasutada ei saa.

 

Lisaks ei ole harvad juhtumid, kus API-päring on näiliselt korras (st “Status code on 200”), kuid tegelikult vastav päring kasutajaliidesesse andmeid välja lõpuni ei kuva.

 

"Näide kasutajaliidese võrdlemisest ja ebaõnnestunud testist EndTest tarkvaraga"

Näide kasutajaliidese võrdlemisest ja ebaõnnestunud testist EndTest tarkvaraga

 

 

Kuidas EndTest töötab?

EndTest on tasuline pilves asuv koodivaba platvorm, mis kasutab töötamiseks Selenium mootorit veebilahenduste ja Appiumit mobiiliäppide testide loomiseks. Lihtsamalt seletatuna kopeeritakse ja seejärel käivitatakse tarkvaraga erinevaid tegevusi (nn samme), mida kasutaja veebilehel sooritab.

 

Samal ajal kontrollitakse, kas automaattesti käivitades käitub ka veebirakendus valitud brauseris, op-süsteemis ja resolutsioonis ootuspäraselt. “Ootuspärasuse” sisu on määratud testija poolt ning sisaldab endas erinevaid nõudeid, millele vastavust kontrollitakse.

 

Näiteks saab luua (automaat)testi, kus veebirakenduses täidetakse mingile üritusele registreerimisvorm vastavate andmetega. Säärane test võib sisaldada erinevaid testija poolt määratletud nõudeid: registreerimismodaali kujunduse vastavust, väljade veateadete olemasolu, nuppude stiile jne. Nõudeid kuni selleni välja, et kas registreeringu sisu ise jõuab ka andmebaasi. Kui jah, siis kas selle sisu vastab veebirakenduses sisestatule ehk kas mingid andmed ei ole kaduma läinud. Sisuliselt on võimalik automaattestidega katta ära nn “end-to-end” raamistik.

 

Testide loomiseks sammude lisamine testidesse peaks olema jõukohane enamikule. Selleks on vaja vaid käivitada vastav EndTesti plugin, mis kõik testija tehtavad tegevused veebirakenduses lindistab. Või siis luua vastav test käsitsi ning lisada soovitud tegevused (nt klikk nupul).

 

Seejärel lokaliseerida elemendid, millega vastav tegevus toimub (nt Id või xPathi abil) ning lõpuks lisada vastavad nõuded (nn assertions), mis konkreetse sooritatud tegevuse tulemusena on oodatud lahendus - näiteks kui vajutan “otsi” nuppu, siis kuvatakse otsinguvasted ja just kindla visuaalsusega.

 

"Näide kasutajaliidese võrdlemisest ja ebaõnnestunud testist EndTest tarkvaraga"

Kuvatõmmis 2: näide EndTesti puhtast ja intuitiivsest disainist ning ühe (fiktiivse) testi ülesehitusest

 

Lisaks graafilise kasutajaliidese testimisele võimaldab EndTest sooritada ja automatiseerida ka API-päringuid ehk selleks, et näiteks lihtsalt kontrollida, kas mingi päringu “Status Code” on 200, ei pea enam eraldi programmi (nt Postman) kasutama. Need saab edukalt lisada muude kasutajaliidese testide hulka. Ka SQL päringute funktsionaalsus on EndTesti lisatud ja vajadusel saab andmebaasidele (MySQL, PostgreSQL, MicrosoftSQL) ligi ka EndTestiga.

 

" EndTestis API päringu “Status Code`i” kontrollimiseks kontrollitakse loodud muutujat (“Variable”) ja selle väärtuse säilimist"

Kuvatõmmis 3: EndTestis API päringu “Status Code`i” kontrollimiseks kontrollitakse loodud muutujat (“Variable”) ja selle väärtuse säilimist

 

Mis mulle testijana eriti meeldib EndTesti puhul:

  • API testide tegemise võimekus;
  • lisatud mobiilitestide ja äppide testimise võimekus ehk üks tööriist kõigeks;
  • andmetest lähtuv (“data driven”) testimise võimalus ehk CSV failide kaudu erinevate andmete testimine;
  • võimalus kasutada testides vajadusel JavaScripti käsuridasid;
  • kasutajaliidese väljanägemine ja kognitiivsus;
  • pilves asumine ehk igalt poolt ja iga kell oma testidele ligipääs;
  • pidev arenemine sisult läbi lisanduvate funktsionaalsuste;
  • pidev arenemine vormilt ehk väljanägemiselt;
  • väga kiire ja hea klienditugi;
  • integreeritus teiste platvormidega (JIRA, Jenkins, BrowserStack, Slack jt);
  • testide tulemuste vaatamise võimalus videotena;
  • sisseehitatud Veebämblik (“Web Crawler”) lehtede laadimisaja kontrollimiseks.

 

Mis mulle testijana nii väga ei meeldi:

  • halvasti loetavad tulemuste logid;
  • õpetav dokumentatsioon võiks olla põhjalikum;
  • kohati puudulik UX ja piiratud kasutaja tegevused.

 

Soovitan julgesti EndTest tarkvara järele proovida kõigil testijatel, kes ei ole julgenud seni esimest sammu automaattestimise vallas teha. EndTestil on olemas ka “trial” ehk proovimise versioon, millega saab katsetada esimeste testide loomist ning veenduda, et just see on tööriist, mida Sinu ettevõttel ja Sinul on vaja.

 

Lisa kommentaar

Plain text

  • HTML elemendid keelatud.
  • Automaatne rea- ja lõiguvahetus
  • Veebilehtede aadressid ja e-posti aadressid muutuvad automaatselt linkideks.
Kommentaar