Kuidas testide automatiseerimisel õnnestuda

Testide automatiseerimine on alati kahe otsaga asi, võimaldades küll testijate igapäevatööd kergendada, kuid sama kergesti võib sellega hoopis probleeme juurde luua. Kuidas toimida, et õnnestuda? Automaattestide juurutamisel võib ette tulla mitmeid probleeme, mõned tüüpilisemad komistuskivid:

 

  • Automatiseerimine vabal hetkel. Automaattestide loomisega tegeletakse siis, kui selleks on aega – projekti töös tekkivate “aukude” täiteks, omast ajast jne. Puudub vajalik pühendumus.
  • Puudulikud eesmärgid. Milleks me üldse automaattestidega vaeva näeme? Aja säästmiseks, testimise lihtsustamiseks, testide katvuse parandamiseks? Testijate motiveerimiseks? Kõike korraga tõenäoliselt ei ole võimalik saavutada, inimeste eesmärgid on erinevad ja kui neid selgelt välja pole öeldud, on lihtne feilida.
  • Kogemus. Õigemini selle vähesus või puudumine. Automaattestid võivad kergelt muutuda haldamatuks džungliks, kui neid arendavate inimeste teadmised tarkvaraarenduse põhitõdedest on puudulikud.
  • Inimesed vahetuvad. Automatiseerimise õppimine võtab aega ja kui meeskonnaliikmed tihti vahetuvad, kaob ka omandatud kogemus.
  • Tahtmatus testida. Paljude inimeste jaoks on automatiseerimise protsess huvitavam, kui tarkvara testimine. Automatiseerimine võib muutuda mugavaks vabanduseks, miks testimisele vähem pühenduda. Sellisel juhul ei ole ka automatiseerimise väljund testimise seisukohalt tihti suurem asi.
  • Tehnilised üksikasjad. Kuidas tarkvara automatiseerida, on tehniliselt huvitav ülesanne, kuid liigne keskendumine tehnilistele probleemidele võib tähendada vajadustele üldse mitte vastavat tulemust.

 

Automaattestid on tarkvara

Testide automatiseerimist tuleks võtta kui igasugust muud tarkvaraarendust, täpselt samade probleemide, lahenduste ja metoodikatega. Automaattestid on tarkvara ja nende loomisel tuleks silmas pidada tarkvaraarenduse häid tavasid. Automaattestide loomisel peaks osalema nii arendajad kui ka testijad, seda seetõttu, et arendaja võib olla küll väga kogenud oma erialal, kuid testimisel on oma spetsiifilised lahendused, mida arendaja ei pruugi nii hästi tunda. Siin tuleb appi kogenud testija.

Nagu iga arendusprojekt, nii vajab ka testide automatiseerimine korralikku eeltööd – tuleb kirjeldada nõuded, disainida raamistikud ja arhitektuur. Vajalik on koodi haldamine ja versioneerimine. Automaattestides, nagu igas teises tarkvaralahenduses, esineb bugisid, seega vajavad ka automaattestid ise testimist. Automaattestidel on kasutajad, seega dokumentatsioonist mööda ei pääse. Ja nii edasi.

Aga mida siis teha, et mitte hätta jääda?

Igasuguse ülesande lahendamiseks peab olema kirjeldatud protsess, kuidas seda teha, see peaks olema võimalikult lihtne ja nõudma võimalikult vähe ressurssi. Testide automatiseerimine ei pea piirduma ainult automaatselt jooksvate skriptidega, see võib hõlmata mida iganes, mis aga testimise protsessi lihtsustab või kiirendab.

Hea näide automaattestidega alustamiseks on regressioonitestid. Paljud alustavad just siit. Miks? Neid teste jooksutatakse tihti, nad on sageli tüütud. Aga enne kui üldse mingeid teste automatiseerima asuda, tuleks veenduda, et nad on piisavalt head. Kas vajalikud andmed on hästi kirjeldatud? Testija, kes teste käsitsi jooksutab, ilmselt tunneb testitavat tarkvara, kuid automatiseerimiseks on vaja see info selgelt esitada. Sama lugu on ka testide oodatud tulemustega – tihti eeldatakse, et testija teab, millist tulemust oodata ja see on puudulikult kirjeldatud. Mida rohkem ja täpsemat informatsiooni me testitava tarkvara kohta omame, seda paremini saame me automaatteste planeerida ning seda kvaliteetsemad need on.

 

Nõuded paika

Automaattestide loomiseks vajame me selgeid nõudeid, et me teaks, mida testida ning mida me automatiseerimisest ootame. Testide automatiseerimine on paljude inimeste jaoks nii ilmselgelt õige asi, et nad ei vaevugi mõtlema, mis nad sellega saavutada tahavad. Automatiseerimine aitab ühelt poolt testimist kiirendada, testida saab sageli ja vähema käsitsitööga, testide katvus paraneb, testid töötavad alati ühtemoodi, on usaldusväärsemad. Samas aga võime me teste automatiseerida ka selleks, et testimine oleks huvitavam või et omandada uusi kogemusi. Põhjuseid on mitmeid, mõni lihtsamini saavutatav, mõni mitte nii lihtsalt.

Testimine ei ole ainult etteantud skripti pime järgimine. Enne testima asumist tuleb tihti seadistada keskkond. Testide tulemused tuleb kuidagi jäädvustada, vigu analüüsida ja koostada vajadusel uusi teste vea täpsemaks lokaliseerimiseks. Tarkvara “imelik” käitumine vajab täiendavat uurimist. Kõike seda ei ole vaja ja ei saagi automatiseerida. Keskenduda tuleks sellele, mis on parima bang-for-buck suhtega. Osaline automatiseerimine on täiesti aktsepteeritav. Alati leidub keegi, kes ütleb, et tõeliselt automatiseeritud protsess teeb kõike ise. Jamajutt. Väljakutsena töötab absoluutselt kõige automatiseerimine imehästi, aga kui on vaja saavutada tulemusi, tuleb keskenduda sellele, mida saab kiirelt automatiseerida ja hiljem korduvalt uuesti kasutada.

Automatiseerimise nõuete väljaselgitamine aitab teha vajalikke kompromisse ja annab kõigile osapooltele ülevaate, mida tehakse.

 

Automatiseerimise võimalikkus

Automatiseerimist alustatakse tihti ilma kindla sihita, kuhu välja jõuda. Enne üle pea töösse sukeldumist tuleks mõelda ka sellele, kas planeeritu on ka teostatav. Valitud tööriistade ja lähenemisviisi pädevus tuleb võimalikult kiiresti välja selgitada. Kas antud projektis on üldse võimalik automaatteste luua? Vastus sellele küsimusele võib vältida suure hulga tarbetu töö tegemist. Esimene väljund automatiseerimisest peaks olema tõestus, et asi toimib – kiire, sisukas testide kogum, mis näitab, et valitud suund on õige. Valitud lahenduse toimivuse tõestamine on samm lähemale õnnestumisele.

Oluline roll automatiseerimise õnnestumises on loodava tarkvara testitavusel. Juhul, kui tegu on juba pikemat aega arendatud tootele automaattestide loomisega, ei saa tihti palju selles suunas ära teha, kuid värskelt alustatud või varajases arengufaasis olevas projektis, kui on võimalik veel toodet vähese vaevaga modifitseerida selliselt, et automaattestide kirjutamine ei nõuaks automatiseerijalt liigset vaeva, tuleks sellele ka tähelepanu pöörata. Paremini testitavale tarkvarale on lihtsam luua kvaliteetseid automaatteste, mis omakorda tõstab ka toote kvaliteeti.

 

Eesmärgiks jätkusuutlikkus

Testide automatiseerimine on tihti see osa projektist, mis ühel või teisel põhjusel jäetakse piisava tähelepanuta või hoopis kõrvale. Projekti ajalised piirangud või ressursside puudus on vaid üks põhjus, samamoodi võib automatiseerimine ebaõnnestuda, kui keskenduda automatiseerimisele iseenesest, ilma selge fookuseta pikemas plaanis. Automaattestid vajavad haldamist ja täiendamist, et käia kaasas toote arenguga. Testid peavad olema usaldusväärsed – kas test tõesti õnnestus või ainult teatas, et õnnestus? Testid, mis ei tuvasta probleeme, mille vältimiseks nad on koostatud, võivad põhja viia kogu projekti. Sellised testid tekivad, kui eelnev disain on kehv või teste modifitseeritakse hooletult.

Üks põhjuseid automatiseerimise ebaõnnestumiseks võib olla liigne keskendumine testide jõudluse parandamisele. Koodi optimeerimine tähendab tihti koodi keerukuse suurenemist, keerukam kood omakorda võib aga olla vähem stabiilne. Automaattestide juures on see probleem tihti teravam, kuna testide testimisele ei panda alati piisavalt palju rõhku. Olenevalt rakendusest ei pruugi ka olla tegelikku vajadust automaattestide puhul maksimaalset kiirust taga ajada, kuna tihti seab testitava rakenduse enda kiirus automaattestidele piiri, kust edasi ei ole testide optimeerimisel enam mõtet.

Mida aga teha siis, kui automaattestid annavad vigu? Kas tegu oli valehäirega, testi enda veaga, testkeskkonna probleemiga või tegeliku bugiga rakenduses? Testide kvaliteedi parandamise, tarbetute või aegunud testide eemaldamisega saab vähendada nii valehäirete sagedust kui ka lihtsustada tekkinud vigade analüüsimist.

Esineb olukordi, kus projektis on mingi hulk automaatteste olemas, sageli loodud ammu enne seda, kui praegune meeskond projektiga tegelema hakkas. Neid teste on kogu aeg kasutatud ja nad on omandanud teatud “oraakelliku” staatuse. Samas aga ei tea keegi täpselt, mida need testid teevad ja kuna seda võib olla ka keeruline välja selgitada, siis kiputakse selliseid teste ülehindama, kui tegelikult võib tegu olla üsna tagasihoidlike testidega. Ülevaadet testide sisust aitab parandada nende korralik dokumenteerimine ja rakenduse koodi katvuse analüüs. Testid, mis küll töötavad ja annavad tulemusi, kuid millest testija päris täpselt aru ei saa, ei pruugi olla piisavalt usaldusväärsed. Eriti kui ülehinnatakse seda, mida need testid teevad.

Automaattestide usaldatavus on üks olulisemaid testide kvaliteedi mõõdikuid – kui test õnnestus, kas testitav funktsionaalsus tegelikult ka töötas? Valehäired testides endis leiduvate vigade tõttu tekitavad segadust, seega tuleks kuidagi eristada teste, mis ebaõnnestusid testi vigade tõttu testidest, mis ebaõnnestusid rakenduse vigade tõttu.

Automaattest ei suuda kunagi täpselt imiteerida manuaalset testi. Manuaaltestide puhul eeldatakse, et teste käivitab inimene. Erinevalt automaatteste jooksutavast arvutist on inimene intelligentne mõtlev olend, kes suudab teha järeldusi sellest, mida ta näeb. Automaattest peab täpselt kirjeldama, milline on oodatud tulemus, ühe testi ebaõnnestumine ei tohiks järgmiste testide jooksutamist katkestada. Automaattest peab olema võimeline jooksma nii iseseisvalt kui osana suuremas testide kogus. Seega peavad automaattestid olema sõltumatud, iga test peab olema võimeline iseseisvalt seadistama oma käivitumiseks vajaliku keskkonna. Kirjutades automaattestid nii, et üks test eeldab, et mingi teine test on eelnevalt käivitatud (üks test kasutab sisendina teise testi väljundit), tekitab doomino-efekti – ühe testi ebaõnnestumisel ebaõnnestuvad ka järgmised. Lisaks ei saa selliseid teste ühekaupa käivitada, raskendades leitud vigade analüüsimist. Testide üksteisest sõltumatuks tegemine küll tekitab mõnevõrra lisatööd, kuid selliste testide suurem usaldusväärsus on piisav kompensatsioon.

 

Automaattestide pakendamine

Automaattestide puhul, nagu ka igasuguse muu tarkvara korral, tuleb olulise asjana läbi mõelda nende pakendamine. Testide looja teab, kuidas oma toodangut kasutada, kuidas saadud vigu analüüsida, kuid sobivalt pakendatud testid on kasutatavad ka kõigile teistele. Korralik dokumentatsioon ja läbimõeldult loodud arhitektuur – et testide toimima saamine ei oleks kaelamurdev ülesanne – annavad testidele tugevalt lisaväärtust. Vähem oluline ei ole vigade puhul antavate veateadete sisukus ja arusaadavus.

Testid on toode ja need vajavad testimist. Värskelt valminud testid tuleks anda esimese asjana kellelegi teisele kasutamiseks, nii on võimalik saada operatiivselt tagasisidet, kas testid käituvad nii, nagu peaks, kas testide väljund on arusaadav, kas on vaja koolitust või täiendavat dokumentatsiooni.

Keeruline on ette näha, kes loodud teste lõpuks kasutama hakkavad. Lihtne kättesaadavus on oluline, näiteks võib teste säilitada koos rakenduse lähtekoodiga versioonihaldussüsteemis, et teised testijad ei peaks neid taga otsima. Paljud automatiseerijad ei tee oma teste avalikuks, kuna “need ei ole veel valmis”. Isegi kui testid ei ole täiuslikud, tuleks need teha teistele kättesaadavaks, sest lõplikku viimistlust võib testidele anda lõputult kaua ja nii ei jõuagi need kunagi kasutusse.

 

Mis edasi?

Vaeva on nähtud, testid kirjutatud, dokumenteeritud, inimesed saavad neist aru ja oskavad neid kasutada. Teste kasutatakse toote arendamise käigus regulaarselt ja tihti. Võiks ju lugeda töö tehtuks, kuid nii lihtne see siiski ei ole. Kuigi automatiseerimine lihtsustab testimist, kaasnevad sellega ka uued väljakutsed.

Testimise protsess on automatiseerimise lisandumisega paratamatult keerukamaks muutunud, testijad peavad õppima automaattestide tulemusi iseseisvalt tõlgendama. Kui seda ei tehta, on lihtne arvata, et igasugune automaattestidest tulnud viga võib olla hoopis testi probleem, appi kutsutakse automatiseerija, et tulemusi analüüsida, ja nii iga kord, kui teste jooksutatakse. Ka arendajad ei pruugi täiesti usaldada koodi, mida nad hästi ei tunne, seega testijad peaks automaattestidest piisavalt hästi aru saama, et vajadusel vea tuvastanud automaattestis sooritatavaid operatsioone vea reprodutseerimiseks käsitsi läbi viia.

Toote arenedes tuleb lisada uusi teste, olemasolevaid parandada, iganenud teste eemaldada. Vahel tuleb ka testid portida hoopis uuele platvormile. Testide kvaliteedi pideva paranemise tagamine on keeruline ülesanne, vältida tuleks olukorda, kus kaua kasutusel olnud teste pimesi usaldama hakatakse.

Aja jooksul toode muutub ja olemasolevad testid ei pruugi enam probleeme leida. Arendajad on õppinud teste tundma ja parendanud toote disaini ja koodi selliselt, et testid seal enam vigu ei leia. Mis ei tähenda, et seal vigu ei ole, lihtsalt vead võivad olla hoopis teist laadi, kui need, millele testide loomisel keskenduti. Tekib küsimus, kas testid ikak töötavad korralikult, võibolla oleks aeg testide tehnilist taset tõsta.

Ka kõige paremini automatiseeritud testid ei kaota aga täielikult manuaalset testimist. Paljusid asju on väga keeruline või täiesti võimatu automaatselt testida (näiteks kasutatavus). Mõnda testi ei ole põhjust või mõtet automatiseerida, keeruline on ka prognoosida, kas üks või teine test väärib rohkem kui ühekordset jooksutamist, et seda automatiseerida. Unustada ei saa ka kulusid – aeg ja ressursid. Kõige automatiseerimine ei toimi.

 

Lõpetuseks

Automatiseerimisel on oluline tabada ka õige ajastus, millal automatiseerida. Mõistlik oleks alustada võimalikult varakult, et automaattestidest oleks maksimaalselt kasu, kuid mitte nii projekti alguses, et tuleks teste veel kindlalt väljakujunemata nõuete tõttu pidevalt ümber teha. Automaatteste tuleks võtta kui tarkvara, need vajavad testimist, hooldust, aeg-ajalt tuleks kasutatavaid teeke ja tööriistu uuendada. Testide automatiseerimine on osa arendusprotsessist. Hästi disainitud automaattestid küll ei pruugi manuaalset testimist täielikult asendada, kuid toetavad seda tõhusalt, suhtumine automaattestidesse samasuguse tõsidusega kui toote koodi tagab nende järjepidevuse, jätkuva usaldusväärsuse, teeb kogu meeskonna elu kokkuvõttes lihtsamaks ja loodava tarkvara kvaliteeti tõstes tagab ka meeskonna (ning suuremas plaanis kogu ettevõtte) edu.

Leave a Reply

Your email address will not be published. Required fields are marked *