Tere, Kuku raadio kuulaja, on laupäev ja eetris on IT-ri saade Restart, mis täna räägib testimisest. Saadet toetab ITL ja mina olen saatejuht Hendrik Aavik ja alates sellest saatest, vahel ka tulevikus, on meil Andrei Korobeinikut mitte asendamas, vaid nüüd välja vahetanud minu kaassaatejuht, Majandusministeeriumi IKT valdkonna asekantsler Taavi Kotka. Tere, Taavi.
Täna räägime testimisest, mis on siis kontrollimine, et kõik asjad arvutis töötavad ja meil on saates külalisteks Kaspar Loog, kes on Eesti Testijate Liidu juhatuses, aga peale selle testimistarkvara firma Browserbite, omanik ja eestvedaja, ning ka Raivo Päts, kes on testimisfirmast CGI testimise juht, ja Testijate Liidu nõukogu liige, nii et väga testimisvaldkondlik seltskond. Taavi, äkki juhatad sisse, mis asi üldse testimine on siis, täpsemalt?
No minul on see väga südamelähedane teema seoses minu eelmise eluga, aga aga mul on kogu aeg huvi pakkunud see nii-öelda testimise ja kvaliteedi juhtimise teema just Eesti kontekstis, sellepärast et testimine on ju nii-öelda millegi uue katsetamine ja infotehnoloogias on see tavaliselt millegi suure katsetamine, mistõttu see, kes katsetab või, või, või, või testib, et sellel on alati kahtsugu tundmust, et on kas katselendur, ehk siis uhken olla testija, või siis katsejänes, ehk siis sa tunned, et sind on kuidagi ära kasutatud. Ja Eesti IKT lahenduste koha pealt tihti me tunneme, et me pigem oleme nagu katsejänesed, mitte katselendurid, eriti kui vaadata selliseid suuremaid fiaskosid, nagu nagu digiretsept näiteks, et seetõttu tänane saade on mulle eriti huvipakkuv ja just sellest vaatevinklist, et mis moodi nii-öelda oma ala professionaalid hetkeseisu Eestis näevad, et Kaspar, oskad sa kommenteerida?
Tere ka kõigile kuulajatele, et testimisega on selline lugu, et väga paljud inimesed arvavad, et, et testimine nagu aitab kõiki vigu siis paratada. Reaalsus on see, et, et kui meil on mingisugune uus tarkvara, siis testijad saavad tihtipeale kasutajate vajadusi, arvestades öelda seda, et kas see tarkvara nende ootuseid võiks täita või, või mitte. Ja kui nüüd Eestit siin käsitleda, tegelikult see kehtib kogu maailma, et maailma kohta, siis see testimine on tihtipeale... ikkagi kukkunud sinna rolli, et noh, oma eelmist firmat juhtides helistati mulle üsna tihti, et näete, et meil on siin üks tarkvara ja sellega on probleeme, et äkki te tuleksite ja nüüd testiksite selle ära. Aga reaalsuses me tihtipeale nendele klientidele ikkagi ütlesime, et meil ei ole ju mõtet teile tulla ütlema, et see tarkvara on katki, sest et te teate seda juba isegi. Et Eestis on jah, kõige, kõige tüüpilisemad testijad on need kasutajad ise, ehk siis ollakse katsejäänese rollis. Aga kui sinna rolli ei soovita sattuda, siis tuleks jah, professionaalset abi otsida nende lendurite näol.
No aga ei pea ju endale kindlasti palkama testimisfirmasid, kui sa ostad mingisuguse tarkvara arenduse mõnest tarkvara arendusfirmasse ja eeldad, et ta töötab ja järelikult see tarkvarafirma peaks olema seda testinud, et kuidas siis nii, et üldse saab katki olla?
No siia võib nagu küsida näiteks ehitusvaldkonna kohta, et kõik on kangesti harjunud, et noh, kui ma endale ehitaja palkan, et siis ta võiks ju ehitada sellise maja, mis kindlasti püsti seisab ja kus veetorud ei leki. Aga millegipärast on väga populaarne eriala, on siin ka ehitusjärelevalve.
See ongi, millele sa viitad, on see, et me ei peaks rääkima mitte niivõrd testimisest, kui me peaksime rääkima kvaliteedi juhtimisest kui protsessist?
Jaa, täpselt nii. Et testimine ongi see, testimine kitsas mõistes tähendab ainult selle kontrollimist, et kokku lepitud, mida mingi tarkvara tegema peab, saad kontrollida, kas ta seda teeb, kvaliteedi juhtimine tegelikult tähendab juba laiemalt seda, et või tarkvara kvaliteedi juhtimine, et kas tarkvara tegemine vastab, kas see tehtud tarkvara vastab kasutajate ootustele?
Aga Raivo, et sul on, oled seotud niisuguse firmaga nagu CGI, mis tegeleb testimisega, et mina olen jälle kuulnud, et testida on kõige mõistlikum siis, kui testija on programmeerija kõrval, et kuidas on võimalik üldse teha niisugune eraldi testimisfirma, mis testib?
Tere ka minu poolt, väike parandus esmalt, et seegi ei ole puhtalt testimise firma, et meil tehakse ka arendust. Aga kuidas teha puhtalt testimise firmat, no esiteks sellepärast, et sul on väga lihtne hoida siis testimisealas kompetentsid ja pakkuda sellist kolmanda silma või kolmanda poole hinnangut tarkvarale? Et kui sa oled testija tarkvaraarendajaga koos, siis alati jääb väike kahtlus, et sa oled kallutatud tarkvaraarendaja poole ja sinu antud hinnang pole justkui objektiivsem.
Rääkides testija motivatsioonist, siis näitena Microsoft oma test, testijaid ja töötajaid motiveeris selle pealt, et mida rohkem nad vigu avastavad või ütleme, mida rohkem nad suudavad laivimineku kuupäeva edasi lükata, seda tublimad on, eks, ja tihti selles ametipositsioonis olid just endised programmeerijad, sellepärast et testimine ja, ja ülevaatamine on, on ilmselgelt nagu kas ma ütlen siis, kunstilisem tegevus kui see müüriladumine, eks, et kuidas teie üldse täna nagu testija rolli näete?
No reaalsus on see, et testija ja arendaja rollid üha enam põimuvad, sest et arendajatelt oodatakse tegelikult üsna ulatuslik testimisoskuste olemasolu, ehkki neid koolis väga palju ei õpetata, vähemalt Eestis hetkel see Olukord väga roosiline ei ole.
Kas täna üldse on ülikoolides sellist ainet nagu testimine või kariteedi juhtimine?
No testijate liidu eest, eestvõttel me oleme need siis TTÜ-sse, Tartu Ülikooli ja IT-Colledžisse, siis need ained ka nagu aidanud sisse viia, aga pigem on küsimus selles, et nad peaksid olema kohustuslikud ained ja juba bakalaureuseastmes. Aga...
Ma olen kuulnud, et testija ja arendaja on kuidagi vastandlikud, nagu ying ja yang ja must või valge, et, et arendaja eesmärk on luua midagi, üles ehitada ja panna asjad tööle ja testija töö, et tema töö oleks tulemuslik, on ära lõhkuda ja suuta teha nii, et see asi ei töötaks, et need vead üles leida, et kas, kas needsamad kaks iseloomujoont või tegevust saavad ühes inimeses täiuseni minna?
No minu arvates testija roll ei ole asju lõhkuda, eelkõige testija info, roll on astuda kliendi või lõppkasutaja kingadesse ja pakkuda siis informatsiooni. vastavalt kliendi või lõppkasutaja vajadustele, et öelda, kas see tarkvara on tema vajadustele kohane, kas see on piisavalt kvalitne, et, et ta saaks oma tööd teha. Ehk siis sellest tulenebki, et kui tarkvaraarendaja midagi arendab, siis tal on vaja teada seda informatsiooni, kuidas teha kliendile meelepärane lahendus. Ja see tingib ka selle, et testijad ja tarkvaraarendajad peaksid väga tihedalt omavahel koostööd tegema ja teadmisi ajama ja omavahelisi meetodeid ühtlustama.
Ma tuleks tagasi ikka selle juurpõhjuse juurde, ehk siis et kui testimine on nüüd reaktiivne tegevus, aga kvaliteedi juhtimine on proaktiivne tegevus, siis mis seis on ikkagi Eesti tarkvaraprojektides kvaliteedi juhtimisega, et kas tegemist on ikkagi sisipärase tegevusega või see on pigem selline litaarne tegevus, mida teevad ainult pangad ja suuremad tõlkoettevõtted, aga ütleme nii, et avalikus sektoris ja, ja väikeettevõtetes see jätkuvalt on pigem reaktiivne tegevus?
No Eesti ei ole siinkohal üldsegi mitte erand, et me peame arvestama, et Eesti on väike riik ja siin olevad firmad on ka väikesed maailma mastaabis. Ja, ja selle tõttu tekib meil mulje, et see testimine on vähe arenenud Eestis. Aga me peame alati meeles pidama, et testimine on nagu kindlustus või, võib mõelda nagu kaskokindlustus. Et mida suuremad on riskid, et see süsteemi töötamise korral on suured kahjud, seda rohkem tasub sinna panustada.
Aga kas siin äkki ei olegi nagu eestlaste tal avastatud nagu nii-öelda efektiivsem arendusmudel, et täna, kus pannaksegi ilmselgelt toorest tarkvara nii-öelda toodangusse ja, ja lastakse lõppkasutajatele hambaid kiristada, aga kokkuvõttes nii-öelda selle hammaste kirina taustal lihvitakse teemant, eks, et, et kas see äkki ei olegi nagu efektiivsem ja odavam kokkuvõttes, kui panustada meeletult kvalitektori kontrollile, nii nagu sakslased seda teevad näiteks?
No see on efektiivne, aga see on efektiivne ainult meie suuruse juures, et kui me sama mudeliga läheme Saksamaa maksusüsteemini, mingi, mingisugust suurt Saksa süsteemi arendama, siis üsna kindel on, on see, et samasuguse arendusmetoodikaga me jookseme peaga väh, vastu väga paksu tellisseina.
Aga põhimõtteliselt Eestis sellised iRetsepti lahendused, kus lähme laivi ja avastame, et kolm kuud nagu, nagu vaevu, vaevu töötab, et, et Eesti koha pealt on see siis nagu kõige lähenemine?
No see, testimine ei ole selline binaarne, et on õige ja vale, et see, seda võib mõelda nagu sellist vana analoograadiot, et sa saad seda joont tõmmata väga erinevatesse kohtadesse ja noh, kui siin digiretseptide peale jutt läks, siis... Siin, siin tegemist oli väga selgelt algselt ju, ju nõuetes eksimisega, sest et testimine hakkab pihta sellest, et mida siis lõppkasutaja või, või tellija soovib süsteemilt saada ja seal on üsna, üsna selgelt juhtus see, et tellija, ja soov ja tellija arusaam, kuidas see süsteem töötab, erines päriselust oluliselt.
Aga just küpsed turud on meile näidanud, et kus seda kvaliteedi juhtimist ka protsessina tarkvaratootmise juures väga jälgitakse, et et selline tõsine kvaliteedi juhtimine lisab tarkvaramisprotsessil eelarvele kuskil noh, kolmkümmend viis, nelikümmend protsenti, et mis Eesti kogemus on, et kui palju täna nagu ühest suurest tarkvaramisprotsessist Selline testimine, kvaliteedi juhtimine protsentuaalselt umbes mahuna võiks siis nagu olla.
No Eestis on, ma arvan, see suurusjärk umbes sama, kuid küsimus ei ole mitte selles, kui palju testimine maksab, vaid pigem on küsimus see, et mis juhtub siis, kui me ei testi ja palju see asi maksma läheb, kõik need välja tulevad vead.
Nagu see, kui kolm kuud digiretsept ei tööta, noh, see ei läinud riigile midagi maksma ju.
No selle hinnamaksid kinni meie inimesed ja teiseks nagu, nagu ka öeldi, et digiretsept oli mugavusteenus, et meil oli tegelikult olemas ju plaan B, et alati see paberretsepti võtta
ja... No justkui mõttelge, et kei, kellelgi ei jäänud ju rohud ostmata, et kõik paber, paber ju töötas kõrval, eks ole, et võib-olla oligi efektiivne mitte kulutada kolmkümmend protsenti eelarvest testimisele, vaid panna vead kirja siis, kui nad elus nagu avalduvad ja siis pärast lihtsalt korda teha, no täna töötab teenus hästi.
Jah, see, see on okei, senimaani, kuni meie elu muutub sõltuvaks sellest teenuseks, et praegu võib minna näiteks Swedbanki ja küsida, et mis te arvate, et mis teiega siis juhtuks, kui internetipank panna nädalaks ajaks kinni, et kuidas nad sellele vastu peaksid?
see jah, oleks mitte väga meeldiv situatsioon, ma arvan.
Kusjuures nii naljakas, kui see ei ole, et näiteks Skandinaavias on see, ma mõtlen siin Rootsis, Norras, Taanis selline momentum, et näiteks pank või internetipank pool päeva ei tööta, on täiesti normaalne näha, et, et selles mõttes on kindlasti meie ühiskond, ma ei ütle, et hellitatum, aga just, et ta nagu rohkem sõltuvusesse nestsamast töökindlusest.
Me, me ei teagi päris kindlasti, kas ma nüüd jälle näitega õigesti panen, aga kas vist Amazonilise firma, kus, kus testitakse niimoodi, et käiakse täiesti suvaliselt mööda serveriruumi ja tõmmatakse suvaliste servete, serveritel juhtmeid tagant ära lihtsalt, et et süsteem peab vastu pidama, aga ükskõik, mis juhtuks ja mis inimesel, mis juhtmeid õnnestub inimesel ära tõmmata, et see nagu ei ole oluline, et et ka seal käib see asi noh, laivis ja kui midagi halvasti läheb ilmselt siis ka kasutajate arvel. Aga lähme siit väikesele pausile.
tagasi kuulama IT-hääri saadet Restart, meie saade räägib täna testimisest. Saadet saate kuulata, muuseas, korduses täna öösel kell kaksteist ja raadio1.ee lehel on meie saate podcast allalaaditav. Odas, kus see saate kuulata igal ajal.
Eelmises plokis rääkisime testimise ja kvaliteedi juhtimise hetkeseisest Eestist, tahtsin veel kord küsida, Kaspar, et anna kiire ühe lause või kahe lausega hinnang, et mis seisus ikkagi kvaliteedi juhtimine täna on Eesti tarkvaratööstuses?
Lühike hinnang on, et küllaltki kehvas seisus. Põhjuseks on, on just meie riigi väiksus, sest et meil ei ole väga kõrgelt seda kvaliteediteenust ka vaja teha. Aga kui me soovime ikkagi nagu kaasa lüüa suures mängus, kui me soovime teha suuri süsteeme, siis on vaja see nagu järgi aidata.
Ehk siis ütled, et Eesti taseme jaoks praegune kvaliteedikontroll ja kvaliteedi juhtimine on piisav, aga kui me tahame eksportima hakata oma lahendusi, siis tuleks ikkagi minna hoopis uuele kvaliteeditasemele?
No lugedes lehti, siis ma küll ei ütleks, et see on piisav, et ma olen küllalt kuutunud kokku erinevate siis tarkvaratellijatega, kes on tihtipeale tegelikult hiljem ise tunnistanud, nad on ämbrisse astunud sellega, et nad on võtnud nagu lühiajalises perspektiivis odava lahenduse, aga pikaajalises perspektiivis on see just nimelt kvaliteedi juhtimise pärast või selle puudumise pärast osutunud oluliselt kallimaks.
Aga kui tellida endale IT-lahendust ja soovida hiljem hinnas kokku hoida, et siis ju see vist on väga keeruline mitte kokku hoida testimise pealt, sellepärast et kui küsida, et kas see menüü on oluline, kas me teeme selle, et menüüd sinna või ei tee, no kuidas siis menüüd ei tee, aga kas me ka testime seda, noh, no testige natukene, testige kiiremini võiks ju olla see, et kas, kas on mingisuguseid konstante siis, mis, kui palju peaks ikkagi testima mingisugust asja?
Jah, väga paljud on mu käest küsinud, et näed, et mul on siin tarkvaraarenduse eel, eelarve, et mitu protsenti siin testimise real peaks olema. Ja siin, siin ongi just nimelt raske koht, et sellist protsenti pole olemas, sest et see oleneb just nimelt sellest süsteemi riskiastmest, et tuumajaama kontrolltarkvara on vaja protsentuaalselt oluliselt rohkem testida kui näiteks Angry Birdsi. Et ei ole olemas ühte protsenti mingit kindlat protsenti, et see oleneb väga palju sellest kontekstist ja süsteemi kriitilisusest. Ja seda oskavad eksperdid aidata, paremini välja selgitada.
Raivo, et sa oled testimisvaldkonna ekspert, et äkki räägid raadiokuulajatele paari sõnaga, aga mis on uue maja trendid testimises, näiteks niisugused märksõnad nagu test-driven development või siis automaattestid?
No testrement ja laveloment on eelkõige mõeldud arendajatele, kes kasutavad seda sellisel viisil, et esimene kirjutavad valmis oma testid koodi tasemel ja siis hakkavad ju kirjutama koodi ja samaaegselt jooksutavad neid teste, et näha, kas nende kood need testid läbib. Ja koodi kirjutatakse senikäiva, kuni testid on läbitud.
Kuulajatele on ilmselt keeruline aru saada, et mis tähendab teste kirjutama, et kõigepealt on arvatud, et testimine on ju see, kui sa raputad masinat ja vaatad, mis seal sees on, et et kas see, äkki räägid paari sõnaga, kuidas see töötab?
Kui tõmmata paralleele näiteks kas või autoga, mis sul kodus on, noh, kellel on, siis väiksem jupp, mis seal võiks olla, on näiteks ABS pidurid. Siis sa teed mingi seadme, mis proovib, kas ABS pidur alla neljakümne kilomeetri tunnis rakendub või mitte. Seda võiks tinglikult nimetada unit testiks, et sa proovid sellist auto pisimat juppi ja vaatad, kas selline... jupp vastab mingile kindlale reeglile, samamoodi võib kirjutada ka koodis rea, mis kontrollib, kas funktsioon, mis selle ABS-i piduri nüüd käivitab, tagastab õige väärtuse, kui on kiirus alla neljakümne või mitte.
No aga ma saan aru, et kui testijaks on arvuti, et siis see on ju jube mõnus, et siis on, inimesed ei pea tööd tegema ja ei pea jälle nii palju eelarvet kulutama selle testimise peale. See kõlab mulle nagu sajandilepingu, et miks kõiki nii ei tee?
Selle kohta on üks, olen kuulnud vahvat nalja, et on, ühel testimiskonverentsil küsiti, et millal lõpuks siis kogu testimine ära automatiseeritakse. Ja, ja esineja vastas väga leidlikult, ütles, et siis kui kogu programmeerimine on ära automatiseeritud, et neid tingimusi ikkagi peavad välja mõtlema inimesed ja sellest hakkab kõik pihta. Ja seesama test-driven development, unit testing ja kõik need vahvad sõnad on ainult sellised sõnakõlksud, sest et me peame meeles pidama, et kõige suuremad vead tekivad just nimelt inimestevahelises kommunikatsioonis, et kui seesama arendaja, kes seda testi kirjutab, ei ole tegelikult kliendist aru saanud, siis seda kirjutab valed testid ja, ja kontrollib valet asja. Et oluline on ikkagi aru saada, et sa teed õiget asja, mitte et see asi töötab õigesti.
Noh, selles mõttes automaattestide kirjutamine on läinud muidugi mäletavalt lihtsamaks ka muutsete töövahenditega, et mäletan seda aega veel, kus kasutasime ka test-driven developmenti, mis lõppes siis sellega, et ühel hetkel testide kirjutamine võttis nagu kordades rohkem aega kui koodi kirjutamine ja, ja alati sellisel hetkel tekib tunne, et, et noh, või kiusatus vähemalt, et peaks nagu testimistest nagu või testide kirjutamisest loobuma või vähemalt nende osakuulu vähendama, eks, aga ma küsiks seda ka, et Eestis kipub olema niimoodi, et... Et selline analüütik, kui programmeerija, testija puhul me räägime kolmest rollist, me räägime kolmest inimesest, mujal maailmas, erikui Saksamaal näiteks on need pigem üks inimene, et teie vaatenurgast, kumb on nüüd siis parem, et kas see, et universaalne insener, kes nagu teeb ühe ploki või tüki valmis otsast lõpuni, või see, et ikkagi on nagu kolm erinevat persooniga?
No minu silmis on tulevik generalistide päralt, et järjest enam on vaja inimesi, kes teavad igast asjast piisavalt palju, tõesti nad mingis alas spetsialiseeruvad rohkem, et kindlasti igal testijal on vaja järjest enam ja enam tehnilisi teadmisi. No minu arust on üldse testijal vaja kolme sorti teadmised, ühed on testimisalased teadmised, siis on testimistehnikad ja nii edasi, tehnilised teadmised on kõik baasid, keeled ja nii edasi ja lõpuks äriteadmised, ehk mida klient tahab.
Aga ta ikkagi kokkuvõttes on testija, ta ei ole nagu samal ajal programmeerija või analüütik?
Ta kirjutab siiski erinevaid vahendeid oma töö hõlbustamiseks. Aga
tõmbaks ka paralleeli siin, ma nüüd programmeerimist ei tea, aga noh, ajakirjandusmaailmas, et see oleks umbes sama, kui ajakirjanik ja korrektor oleks seesama inimene. Aga noh, tegelikult on teada, et inimene iseenda vigu ei näe, lihtsalt ta on täiesti pime, isegi siis, kui tal on tähed sõnas valesti, ta, kui ta on seda ise kirjutanud, siis ta, ta, see on tema jaoks nii. Et ma küll ei kujuta ette, et noh, selge on see, et kedagi ajakirjanikuna tööle ei võeta, kui ta kirjutada ei oska, aga testima peaks ikkagi, keegi teine on, minu amatöörlik siis jäänud siia.
Ja toetan seda amatöörlikku arvamust, et reaalsus ongi, ongi see, et inimesed iseenda vigu ei näe ja mis on veel hullem, mõnikord kriitilistes situatsioonides, eriti siis, kui projekt on lõpujärgus ja mängus on võib-olla mingid õigeaegse tarne eest pakutavad boonused, et siis kiputakse nende leitud vigade, isegi kui neid leitakse. nende tähtsust võib-olla alahindama või neid maha vaikima, et siin on, tekib huvide konflikt lihtsalt ja eraldi inimene või eraldi roll, mõnel puhul ka eraldi firma, aitab seda huvide konflikti vältida.
Aga see on huvitav Eesti kontekstis, et Eestis on see nii-öelda noh, tundub triviaalne, et, et meil on need erinevad rollid, eks, ja kui sa lähed vähegi, vaatad nagu naaberringides ringi, siis sa näed, et et seal programmeerijalt oodatakse ikkagi märgatavalt kvaliteetsemat lõpptulemust kui seda, mis nagu täna Eesti programmeerija oma igapäevatöö selle tööna välja annab, et noh, täna Eesti programmeerija teab, et tal on veel noh, back-upiks üks inimene, kes tema asjast nii-öelda üle käib, on ju, noh, kirjutades loomulikult teste peale ja nii edasi, eks, aga Aga et tal on see back-up olemas, et, et, et mujal maailmas see päris nii ei ole, aga see on andnud jälle meie ettevõtetele selle paindlikkuse, et nad saavad sellesse testi rolli, kus üldjuhul on vähem, vähem nii-öelda teadmisi vaja, on võimalik palgata ka lihtsamat tööjõudu.
Peatudes selle tööjõu teema juures, ma olen aru saanud, et ega neid testijaid Eestis niisama lihtsalt ei leia, et neid on nagu, ei ole väga palju testimisfirmasid, tarkvara tootmisfirmasid, on rohkem teada, et kas on mõistlik seda teenust kuskilt välismaalt sisse osta, ma olen kuulnud, ma ei tea, Skype ostab vist Ukrainast, Singapurist, igasugust juttu olen kuulnud, et...
No Eestis üldse ei ole igasuguste tarkvara arendus või ka siis testimisalaste ressurssidega asi üldse kiita, et ma olen siin kuulnud erinevaid numbreid, mis siin Eestis räägitakse IT-sektori noh, kogu suuruse kohta, et alates neljast tuhandest lõpetades kaheksa tuhande inimesega, et võib-olla on... IKT ministril või see IKT kantsleril, asekantsleril midagi paremat numbrit pakkuda, aga ütleme, testimisega Eestis, ma arvan, tegeleb hetkel suurusjärgus noh, ütleme siis viissada inimest, ma arvan. Ja see oleneb väga palju ka definitsioonist, et tegelikult peaks iga arendaja oma töö testimisega ka tegelema. Et seda ressurssi siin peale kasvamas väga ei ole ja sellega ma ka väga ei tahaks nõus olla, et, et testimise peale saab võtta nii-öelda vähema kvalifikatsiooniga tööjõudu, sest et... Kui vaadata seda, kuhu see testimine või testimise oskus üleüldiselt areneb, siis need segunevad väga tugevalt arendusoskusega ja laias laastus noh, väljaõppes väga suurt vahet ei ole, kas seda koolitada välja arendajat või testijat. Et see ressursikulu on umbes sama, et see on niisugune ekslik arvamus, et, et võtan endale niisuguse tubli sekretäri ja siis kuus kuud istub arvuti taga ja natuke näpib seda programmi, mida me arendame ja varsti ongi testija valmis, et päris nii lihtsalt see asi ei käi.
Numbrile olgu siis öeldud, et Eestis on Statistikaameti andmete järgi circa seitseteist tuhat IKT-spetsialisti kõikide valdkondade peale kokku, aga tulen tagasi ikkagi selle kvalifikatsiooni juurde, et Et kas täna ühtegi eriala ülikoolis vastavat ei ole, et ma saan nagu lõpetada ja õppidagi nagu testijaks, kas see pigem on nagu ülikoolide teema või see pigem on nagu tehnikumide teema, et, et kas me peaksime pigem kutseharidust arendama siin või kõrgharidust?
Meil on vaja kõiki tasemeid, alates tehnikumist, lõpetades doktoriõppega, sest et kõige nii-öelda testimise niisugune koorekiht on, on ikkagi, see on juba väga keerukas teadus, väga keerukas arvutiteadus, et siinsamas TTÜ-ski tegelikult tegeletakse ka testimisega ja see testimine on siis nende kiipide testimine ja kontrollimine.
Aga kui see valu on nii suur selles IT, IKT valdkonnas, et noh, ma tean nüüd ZeroTurnAround, nendel on keeruline leida Java spetsialiste, nad avasid ülikoolis oma õppekava ja panustavad sinna, et kas siis firmad, kellel testimist vaja on, ei ole alustanud koostööd mõne ülikooliga?
Jaa, oleme, et Eesti Testijate Liidu esitevõttel on kõigis suuremates ülikoolides on juba vastavad ained, on olemas, Et järgmine samm ongi see, see, et saada need ained juba kohustuslikeks ja saada nad erinevatel tasemetel õppekavadesse sisse. Et vaja on, et asi nii kaugele jõuaks.
Ikka torgin edasi sama teemat just selle koha pealt, et süvatestimisega olen nõus, aga jätkuvalt on olemas nii-öelda Lõppkasutaja teste on AB-testingud, kus sul tegelikult ei ole vaja nagu IKT kõrgharidusega spetsialiste testima, et et täna on meil tõsine probleem sellega, et näiteks koolireformiga jääb meil üle kõvasti õpetajaid. Samas kellegi töö ülevaatamine, märkuste tegemine, punase pastakaga vahele kirjutamine võiks olla just täpselt see, mis neile nagu sobib, eks, et kasutades seejuures siis nagu hiirt ja noh, tehes seda sama AB-testingut, et näed sa siin mingit potentsiaali, et nagu ümberõppeks?
No ma siin korrigeeriks, et AB-testing ei käi tegelikult niisuguse klassikalise tarkvara testimise alla üldse mitte, et AB-testing käib pigem sellise müügitehnikate, veebimüügitehnikate teema alla. Aga kui rääkida sellest, et noh, teistest hektoritest inimesi üle tõmmata ja, ja neid alustuseks testijatena tööle panna, siis siis kindlasti see saab toimida, sellepärast et sarnast mudelit on üsna ulatuslikult kasutatud ka analüütikute puhul. Sest et kui Eesti, Eestis ringi vaadata, siis väga paljud analüütikud on tegelikult tulnud teistest ärivaldkondadest ja õppinud selle siis nii-öelda IT-meeste keelde panemise kas käigu pealt või koolist selgeks, et testimine on lihtsalt sellesama töö tagurpidi tegemine tegelikult, et See on täiesti võimalik ja sellised ümberõppe kavad on täiesti tehtavad.
Ühesõnaga, sinu silmis võiks panustada riik sellesse, et investeerida väiksema lisandväärtusega valdkondade inimeste ümberõppesse just läbi nii-öelda testimise ja oskuste lisanduse.
Jaa, ja siin muidugi riigist üksi ei piisa, et meie enda firmad peavad selle asjaga kaasa tulema. Sest et seda kompetentsi, kes suudab õpetada, on, on ka kuskilt vaja han, hankida, aga siin see ümberõppe vajadus on selgelt olemas, et turul on testimise ja inimesi puudu.
Aga millal tekib sõna otseses mõttes lausa omaette õppekava testimise koha pealt meie tehnikumitesse ja, ja, ja ülikoolidesse?
Ma hetkel ei ole sada protsenti veendunud, et eraldi õppekava on vaja, võib-olla magistri- või doktoritasemel see oleks mõeldav. Aga mina leian, et testimine on selline baasoskus, mis peaks olema igal siis informaatika või, või arvutiteaduse kraadi omanikul, see oskus peab olema neil taskus.
Aga testija või tänases, modernises maailmas testimine võikski olla ju elukutse, et sellisel juhul võiks seda ka ju tehnikumides õpetada, et noh, et, et noh, samamoodi... Jaa, selleks...
Puudub igasugune takistus, et see võib vabalt olla õppekava, et siin on võib-olla küsimus selles, et see on, see eriala ei ole Eestis veel nii-öelda omale täit tuntust saanud, et ja ta ei ole kindlasti nagu nime poolest nii prestiižne. Ja, ja väga paljud firmad siin, kui nad tahavad endale tõeliselt häid testijaid leida, siis nad ütlevad, et nad otsivad testimisinsenere. Et ja, ja olen kuulnud ka selliseid ametinimetusi nagu Clicker, mis siis tähendab, et see on väga vähese kvalifikatsiooniga või ilma igasuguse kvalifikatsioonita inimene, kes võtab rakenduse ette ja proovib seda kasutada ja siis paneb kirja need vead, mis ta leiab.
Kas selle, nende testijate noh, kuna need oskused on väga keerukad paljuski selles testimises ja väga sarnased programmeerija oskustele ja programmeerijad on ju teada-tuntud ülemaksu Eestis, Või, või vähemalt keskmise palgaga võrreldes, et siis kas testijate palgad on piisavalt head, et motiveerida inimesi, et ma arvan, et kui testijad on hästi makstud, et noh, et siis nad käivad ka võlgu ja nuhkusega, testijad, et võib-olla see maine paraneb, kui on rohkem teada, et tasub sinna kandideerida ja kommenteerite äkki seda poolt?
No kindlasti on palgaküsimus üks, mis takistab meil nii palju testijaid leidmist kui vaja, sest nii tööandjad kui ka töötajad ise näevad seda tihti kui entry level töökoht, et kust on võimalus areneda programmeerijaks, et ma olen isegi näinud töökuulutusi, et üle tööle testijaks võimalus saada programmeerijaks, et juba see vaade tööle on vale. alaväärtustatud, kuid loomulikult see palgatase ka on see, mis takistab väga häid inimesi sinna minemast, et kui sa oled juba väga tehniliselt kompetentne, et sa lähed juba puhtalt palga pärast ennem arendajaks ja teed seal oma tööd ja see tekitab selle, et tööandja ei näegi väga, väga pädevaid inimesi testijate seas, kindlasti seal praegust on väga palju pädevaid inimesi, kellele ka makstakse noh, arendajatega võrdset palka, kuid siiski seda nähakse interlevel tööna ja ei maksta nii hästi.
No Fontese palgauuringu järgi jah, testija roll on pisut vähem väärtustatud kui arendaja oma, aga kui me jälle võrdleme Eesti muude sektorite või muude valdkondadega, siis vähemalt Eesti keskmisest palgast nad kindlasti on rohkem kui poolteist korda rohkem, saab üks testija.
Kuskil arsti ja programmeerija vahepeal?
No meie kõrgelt pala, palesed arstid on, on vaata, et sama hetk programmeerijad oma palga poolest, eks, aga, aga kindlasti jah, et, et kahe tuhandeeurone palk testijale ei ole mingi haruldus.
Aga no õpetajale ilmne edasiminek. Kindlasti, jah. Lähme siit väikesele pausile.
Tere tagasi kuulama IT-ärisaadet Restart, meie saade on korduses täna öösel kell kaksteist, aga raadio1.ee aadressil saate kuulata meid läbi podcasti kogu aeg. Meie saad, tänane saade räägib testimisest, mina olen Henrik Aavik, püsisaatejuht ja Ma loodan, et tulevikus ka tihedamalt on meil kaassaatejuht Taavi Kotka, kes on Majandusministeeriumi IKT valdkonna aseklantsler ning tänases testimissaates on meil külas kaks testimiseksperti, Kaspar Loog firmast Browserbite ja Raivo Päts firmast CGI ning nad mõlemad on seotud kohe niisuguse organisatsiooniga nagu Eesti Testijate Liit. Ja Eesti Testijate Liidul, ma tean, on tulemas üks üritus.
Viiendast seitsmenda juunini toimub Eestis Nordic Testing Days nimeline konverents, kui me eelmises plokis rääkisime tarkvara süvatestimisest, selle keerukusest ja selle rolli nii-öelda võib-olla liiga vähesest tähtsusest, siis just seoses selle konverentsiga tekib küsimusi, et kas Eesti testimisel ja kvaliteedi juhtimisel võiks olla ka mingi ekspordipotentsiaal, ehk siis millal hakkavad Eestis tekkima need ettevõtted, kes noh, pakuvadki testimist ja kvaliteedi juhtimist ka lähiriikidele teenusena?
Ma arvan, et see potentsiaal on Eestis juba olemas, et Eestis on firmad, kes seda eksporditeenusena pakuvad, et võib-olla väga paljud inimesed ei tea, et noh, väga paljud Nokia telefonid on. Eestis testitud vähemalt osaliselt ja, ja on firmasid, kes seda teenusena osutavad, et nii-öelda ressursitarbimise koha pealt, et, et leida Eestis inimesi, kes seda tööd teevad, et neid firmasid on ja mõned tulevad, mõned lähevad, tööstusharuna on see meil endiselt võib-olla üsna, üsna tugev ja kuna selle teenuse eest on võimalik küsida üsna korralikku hinda, lähiturgudel, siis ja tänu meie lähedusele on, on see täiesti reaalne majandusharu, mida, mida kasvatada.
Aga millal me jõuame kahesaja, kolmesaja töötajaga testimisfirmadeni, kes kasutavad ka, kuidas ma ütlen siis, mitte IKT kõrgharidusega spetsialiste, kas see üldse on võimalik, on see reaalne lähima kolme aasta jooksul näiteks?
Kolme aastaga on mul raske öelda, et see tõenäoliselt sõltub sellest, et kas siia, siia otsustatakse panna mõni suurem arendus- või testimiskeskus. Et kui see otsus tehakse, siis see on võimalik, aga kindlasti tuleb siin vaadata ka nagu selle asja teist poolt, et meie väikse riigina peaksime just keskenduma sellele, et niisugused nutikad lahendused, mis asju automaatselt teevad, et Eestis on ka mitmeid firmasid, kes selliseid lahendusi välja töötavad, et ise ka juhin ühte sellist, et, et mina arvan, et pigem Et me peaksime nagu mõlemat poolt vaatama, et meil oleks nutikad automaattestimislahendused, mida siit riigist saab väga lihtsalt eksportida ja suureks ajada, ja teiselt poolt me endiselt oleme Soome, Rootsiga võrreldes niisuguse tugeva kulu eelisega ja kui teistes sektorites õnnestub inimesi juurde tõmmata, siis Saab seda sektorit kasvatada, et siin on nagu näiteid olemas küll, et Playtechis on suured testimistiimid ja, ja nõnda edasi.
Aga sa usud seda, et meil on võimalik võtta teistest sektoritest inimesi ja neid mõistliku ümberõppeajaga teha?
Kui sinna fookust panna, siis on võimalik, jah.
Kuidas meie lähiriikides üldse nende testimisfirmadega on, et kas Soomes on testimisolukord suurepärane, kõiki asju testitakse või, või tehakse ikka Soome jaoks ka Eestis teenust, kuidas on Lätis, Peterburis?
Noh, tegelikult kui rääkida testimisvaldkonna inimestega üle maailma, siis noh, ikkagi see, mis läbi kõlama jääb, on see, et ega nutt ja hala on ikka igal pool, et ei olda nagu rahul kusagil, et alati, alati saab kvaliteet parem olla. Kui me võrdleme näiteks siin lähiriigi Soomega, siis Soome testimise või kvaliteedi juhtimise turg on minu arust Eesti omaga võrreldes kuskil noh, kolm-neli aastat ees, et meie turul toimuvad praegu umbes samasugused sündmused, nagu Soomes, kolm-neli aastat tagasi näiteks. Et see on, Eestis on see turg veel arenemisjärgus. et testijaid tuleb veel siia kõvasti juurde minu nägemuse kohaselt ja ja see teenus kui selline saab oluliselt konkreetsemalt defineeritud.
Saad sa mingeid näiteid ka tuua selle küpsemise kohta?
No kui me vaatame lihtsalt, võrrelda Rootsi-Soomega, et võrreldes siis testimisorganisatsioonide suurust võrrelduna rahvaarvuga, siis noh, Rootsis on selline ühendus nagu SAST, mis ühendab sealseid testijaid ja minu teada seal on juba ligi neli tuhat liiget, et Eesti Testijate Liidus on hetkel kuuskümmend liiget, et Rootsi on ainult üheksa või kaheksa korda suurem.
Aga tulles tagasi nüüd selle konverentsi juurde, et Raivo, millised on hetketrendid, mis on see, mille pärast tullakse siis üle Põhjamaa kokku Eestisse, et testimisest ja kvaliteedi juhtimisest rääkida, mis on need põhi, põhiteemad, mis neid inimesi siia toovad?
No selle aasta konverentsi põhiteemaks on meil arendajate ja testijate vaheline koostöö ja me oleme leidnud väga palju väga häid esinejaid. väga mitmest riigist, kes tulevad ja räägivad meile sellel teemal. Näiteks meil tulevad rääkima, kuidas tehakse mobiilide testimis, kuidas tehakse automaattestimisi, et meil on väga palju häid eksperte tulnud sellest rääkima.
No selline konverentsil tasub tulla ikkagi ainult oma ala spetsialistidel või, või ka ütleme nii-öelda inimene, ma ei ütle, et päris tänavalt, aga vähese taustaga, kes tahaks oma, oma teadmisi tõsta, on mõttekad, mõt, on mõtet tulla.
Meil on neid töötubasid ja loenguvormis esinemisi mitmele erinevale tasemele, et seal on inimestele, kellel on väga sugavad tehnilised teadmised kuni inimesteni, kes alles nuusutavad testimist.
Et mina soovitaks kõikidel klikkeritel kindlasti kohale minna ja küsida... Tööd. Seal tööd leiab kindlasti.
Kas see konverents Nordic Testing Days, ma ütlen siis küll juurde, et mis viies kuni seitsmes juuni toimub, kas ta on kuidagi perioodiline, et kas ta toimub alati Eestis, kas ta on kuidagi seotud Põhjamaadega, kas seal tulevad Põhjamaadest ainult, ka ainult esinejad või tulevad ka konverentsi külastajad Põhjamaadest?
Kui suur see on, meil eelmine aasta ligi kakssada kolmkümmend osalejat ja inimesi oli kümme pluss riigist. See aasta me ootame paremat tulemust loomulikult, nagu ikka. Aga miks meil on Nordic, siis eesmärk on saada kokku Põhjamaade testijad Soomest, Lätist, Leedust, Rootsist, sellepärast on ka meil Nordic. Regulaarsuse kohta, et see on meil teine konverents, eelmine aasta oli esimene, Et me kavatseme jätkata seda traditsiooni ja hetkel me veel keskendume Eesti peale, kuid võib-olla tulevikus kindlasti liigume edasi.
On mõtteid olnud küll, et seda karoteerima panna erinevates pealinnades, see sõltub pigem sellest, et kas õnnestub koha pealt siis sealt korraldajad nõusse saada.
No IT-konverentsi kohta rohkem kui kakssada inimest on juba väga, päris hea Eesti tulemustes, Eesti tingimustes, aga mind ikkagi häirib see, et kui me näeme, et testimine on niivõrd potentsiaalikas valdkond ja Ja sektori inimesena ma väga usun ka, et, et siin on nagu tõsine ekspordipotentsiaal peidus, et kuidas me ikkagi leiame rohkem neid ettevõtlikke inimesi, kes siia oma energiat ja, ja rahainest teeksid ja, ja püüaksid üles ehitada neid erinevaid testing house'e, kes seda eksporti võiksid nagu vedada ja teha?
No sellega on ikka sama lugu nagu igasuguste ettevõtjate leidmisega, et Ma ise usun, usun kõige rohkem seda, et Eesti arendusfirmades on hakanud tekkima järjest rohkem juba fokusseerinud testimisosakondi ja pikas perspektiivis hakkab ka seda turgu toitma, et need inimesed võib-olla tahavad ise midagi ette võtta või näevad sellel eraldiseisva sektorina nagu potentsiaali ja, ja lähevad ja teevad oma firma või spetsialiseeruvad sellele juba konkreetsemalt.
Seda on muidugi rõõm kuulda, aga lõpetuseks, teie vaatenurge, vaatenurkast lähtuvalt, see aeg, kus Eesti Vabariigis lõppkasutaja on testimismeeskonna liige ja enamus avalikest teenustest nii-öelda saavadki testitud kodanike poolt, et see aeg on läbi saamas ja Eesti tarkvaratööstust või tarkvaratööstus hakkab üha kvaliteetsemat tulemit välja pakkuma aasta, järgmiste aastate jooksul.
No praegu küll paistab, et sinna, sinnapoole on nina pööratud igal juhul, sest et üha enam riigiasutusi ja ka eraettevõtjaid noh, vaatavad ju reaalselt seda, et, et nad soovivad, et keegi vaataks tarkvaraarenduse tulemid üle ja, ja leitakse, et see ei ole enam nii-öelda nende põhi, tellija põhitöö, vaid seda saab outsource'ida.
Testimise juures jätkuvalt on ikkagi valus teema see, et meil on küll kvaliteetsed testijad, kes suudavad seda tarkvara testida IT vaatest lähtuvalt, kuid puudujääk on jätkuvalt nii-öelda ärilist mõtlemist omavate testijatega, ehk siis kui me vaatame kas või meie avalikke teenuseid, siis jah, need teenused toimivad IT mõistes, ehk siis kasutaja jõuab mingi loogilise tulemuseni, Aga see, et kas see ka kasutaja jaoks mugav on, et kas seda informatsiooni seal pole äkki liiga palju, et seda meie testijad täna välja nokkida ei suuda?
No ise küsimus on see, et kas siin on nagu testijad, kas testijad on need, kes selles süüdi on, et testijad muidugi võiksid seda avastada, noh, hea näide on meie paljukiidetud tuludeklaratsioon, mida tegelikult võrreldes muu maailmaga ongi äärmiselt lihtne täita. Aga reaalsus on ka see, et ma usun, et kaheksakümnel protsendil inimestel on, on, on seal vaja täita või ainult kolm välja või, või põhimõtteliselt vaja, vaja vajutada ainult kinnita nuppu. Ja mõnes mõttes ongi siin testija roll see, et öelda, et miks neid pagana nuppe nii palju on, et piisab ju mulle kolmest, et jätka ainult need kolm nuppu alles.
No eraettevõtted tavaliselt lähevad klientide juurde ja, ja, ja istuvad klientide kõrval ja vaatavad, mis moodi kliendid nagu kasutavad neid tarkvarasid ja, ja konkreetseid protsesse ja teenuseid, riigi puhul pigem tundub olevat nii, et teeb me mõne seadusakti valmis ja selle akti juurde käiva vormi lükkame veebi ja ütleme, et meil ongi e-teenuse, et, et, et kuidas me selle nagu ära murrame, et kuidas siin nagu testid meil abiks saaksid olla selleks, et, et need testid oleksid kliendist lähtuvad, mitte seadusvormist?
Ma arvan, et see ei olegi testijate roll, et see on rohkem just nimelt seal analüütikute roll ja, ja tuleb just lähtuda sellest, et mis on see lõppkasutaja soov, et kui ma siin vaatan mitmeid e-teenuseid, Olles ise ettevõtja, näiteks, näiteks Haigekassa pakutavad need töötajate registreerimise teenused, et on väga palju teenuseid Eestis, mis, mida ma ei peakski üldse kasutama, kuhu ma ei peakski sisse logima ja mingit nuppu vajutama, sellepärast et riigil on see info olemas, et see võiks käia täitsa vabalt automaatselt. Ja on väga palju teenuseid, mis võiksid mulle lihtsalt infoks ühe e-meili saata. Et need on asjad, kus meil on veel kõvasti minna.
Kas kuidas oleks õige teha näiteks IT-ala riigihankeid, et kas kas see, kes hangib, noh, tänapäeval ju toimub hange mingisuguse tarkvara peale ja siis mingisugune firma pakub seda, et kas siis õige oleks see, et riik nõuaks selles hankes või noh, just tegelikult ka eraettevõtte, et, et juures, et oleks ühispakkumine mingi testimisfirmaga või peaks see testimine olema alltöövõtu korras, tellitud mõnesugusest kohast, kas on äkki mingid sertifikaadid, mis on tell, testijatele, et saab öelda, et seda, seda tarkvara on testitud mingisuguse sertifikaati oma oma testijaga või? Mis need kriteeriumid on, kuidas seda osta?
Sertifikaadid on olemas, on olemas selline sertifikaat, nagu näiteks on ka teisi tarnijaid, aga mis puudutab selle, kui, kui tellida siis riigihanke korras mingisugust projekti, Siis esiteks tuleks vaadata ikkagi selle asja nagu pikaajalist kogukulu, et kui pikaks ajaks seda süsteemi tellitakse. Ja, ja tuleks vaadata noh, nagu siin teede ehitusest paralleeli tuuakse, et tuleks vaadata, et kui palju selle süsteemi üleval hoidmine maksab ikkagi võib-olla viie või kümne aasta perspektiivis. Ja sellest lähtuvalt siis kas nõuda tarnijalt, et võetakse allhankijaks siis eraldi testimisfirma või et seal firmas sees on vastava kvalifikatsiooniga inimesed juba olemas, või võtta eraldi siis nagu ehitusjärelevalves, võtta siis eraldi kvaliteeti tagav partner, kes sõltumatult annab hinnangu sellele, mis tarnitakse.
Selge, aga see oli meie tänane Restart. Kuulake meid korduses või raadio1.ee lehel podcastis, rääkisime täna pikalt testimisest, mis asi on testimine, sellest, et juuni alguses on tulemas testijate konverents, ning sellest, et testijaid on täna Eestis puudu ja neile makstakse hästi ja selle ala omandamine on mingil tasemel võimalik kiiremini kui tippprogrammeerijaks saamine. Kuulake meid taas nädala pärast, kena nädalavahetust!
[ TRANSKRIPTSIOONI LÕPP ]