Mõista, mõista, mis see on: nähtamatu, kui tehtud; nähtav, kui tegemata

Viimasel ajal võib meedias tihti kohata uudiseid tarkvara, õigemini selle mittetoimimise kohta.

Elioni tuumikvõrgu rike tingis üle-eestilise internetikatkestuse, jätkuvad häired digiretsepti kasutuselevõtul ja kiiruskaamerate kasutuselevõtu venimine on vaid mõned kodumaised näited.

Milles on siis küsimus – kas viletsas tarkvaras, või hoopis selles, et puudus õigeaegne info tarkvara kvaliteedi kohta, et võimalikud vead ära parandada enne avalikkuseni jõudmist?

Kas näiteks Elion oleks nimetatud tarkvara kasutusele võtnud, olles veast ja selle mõjust teadlik? Vaevalt. Seega on enne iga tarkvara kasutuselevõttu ülioluline hankida tarkvara kohta infot – kas see töötab ikka nii, nagu ette nähtud? Taoline info kogumise protsess ongi tuntud kui tarkvara testimine.

Testimine võimekuse mõõtmiseks

Meid kõiki on siiamaani loendamatul arvul kordadel testitud – eksamite, kontrolltööde ja tahvli ees õpetaja küsimustele vastamise käigus. Selliseid „teste“ tehti eesmärgiga hinnata meie teadmisi ja oskusi vastavalt õppekavale, et panna välja veerandihinne või anda välja lõputunnistus.

Tarkvara puhul on hindamise aluseks enamasti eelnevalt kokku lepitud nõuded, millele vastavust on testimise abil suhteliselt objektiivselt võimalik hinnata. Näiteks peab kiiruskaamera täpselt registreerima möödasõitva auto kiiruse ja identifitseerima auto ning digiretsepti süsteem peab võimaldama teenindada üheaegselt kogu Eesti apteekreid ning arste ilma katkestusteta ja aeglaseks muutumata.

„Konstruktiivse lõhkumisega“ oma igapäevast leiba teenivaid professionaalseid testijaid kohtab ka mujal kui vaid tarkvaraarenduses. Näiteks enne, kui uus lennukimudel tunnistatakse tootmiskõlblikuks, testivad seda elukutselised katsepiloodid.

Kui võrrelda Airbus A380 katsetusi mõne väikelennuki testimisega, siis esimese katselendudeks kulus ilmselt märgatavalt rohkem tunde. Nii on ka tarkvara arenduses - testimise mahukus sõltub testitava objekti keerukusest ning olulisusest. Siinkohal ei taha ma kindlasti väita, et mõni lennuk oleks teisest väheolulisem – kõigist nendest sõltub inimeste elu, kuid Airbus A380 on kindlasti keerukam ja nõuab palju rohkem teste kui pisilennuk.

Kui maailm oleks riskivaba

Tarkvara testimisel on loomulik, et teismelistele mõeldud mobiilimängu testitakse ilmselt vähema põhjalikkusega kui südamestimulaatori tarkvara. Sellist lähenemist nimetatakse riskipõhiseks testimiseks. Testimise põhjalikkus ning meetodid tulenevad otseselt riskidest ehk sellest, milliseid tagajärgi võimalik viga endaga kaasa tuua võib. Mida hullemad tagajärjed, näiteks oht inimelule või keskkonnale, seda põhjalikum peab olema ka testimine.

Eelpoolkirjeldatud testide käigus panevad katsepiloodid mängu oma elu, et teistel oleks edaspidi ohutu lennata. Näiteks hukkus 2009. aasta kevadel lennukitootja Cessna katsepiloot, sest lennukit ei õnnestunud testi käigus ohuolukorrast välja tuua ning ka piloodi päästmiseks disainitud langevarjusüsteem ei toiminud ootuspäraselt. Kahjuks ilmnes see alles testimise käigus. Seda juhtumit võib käsitleda kui õnnestunud testi, sest leiti viga.

Inimlikus ja majanduslikus mõttes oli see aga katastroof.

Õnneks tarkvara testijad oma elu igapäevaselt ohtu ei pane. Kindlasti ühendab katsepiloote ja tarkvara testijaid keskendumine vigadele, et tarkvara kasutajal tulevikus probleeme ei tekiks. Ebapiisav testimine või testimisest loobumine näiteks kulude ja aja kokkuhoiu eesmärgil võib kaasa tuua aga hoopis suuremaid kulusid ning kahjusid, kui esmapilgul oodata võib – tasub vaid kujutleda mis oleks juhtunud, kui seda lennukit ei oleks testitud vaid kohe kasutusse võetud...

Testija kui katsepiloot

Katsepilootideks palgatakse ainult kõige kogenumaid piloote. On siililegi selge, et kogenud piloot oskab ka halvas olukorras suurema tõenäosusega õigesti reageerida ning lennuki võimalikult tervelt maa peale tuua. Tarkvaraarenduses on kahjuks aga testija ametikoht tihti alahinnatud ja vaid IT organisatsiooni lävepakuks. See on kindlasti ka üks põhjustest, miks vigane tarkvara igapäevakasutajani jõuab. Heal testijal, nagu heal katsepiloodilgi, peab kindlasti olema vastav väljaõpe ning ka kogemused. Näiteks Eestis tegeleb elukutseliste tarkvara testijate kokkutoomisega vabatahtlikest koosnev mittetulundusühing Eesti Testijate Liit.

Testimine on universaalne tegevus info saamiseks. Testitakse selliseid objekte ja subjekte, mille kvaliteedist midagi olulist sõltub, näiteks koolilapsi, lennukeid ja tarkvara. Saadud info on väärtuslik tagasiside, mis aitab leitud vead parandada ning saavutada parema lõpptulemuse – olgu selleks siis haritud inimpõlv, turvaline lennuliiklus või hästi oma eesmärke täitev IT-lahendus. Nii ongi hästi teostatud testimine nähtamatu, sest kõik toimib nii nagu oodatud.

Puuduliku testimise tagajärjed kipuvad aga mõjutama inimeste igapäevaelu.

Maili Markvardt on Tallinna Tehnikaülikooli arvutiteaduse instituudi doktorant. Tema artikkel on kirjutatud Tartu Ülikooli korraldatud doktorantide populaarteaduslike artiklite konkursi tarbeks. Konkurssi aitas rahastada Haridus- ja Teadusministeerium.

• Tweet