Eesti IT tiiger on tardunud topiseks ehk nähtamatu, kui tehtud, nähtav kui tegemata vol 2

Eile toimusid riigikogu valimised, millest mulle jäi kõige rohkem meelde Aarne Rannamäe kümnessetabav kirjeldus olukorrale - "Eesti IT tiiger on tardunud topiseks", et otsustasin selle lause tagamaid veidi enda vaatevinklist lahata. Olles ise viimased 6 aastat rääkinud kõigile oma klientidele, et testimine ei ole luksuskaup vaid hädavajalik, et mitte hiljem piinlikust tunda ja suuri summasid PR kampaaniate või kohtuvaidluste peale kulutada, siis eile õhtune fiasko valimiste infosüsteemiga ning sellest järgmisel päeval tekkinud PR kampaaniad meedias tekitasid minus "äratundmisrõõmu". Olen sellises olukorras juba mitmeid kordi olnud - projekti alguses olen eksootiline nabatantsija või hullumeelne, keda on lihtsalt lõbus projekti alguses meelelahutuseks vaadata, mida vürtsidab väga suur "ega meiega see ei juhtu" enesekindel suhtumine, sest "meil on väga tugev arenduspartner ja meil kõigil on siit projektist võita". Paraku näitab minu viimase 6 aasta kogemus, et ikka juhtub küll ja alati kõige ebasobivamal ajal, millele minu poolt järgneb "ma ju rääkisin sulle" tagantjärele tarkus. Mitte, et ma oleksin VVK juures oma nabatantsu numbrit teinud, kuid räägin oma enda kogemustest mõndade klientide juurest ja olen üsna veendunud, et ka selles projektis valitses selline ülioptimism ja enesekindlus. Olen aru saanud, et testimist, kui teenust ei ole võimalik ette müüa vaid ikka tagantjärele. Ma ise nimetan seda müügiprotsessi "ämbrimüügiks". Näeb see välja järgmine: kohtun kliendiga, kes pole väga IT võimekas - teisisõnu äriettevõtte, kes on alustamas uut IT projekti. Räägin talle, mida ta peaks tegema oma riskide maandamiseks, mis tegevusi on vaja teha ja palju tellija ressurssi kulub ühe tarkvara projekti peale - keskeltläbi 60% mahust on tellija tegevusi ja 40% arendaja tegevusi. Lisan siia veel kirjelduse, mida oodata ühest tarkvaraprojektist ning jään siis ootama reaktsiooni. Teisisõnu kirjeldan arenduse tellijale võimalikult palju ämbreid, millesse ta võib astuda, kui ta sellele ja sellele tähelepanu ei pööra. Reeglina mind kuulatakse ära, surutakse kätt ja öeldakse, et kõik on kontrolli all ja meiega sellised asjad ei juhtu. Möödub umbes 6 kuud. Järgneb meediateade, kus öeldakse, et süsteemi valmimine viibib või on tekkinud "tehnilised probleemid" - ühesõnaga enamus projekti eel kirjeldatud ämbreid on juhtunud. Edaspidi suhtutakse minu juttu selle kliendi juures tõsisemalt. Ämbrimüük tehtud :)

Hiljuti ilmus Maili artikkel Novaatoris, mida refereeris omakorda Delfi (http://www.novaator.ee/ET/it/moista_moista_mis_see_on_nahtamatu_kui_tehtud_nahtav_kui_tegemata/) (ja on varem avaldatud ka siin blogis), mis rääkis testimisest, kui hindamatust infoallikast tarkvaras leiduvast või siis ka puuduvast kvaliteedist. See sai suhteliselt hävitava hinnangu kommentaatorite poolt, kes arvasid, et kõike testida pole võimalik ja testimine ei garanteeri süsteemi toimimist. Kõik ilus ja kena ning olen 100% selle argumendiga nõus. Kvaliteeti ei ole võimalik süsteemi sisse testida vaid testimine annab infot, kas selles süsteemis on minged kvalitatiivseid omadusi olemas või on tegemist järjekordse ämbriga. Kvaliteet tekib ikka tarkvara väliselt rakendades teadlikku ja metoodilist lähenemist ning maksimaalselt edutoonud protseduuride kordamist järgnevates projektides. Selleks on loodud väga palju arenduse etalonmudeleid, mida võiks ka meie arendajad tõsisemalt järgida koos arenduse tellijatega. Seniks kestab paraku nn "kauboikapitalism". Viimane on siis suhtumine tarkvara, kui ärilahenduse arendamisse, millega tarkvara tellija peaks saama oma äri edendada ja paremaks muuta. Mõiste ÄRI ei tähenda siinkohal alati rahateenimist vaid mingi organisatsiooni eksisteerimise mõtet. Avalik sektor ei ole rahateenimise eesmärgil loodud, kuid ÄRI käib seal samamoodi nagu näiteks pangas.

Aga kuidas siis testimisega saada äriliselt olulist infot? Keskendub ju testimine vigade otsimisele? Ühelt poolt jah, on arendustestimine, mille fookus on funktsionaalne korrektsus ja teiselt poolt on äritestimine, mille fookuses on süsteemi rakendumine. Mõlemad testimised on ülimalt olulised ja annavad erineval tasemel infot - üks projektiriskidele ja teine äririskidele. Riskipõhine testimine jäetakse tihtipeale ära, loodetakse, et äririskid ei realiseeru või ei tehta seda piisava põhjalikkusega. Tuleb selget vahet teha projektiriskidel ja äririskidel. Projektiriskid ilmnevad arenduse käigus - arendajad on üle koormatud, eelarve liiga väike, inimesed haigestuvad, tellija ei ole piisavalt kättesaadav, palju vigu jne. Äririskid on need, millele arendaja ei mõtle ja ei peagi mõtlema. Seda peab tegema äripool e tarkvara tellija - süsteem ei täida oma eesmärki, lõppkasutajad ei võta süsteemi kasutusele, jõudluse- koormuse ja robustsuse probleemid jne.

Kuidas siis riskipõhiselt testida ja kuidas teha "riskitestimise plaan"? Millele tähelepanu pöörata? Riskide kaardistamiseks ja juhtimiseks on palju erinevaid meetodeid. Täpsemalt võib igaüks uurida ISO 31010 standardit, kuid kiirelt oluliste riskide hindamiseks sobib selline lähenemine:
Esiteks, loo äririskide maatriks ja lisa sinna 6 mõõdet: risk, esinemise tõenäosus (madal = 0,1, keskmine = 0,5, kõrge = 1), riski mõju ärile (väike = 0,1, keskmine = 0,5, suur = 1), maandamisvõimalused, maandamise kulu, maandamata jätmise kulu (tekkiv kahju). Ürita täita veerud nii hästi kui oskad. Kui sa ei oska midagi hinnata, siis ole pigem pessimist, kui optimist ja hinda väärtust suuremaks, kui madalamaks. Otsuse tegemiseks, tee järgmine tehe:

riski tõenäosus * mõju * maandamata jätmise kulu.

Kui see number tuleb suurem, kui maandamise kulu, on mõistlik see risk pigem maandada, kui maandamata jätta.

Näiteks, ettevõte e-müügikeskkond, 1MEUR käibega:

Risk:
Teenus ei suuda piisavalt palju päringuid teenindada ja süsteem kukub kokku

Tõenäosus:
Keskmine

Mõju:
Suur, sest tulemuseks on mainekahju, klientide rahulolematus, võimalikud kohtuprotsessid ja hilisemad PR kulud

Maandamisvõimalused:
Tuleb läbi viia koormus- jõudlus- ja robustsustestid

Maandamise maksumus:
12 782 EUR

Maandamata jätmise maksumus
PR kulud 1000 EUR
Kohtukulud klientidele kahju tekitamises (partnerid ei saanud tellida kaupa ja äri seisis) 10 000 EUR
Klientide kaotus 100 000 EUR (10%)

äri peatumine vigade likvideerimise ajaks 83 000 EUR (1 kuu käive)

Testida või mitte?
0,5*1*194 000 = 97 000 EUR

Kas potentsiaalne 97 KEURi kahju kaalub üles 12 KEUR säästmise? Siia pole lisatud partnerite omavaheliste suhete keeruliseks muutumisest tingitud kulu, sest tõenäoliselt sama partneriga enam ei jätkata, ning uus partner peab eelmise partneri loodud tarkvara üle võtma, et seda edasi arendada.

Tulles tagasi valmiste ja valimiste infosüsteemi juurde, siis millised on selle süsteemi potentsiaalsed ärikahjud? Raha ju sellega ei teenita, kuid valimiste institutsiooni usaldusväärsus ja arendaja usaldusväärsus said maksumaksja raha eest päris oluliselt kannatada. Ma ei ole täielikult veendunud, et riigil ei tule tagantjärgi ka mõne valimisel osalenud kandidaadiga kohut käia või ei sea keegi kogu seda e-valimiste temaatikat kahtluse alla. Igatahes mina jään põnevusega ootama.

"Ämbrimüük" on täies hoos!

Tarkvara testimisest ja testijatest Eestis

Eestit tuntakse paljus kui „e-riiki“ ning innovatiivsete tehnoloogiliste, sh IT lahenduste väljatöötajat ning juurutajat. Sealjuures on kindlasti oluline pöörata tähelepanu ka kvaliteedile ning võib öelda, et ka selles vallas on astutud olulisi edusamme. Tõsi, ka veel täna jõuab meediasse uudiseid vigasest tarkvarast ning ilmselt on üheks põhjuseks vähene testimine – nii funktsionaalsete kui ka näiteks jõudlusega seotud omaduste osas. Seega arenemisruumi veel jätkub, kuid mõned aastad tagasi ei olnud väga paljudes arendusfirmades oma testijaid, testimismeeskonnast rääkimata. Testija rolli täitsid muude tegevuste kõrvalt nii analüütikud, projektijuhid kui arendajad ise. Selge, et seetõttu testimisega piisava põhjalikkusega tegeleda ei suudetud.

Teerajajad
Siiski on igal alal olemas oma teerajajad ning sama kehtib ka tarkvara testimise kohta. Juba 2006. aastal veeretasid teemast huvitatud professionaalid mõtet luua organisatsioon, mis seisaks testimisalase teabe jagamise ning oma ala asjatundjate kokkutoomise eest. Mõttest reaalsete tegudegi jõuti alles 2008. aasta, mil sündis Eesti Testijate Liit (ETL) . ETL on eraisikutest koosnev professionaalide ühing, millesse võivad kuuluda kõik, kellel vähegi huvi testimise vastu on. Hetkel on meie ridades 42 liiget, nende hulgas nii ettevõtete tipp- ja keskastmejuhte kui ka spetsialiste. See fakt räägib kõnekalt, et testimine ja laiemalt võetuna tarkvara kvaliteet puudutab lähedalt kõiki, kes tarkvaraarendusega kokku puutuvad.

ETLi missiooniks on teadvustada testimise kui distsipliini olemust ning aidata kaasa erialase oskusteabe levitamisele ja kompetentside arendamisele. Kuidas ja kelle jaoks me seda teeme? Tahame olla kasulikud nii oma liikmetele kui ka (majandus)keskkonnale üldisemalt. Liikmetele tahame pakkuda võimalust vahetada ametiõdede-vendadega infot ning seega parandada erialase oskusteabe kättesaadavust. Korraldame perioodilisi seminare, kus ajakohastel teemadel võtavad sõna nii meie endi liikmed kui ka külalisesinejad, samuti aitame „maale tuua“ koolitusi.

Kaudselt mõjub ETLi tegevus kasulikult ka tööandjatele, sest tänu testimisalaste kompetentside parematele arendamise võimalustele on turul ka paremate oskustega töötajad. Tegevuses kompetentside arendamisel oleme jõudnud selleni, et ülikoolid on oma õppekavasid täiendanud: Eesti Infotehnoloogia Kolledžis on 2009. aastast on võimalik valikainena läbida tarkvara testimise aluseid tutvustavat õppeainet, Tallinna Tehnikaülikooli Informaatika magistriõppe kavas on testimise-alane aine aga kohustuslik. Juba traditsiooniks on saanud ka iga-aastane testimise intensiivkursus Tartu Ülikoolis.

Kuidas testijaid testitakse?
Üks väga tähtis osa kompetentside arendamisel on ka sertifitseerimine – see tähendab, et sõltumatu osapool kinnitab kellegi vastavust mingitele nõuetele, näiteks ülikoolitunnistus märgib, et inimene on läbinud mingi kindla õppekava. Testijate sertifitseerimine toimub samadel alustel. Eesti Testijate Liit on lisaks muudele tegevustele alates 2008. aastast ka International Software Testing Qualifications Board’i (ISTQB) esindaja Eestis. ISTQB on rahvusvaheliselt kõige tuntum testijate kompetentside arendamise eest seisev organisatsioon. ETL pakub võimalust testijatel end sertifitseerida ISTQB õppekavade järgi, käesoleval hetkel on võimalik sooritada ainult ISTQB Certified Tester Foundation Level eksamit, ehk kõige madalamat taset. ISTQB sertifitseerimisskeemi kuuluvad veel kesktase, mis jaguneb testijuhi, testianalüütiku ning tehnilise testianalüütiku spetsialiseerumiseks, ning ekspert-tase, millel on plaanis testiprotsesside parendamise, testijuhtimise, testide automatiseerimise ning turvatestimise suunad. Ekspert-taseme õppekavad on käesoleva hetke seisuga veel beeta-seisundis või väljatöötamisel.

ISTQB Certified Tester Foundation Level sertifikaat on muutunud Eesti testimismaastikul de facto standardiks, kuna annab üsna hea ülevaate kõigist testimisega seotud aspektidest ning ühtlasi võimaldab ühtlustada ka kasutatavat sõnavara. Kui testija organisatsioonist A räägib näiteks testiplaanist, siis testija organisatsioonist B saab aru, mida selle all mõeldakse ning väheneb võimalus möödarääkimisteks. Testijate algtaseme sertifikaat on osutunud seetõttu küllalt populaarseks ka inimeste seas, kes testijana ei tööta, küll aga puutuvad testijate tööga kokku – analüütikud, projektijuhid, arendajad. See on ka igati õigustatud, kuna ka testijate ja teiste osapoolte vahelisel suhtlusel on väga vajalik ühtne sõnavara, mida standardi järgimine kindlasti luua aitab.

Testija portree
Kui Sul tekkis nüüd küsimus, kes on testijad ja kust nad tulevad, siis võiks sellele vastata mitmeti. Veel mõned aastad tagasi oli valdav programmeerimiskeskne arusaam, et testijaks (või analüütikuks või projektijuhiks) hakkavad need, kes programmeerijaks ei kõlba. Õnneks on praeguseks need arusaamad veidi muutunud ning liiguvad selles suunas, et mida kogenum on testijaks pürgija tarkvaraarenduses teistel positsioonidel (näiteks analüütik või arendaja, veelgi parem arhitekt), seda parem testija temast saab. See on nii selle pärast, et oma eelnevate kogemuste põhjal tarkvarasüsteeme üles ehitades on need inimesed kõik vead juba omal nahal läbi proovinud, seega teavad nad edaspidi ka teisi hoiatada samu vigu tegemast. Nii ongi tõsiasi, et parimad turvalisuse testijad on endised või tegevarhitektid ning koodiauditit oskab efektiivselt teha ainult tegevarendaja. Efektiivsete koormustestide läbiviimiseks peab tihti aga omama sama põhjalikke teadmisi kui süsteemiadministraator. Muidugi on alati võimalik ka kohe ülikoolipingist testijakarjääri alustada, kuid sel viisil tuleb palju töö käigus juurde õppida selle kohta, kuidas tarkvaraarendus tegelikult käib.

Testimist on ajalooliselt peetud ka rutiinseks ning igavaks tegevuseks. See võib tõesti nii olla, kuid ainult juhul, kui testimine on valesti korraldatud. Isegi käsitsitestimine ei tohiks muutuda igavaks, kui kasutatakse uuriva testimise tehnikaid, ning siililegi on selge, et tüütud ja korduvad tegevused tuleb automatiseerida. Rääkimata siis näiteks turvalisuse testimisest, mida võib võrrelda justkui põneva aardejahiga, kus vihjetest lähtuvalt liigutakse edasi üha sügavamale ja sügavamale meid huvitava info suunas. Tänapäeval on olemas ka kõiki neid tegevusi toetavad vahendid, nii et testimist igavaks nimetada võivad tänapäeval küll vaid võhikud.

Tihti arvatakse, et testijad peavad juba iseloomult olema suured tähenärijad ja perfektsionistid. Tegelikkuses tuleb liigne perfektsionism hoopis töötulemustele kahjuks. Testija peab mõistma, et vaatamata tema enese arvamusele on primaarne siiski tellija arvamus. Testija ülesanne on välja tuua vigu, kõrvalekaldumisi spetsifikatsioonist ning puudujääke, kuid testija ülesanne ei ole saadud info põhjal võtta vastu otsuseid tarkvara sobilikkuse kohta. Seda teeb siiski keegi selleks volitatud isik, enamasti keegi tellija esindajatest. Seega on testija üheks olulisimaks omaduseks hoopis empaatiavõime ja sallivus – töötades vigade ning nn negatiivsete uudistega, peab testija jääma faktidele põhinevaks ning aktsepteerima asjaolu, et ka faktid võivad muutuda, kui muutuvad tellija soovid.

Teatavate diplomaadioskusteta testija oma igapäevatöös hakkama ei saa – oskus kommunikeerida negatiivseid uudiseid ilma, et uudiste vastuvõtja tunneks end „labidaga pähesaanuna“, nõuab harjutamist. Vead ei ole hea uudis kellelegi (peale testijate) – arendajatele ega tellijalegi ning nende teatavaks tegemisel tuleb säilitada neutraalsus ja põhjendatus, sest vastasel juhul võivad suhted minna teravaks kõigi kolme nimetatud osapoole vahel: tellija süüdistab arendajat kehva koodi kirjutamise, arendajad testijaid vigade leidmise ning testijad tellijat uduste nõuete ning arendajat kehva koodi pärast. Selge, et liigsetest emotsioonidest kellelegi kasu ei tõuse. Seetõttu on vigade raporteerimisel ning eskaleerimisel vajalik eristada olulist mitteolulisest ning testijana taandada end otsuste vastuvõtmisest, mis puudutab seda, kas tarkvara „sobib“ või „ei sobi“.

Seega sobib testijaks peaaegu iga inimene, kes tõeliselt soovib selle valdkonnaga tegeleda ning sellega kaasnevat vastutust võtta. Mida rohkem on kogemusi, seda edukam on start, kuid samas kehtib ka põhimõte „kes tasa sõuab, see kaugele jõuab“. Oluline on testimise erinevatest tahkudest valida just see, mis on antud hetkel võimetele ja soovidele vastav.

Kordan veel: tänapäeval ei ole testija kaugeltki enam läbipõlenud programmeerija või mõni eriti aeglase taipamisega tudeng. Pigem on lood hoopis vastupidi – testijate käes on päris suur vastutus õigeaegse ning korrektse info andmise osas, mille põhjal tehakse päris olulisi elulisi otsuseid. Kujuta näiteks ette, et testid uut lennujuhtimistarkvara, mille abil hakatakse Tallinna lennuväljal õhus ja maal lennukeid üksteisest ohutus kauguses hoidma. Testimistulemuste alusel tundub kõik olevat korras ning tarkvaraga antakse kasutusse. Järgmisel päeval või nädalal aga juhtub lennuväljal midagi, millel on katastroofilised tagajärjed. Uurimise käigus selgitatakse tõenäoliselt välja, et tegemist on mitte piloodi ega lennujuhi, vaid tarkvara veaga. Koheselt tekib küsimus, kes on „süüdi“, kas programmeerija, kes vea koodi tekitas, või siis testija, kes seda õigel ajal üles ei leidnud ja ei raporteerinud?

Kokkuvõtteks
Tegelikult ei olegi oluline, kes süüdi mõistetakse, oluline on see, tõenäoliselt on uni ja maine pärast sellist läbielamist tükiks ajaks rikutud, välistatud pole aga ka kokkupuuted kohtusüsteemiga. Tarkvaral lasub tänapäeval hiigelsuur vastutus, sealhulgas vastutus inimelude hoidmise eest, ning testija on just see väga oluline inimene, kes peaks andma asjakohast infot tarkvara korrektsuse kohta. Testijateta ei oleks meil tagasisidet ja kuna tagasiside on tõenäoliselt ainus tõeline sisend paremaks saamiseks, siis ei oleks võimalik testijateta ka võimalik paremaks muutuda.

Maili Markvardt
Eesti Testijate Liit
Juhatuse liige