ASA Quality Services räägib tarkvara kvaliteedist

Vinge testimiskonverents "Nordic Test...

2012-02-10T00:54:00.001-08:00

Vinge testimiskonverents "Nordic Testing Days 2012" ootab kvaliteedikindralitelt ja veaküttidelt teemasid, sest käimas on Call for Papers 1. märtsini!

http://ow.ly/8Zhd8

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

2011-03-07T00:29:00.000-08:00

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

2011-01-04T02:26:00.000-08:00

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

Meie igapäevane testimine

2010-12-07T05:44:00.000-08:00

Minu kätte on jõudnud ahjusoe A&A, mille peatoimetaja vastutusrikast ja auväärset positsiooni paluti täita meie kvaliteedijuhil Maili Markvardtil. See A&A number keskendub tarkvara testimisele ja selle erinevatele aspektidele ning seetõttu pean õigeks Maili artiklid ka meie blogis avaldada. On ju testimine meie igapäevane leib ja teema ise viimasel ajal väga aktuaalne, olukorras kus raha on vähe, et tegeleda PR-i ja kahjutule tõrjumisega peale katastroofi selle asemel, et veenduda enne süsteemide käikulaskmist, et seal sees ei oleks peidus mainet kõvasti kahjustavat pommi.

Mida mul veel muud üle jääb kui soovida mõnusat lugemist ja loodetavasti saame arendada aktiivset arutelu testimisest ja tarkvara kvaliteedist üldse Eesti IT maastikul, lahata müüte ja väärarusaamu ning üritame leida just selle õige koha kes peaks tarkvara kvaliteedi eest vastutama - tellija või täitja. Nüüd aga ASA esimene mõtteavaldus testimisest ja selle olulisusest.

Sander Vallaots
ASA Quality Services OÜ
tegevjuht

Meie igapäevane testimine
Maili Markvardt

Võin täiesti kindla veendumusega öelda, et igaüks meist tegeleb igapäevaelus testimisega, paljud küll alateadlikult, paljud aga kas suuremal või vähemal määral süstemaatiliselt ning eesmärgipäraselt. Milles meie igapäevane testimine väljendub ja kas see sarnaneb kuidagi tarkvara testimisele?

Selge nagu seebivesi
Kord pärast ühte ettekannet testimisest ja Eesti Testijate Liidust (ETL) küsis üks kuulajatest, endine õpetaja: „Kas te ETLis tegelete ka inimeste võimete ja oskuste testimisega. Esmalt see küsimus üllatas mind, sest ma polnud testimisele ja ETLi tegevusele päris sedamoodi mõelnud. Vastasin „Ei, aga…“ ning selgitasin, et Eesti Testijate Liit püüab aidata kaasa ainult professionaalsete testijate teadmiste ja oskuste hindamisele, võimaldades Eestis sooritada kodumaist ISTQB Certified tester Foundation Level eksamit. See on muide kõige tuntum testimise alane sertifikaat maailmas – 2010. aasta augustiks on üle maailma selliseid sertifikaate välja antud juba üle 145 000. Kui hästi järele mõelda, siis tõesti on üks levinumaid testimise liike igapäevaelus inimeste oskuste ja võimete testimine“.

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 mingil kindlal skaalal. Seega selgitamaks kas me oleme piisavalt „küpsed“, et meile omistada teaduskraad ja lõpudiplom. Niisiis võimaldab testimine, ka tarkvara testimine, hinnata objekte mingil ettemääratud skaalal. Tarkvara puhul on selleks skaalaks enamasti eelnevalt kokku lepitud nõuded, millele vastavust on testimise abil suhteliselt objektiivselt võimalik hinnata.

Kuidas hinnata kirjeldamatut?
Küllap need, kelle töökohustuste hulka kuulub muuhulgas ka töötajate palkamine ja kandidaatide intervjueerimine, teavad, milliseid „teste“ ning kuidas teha. Miks taolisi teste tehakse? Ühest küljest nõustuvad kõik tööandjad, et kindlasti on oluline leida heade oskustega ja kogemustega töötaja. Selle väljaselgitamiseks, kas inimene oskab või ei oska, küsitakse konksuga küsimusi ning antakse „koduülesandeid“, millele eeldatakse teatud vastuseid (peaaegu nagu eksamil). Selle info alusel on võimalik otsustada, kas kandidaat sobib oma professionaalsete omaduste poolest pakutavale töökohale.

Teisest küljest on märksa keerukam välja selgitada potentsiaalse töötaja neid omadusi, mis pole objektiivselt ning lihtsalt ülesannete ja küsimuste-vastustega mõõdetavad. Näiteks kui hea meeskonnamängija on kandidaat ja kui hästi sobib ta minu meeskonda? Kuidas ta käitub kriisisituatsioonis? Milline on tema motivatsioon ja töössesuhtumine? Siin võib kandidaat rääkida endast paljutki (sh ebaõiget) ja seda seejuures ise siiralt uskuda. Kuid teha „testi“, mis annaks võimaluse objektiivselt ja üheselt otsustada, on märksa raskem. Käitumist pingeolukorras on võimalik mingil määral testida, küsides tööintervjuul väga ründaval viisil otsekoheseid ja kiuslikke küsimusi, ning jälgida, kas inimene säilitab külma närvi või satub paanikasse. Seda nimetatakse stressi-intervjuuks ja selle kohta võite küsida oma asutuse personalijuhilt või lühidalt lugeda näiteks Kulno Türk’i materjalidest .

Fakt on see, et selliste simulatsioonide käigus on võimalik saada osalist infot, mis võimaldab meil luua kandidaadist ligikaudse pildi. Täpsemalt öeldes saame stressiintervjuu käigus kinnitust teatud omaduste osas – käitumine stressisituatsioonis, kriitikataluvus ning emotsionaalsus. Näiteks kui projektijuhi või kvaliteedikonsultandi kandidaadil hakkavad pärast paari ründavat küsimust käed värisema, siis pole ilmselt tegemist õige inimesega sellele positsioonile. Kuna nende rollide igapäevatöös on konfliktid tavapärased, siis rolli täitvalt inimeselt ootame oskust selliste situatsioonidega edukalt toime tulla. Jättes kõrvale inimlikud emotsioonid ja eelarvamused, võib nüüd öelda, et test oli edukas – teame, et seda inimest nimetatud kohale palgata ei sobi. See on kokkuvõttes väga hea testimise tulemus nii värbaja kui ka kandidaadi huvides – pääseme hilisemast pettumusest, kui töötaja oma kohuseid täita ei suuda. Kui inimese iseloomu sobimatust mingi ülesande täitmiseks on keeruline ja aeganõudev, vahel ka võimatu parandada, siis õnneks saab tarkvara testimise käigus leitud vigu enamasti parandada. Seega säästab iga leitud ja parandatud tarkvaraviga nii tegijaid kui kasutajaid võimalikust järgnevast meelehärmist.

Kõik mudelid on valed, aga mõned mudelid on kasulikud
Paraku võivad olla puudulikud intervjueerijate testimis-oskused ja/või on töölesoovija hea teeskleja. Seega ei pruugi kõik olulised jooned nii lühiajalisel testimisel veel ilmneda, sest limiteeritud aja jooksul pole võimalik „läbi mängida“ kõikvõimalikke olukordi. Ka tarkvara testimisel kehtib üldjuhul põhimõte, et mida erinevamaid ning ebastandardsemaid stsenaariume tarkvaras testitakse, seda parem on testimine ja seda tõenäolisemalt avalduvad vead.

Kui tööintervjuul ühtegi kriitilist viga leida ei õnnestu ning ka muudes tingimustes kokkuleppele jõutakse, siis testimine jätkub. Järgmiseks on õnnelikul uuel töötajal vajalik läbida pikaajalisem testimine – katseaeg. Katseajal on inimene juba reaalses töösituatsioonis ning täidab reaalseid ülesandeid. Kahjuks aga on katseaja järgselt töötajast loobumine seotud tööandja jaoks juba lisakuludega – töötaja otsingut tuleb taas otsast alustada, otsingute perioodiks tuleb ümber korraldada töökorraldus, uue töötaja leidmisel tuleb uut inimest taas õpetada ning toetada.

Analoogia vea parandamiseks vajalike kulutuste suuruse ja vea leidmise aja seosel on olemas ka tarkvaraarenduses. Spetsifikatsioonis leitud viga parandatakse nn paberil ja see ei jõua kunagi koodi. Oleme sellega kokku hoidnud vähemalt koodi valesti kirjutamisele kuluva aja. Arendaja poolt tehtud viga on tal enesel töö käigus teadvustada ja parandada märksa lihtsam, kui saada tagasisidet testijalt: testija peab viga otsima, raporteerima, vajadusel täpsustama, ning alles seejärel saab arendaja asuda vea põhjust välja selgitama. Seega on igati mõistlik, et arendajad testivad esmalt oma töötulemit ise nii palju kui oskavad ning alles seejärel antakse see testijate kätte. Lõppkasutajate käest tulnud tagasiside töötlemine ning arendajale arusaadavaks ülesandeks vormistamine on aga hoopis aega nõudev protsess. Seetõttu üritatakse mitmetasemelise arendustiimi ja testijate poolse testimisega lõppkasutajateni jõudvat vigade arvu kõigi vahenditega minimeerida. Niisiis, mida varem elus või tarkvaraarenduses testitulemuste abil negatiivsele tulemusele jõuad, seda parem, sest seda odavam on viga parandada või otsast peale alustada.

Maailmas on ainult üks kindel asi - muutused
Elus võtab negatiivsele tulemusele jõudmine tihti pikemalt aega, kui oodata oskame. Näiteks aasta, paar, või paarkümmend. Seda näiteks juhul, kui räägime elukaaslase või abikaasa „testimisest“. Inimene, kes esialgu tundus hea tüdruk- või poiss-sõber, kellega pidudel käia, ei pruugi osutuda näiteks heaks lapsevanemaks. Või inimene, kes on hea lapsevanem, keskendubki vaid lastele, jättes hooletusse oma kaasa ja enese vahelise ühendava sideme. Kui lapsed on suureks kasvanud, ei jää ilmselt alles ainsatki siduvat lüli huvide ega sõprade näol.

Milles on probleem antud juhul? Esialgsed „testid“ ju läbiti edukalt, et niikaugele üldse jõuti? Võti seisneb selles, et aja jooksul muutub nii testitav objekt (subjekt), kui ka ootused selle suhtes. Esimesel juhul, kui heast peokaaslasest ei saa head lapsevanemat, muutuvad teise poole ootused. Teisel juhul, kui kaob ühendav lüli, on muutunud objektid (subjektid), aga erinevates suundades, ega vasta enam esialgsetele ootustele.

Tarkvaramaailmas juhtub täpselt sama. Selleks ajaks, kui tarkvara valmis sai, on äripoolel valmistehtud „õuna“ asemel hoopis „apelsini“ vaja. Või siis oli neil tegelikult kogu aeg „apelsini“ vaja, aga nad ei teadnud seda ise või ei suutnud seda piisavalt hästi väljendada. Samuti on tarkvara puhul tüüpiline regressioon ehk „eile see töötas veel“, aga täna tehti parandus või täiendus, mis mõjutas juba olemasolevat ebasoovitavas suunas. Tarkvara puhul ongi oluline osata piisavalt hästi nõudeid koguda ja esitada. Kuidas vajadusel oma testimist äriolukorrale vastavalt piisavalt agiilselt korraldada, tutvustab värskes A&A väljaandes Valli artikkel. Regressioonivigadele kiirelt jaole saamisest testimise automatiseerimise abil tutvustab Raimond. Uuest suunast testimise efektiivsemaks muutmisel mudelipõhise testimise abil tutvustab minu selleteemaline artikkel.

Testimine – universaalne vahend tagasiside saamiseks
Lisaks tarkvara testijatele on professionaalseid testijad, kes konstruktiivse lõhkumisega oma igapäevast leiba teenivad, olemas ka muudel elualadel. Näiteks lennukeid testivad elukutselised katsepiloodid, kes võtavad uue või parandatud omadustega lennuki (prototüübi) enne, kui see tunnistatakse tootmiskõlbulikuks. Miks katselende tehakse? Esiteks selleks, et veenduda, et lennuk suudab täita oma tavapärast otstarvet. Veelgi enam aga selleks, et selgitada välja täpne piirangute hulk, milles antud lennukit on ohutu käitada.

Lennuki testimisel tehakse selgeks, missugune on lennuki minimaalne kiirus ja kaldenurk, ilma et lennuk alla kukuks; milline on maksimaalne ohutu kiirus, et konstruktsioon ei laguneks jne. Lennuki testijal pole tihti ees konkreetset „spetsifikatsiooni“, millele lennuk peab vastama, vaid testide käigus ta uurib, mida lennuk suudab ja talub. Niisiis tuleb lennukeid testida ka olukorras, kus testijal pole teada täpseid nõudeid, kuid ta võib lennukit uurida oma kogemusest, leidlikkusest ja uudishimust lähtuvalt. Tarkvaras on sellise testimise vasteks uuriv testimine ning sellest, räägib lähemalt Ervini artikkel.

Lisaks päris uute mudelite katsetamisele testitakse ka konkreetset lennuki eksemplari kokkupanemise järgselt, et välistada võimalikud koostevead ehk praak. Olenevalt lennukist ja tema otstarbest võtab see protseduur mitusada kuni mitutuhat lennutundi. Näiteks nn do-it-yourself-tüüpi kerglennukikomplektist kokku pandud lennuki registreerimiseks peab sertifitseeritud katsepiloot sellega lendama umbes sadakond lennutundi. Seejärel kuulutatakse lennuk lennukõlbulikuks, sest on olemas piisav kindlus, et lennuk ei kujuta endas ohtu ei temaga lendajatele, ega läheduses viibijatele. Tarkvaramaailmas on selle analoogiks kasutusse vastuvõtmise test (operational acceptance test), mis viiakse läbi vahetult pärast tarkvara paigaldamist toodangukeskkonda eesmärgiga leida paigaldamisel tekkinud juhuslikke vigu või vigu, mida pole võimalik enne toodangut avastada (näiteks testkeskkonna piiratud võimaluste tõttu).

Kui võrrelda mõne Airbus A380 katsetusi do-it-yourself lennuki 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 rohkem teste kui pisilennuk. Tarkvara testimisel on fakt see, teismelistele mõeldud mobiilimängu testitakse ilmselt vähema põhjalikkusega kui südamestimulaatori kontrollerit. Sellist lähenemist nimetatakse riskipõhiseks testimiseks, kus testimise ulatus ning meetodid tulenevad otseselt riskidest ehk sellest, milliseid tagajärgi võimalik viga endaga kaasa tuua võib. Riskipõhist testimist kirjeldab uues A&As täpsemalt Raivo artikkel.

Mis maksab rohkem – testimine või testimata jätmine?
Eelpoolkirjeldatud testide käigus panevad katsepiloodid mängu oma elu, et teistel oleks edaspidi ohutu lennata. Näiteks sai 2009. aasta kevadel surma lennukitootja Cessna katsepiloot , kuna lennukit ei õnnestunud testi käigus esile kutsutud pöörisest välja tuua ning ka piloodi päästmiseks disainitud langevarjusüsteem ei toiminud ootuspäraselt. Kahjuks ilmnes see alles reaalse testimise käigus. Seetõttu võib nimetatud juhtumit käsitleda kui õnnestunud testi, sest leiti viga. Inimlikus ja majanduslikus mõttes oli siiski tegemist katastroofiga. Õnneks tarkvara testijad oma elu igapäevaselt ohtu ei pane, kuid kindlasti ühendab katsepiloote ja tarkvara testijaid keskendumine läbikukkumisele, et arendaja ja lõpptarbija saaksid nautida edu. Seetõttu on testija oma töökohustusi täites professionaalne kahtleja ja igapäeva standardeid arvestades võiks öelda isegi, et paranoik.

Katsepilootideks, muide, palgatakse ainult kõige kogenumaid piloote . Küllap on selleks ka oma kindlad nõuded vastavalt sellele, kas testida on vaja pisikesi eralennukeid või ülisalajasi sõjaväelennukeid. Miks just kõige kogenenumaid? Selge see, et kogenud piloot oskab ka halvas olukorras õigesti reageerida ning suurema tõenäosusega lennuki niivõrd-kuivõrd tervelt maa peale tuua. Ka piloodi enda päästmine on kahtlemata majanduslikult üsna hästi põhjendatud. Siin saab paralleele tõmmata ka tarkvara testimisega. Tihti on testija ametikoht IT organisatsiooni lävepakuks, millest siis vaikselt karjääriredelit mööda üles ronima hakatakse. See on suhteliselt odav, kuid riskantne lähenemine, kuna väheste IT kogemustega inimene ei suuda anda nii kvaliteetset tagasisidet, kui inimene, kes on võimalikud vead juba ise läbi teinud. Niisiis saavad parimad testijad analüütikutest, arendajatest ja arhitektidest, kuna oma varasema kogemuse tõttu oskavad nad tihti vigu juba ette näha ning vältida nende tekkimist.

Tarkvara testimisel on kuluefektiivsus kindlasti oluline ning see sõltub suuresti vastusest küsimusele „kui palju testimist on piisavalt?“. Rusikareegel ütleb, et testimisel tuleb leida tasakaal testimise ja vigade ennetamisele kulude ning vigade tagajärgede likvideerimise kulude vahel. On selge, et kui infosüsteemis oleva turvaaugu tõttu lekivad konfidentsiaalsed isikuandmed, siis võib tarkvara tellijat (ning miks mitte ka arendajat?) oodata kulukas ning mainele laastavalt mõjuv kohtuasi. Seetõttu tuleb sellise vea toodangusse jõudmist kõigi meetmetega vältida, kas siis ennetades vea tekkimist või vea leidmisel selle parandamisega. Vastupidine näide oleks aga internetipoe kohta, kus võib-olla üks miljonist kasutajast 3 aasta jooksul lahkub poest konkurendi poodi, sest ei leia õiget toodet tema jaoks piisavalt kiiresti. Selline „kaotus“ on poe omanikule ilmselt vähem kulukas kui põhjalik kasutuskõlblikkuse test ning sellele järgnev poe ümberdisainimine.

Lennuki testimise põhjalikkusest sõltub temaga reisijate elu ning tema väljatöötajate hea maine. Tarkvaraga on täpselt samamoodi – tarkvara viletsa kvaliteedi läbi on midagi kaotada nii lõppkasutajatel kui ka omanikul ja väljatöötajal. Testimine on seega vahend hingerahu ja kindluse saavutamiseks ning riskide vähendamiseks talutavuse piirideni. Objekti, sealhulgas tarkvara, pole mõtet testida, kui tema võimaliku tõrkumise puhul pole midagi kaotada. Kui aga kaalul on inimelud, keskkond, suured summad raha või midagi muud olulist, siis aitab testimisest saadav info õigel ajal võtta vastu õigeid otsuseid.

Kelle viga?
Tuletame meelde lennujuhtimistarkvara viga , mille käigus kaotas Los Angeles’i lennujuhtimiskeskus kontakti 400 lähialas viibiva lennukiga. Esmalt võib jääda mulje, et vea, mis intsidendi põhjustas, tingis süsteemi käitajate ebapädev käitumine. Tarkvarasüsteemi ei taaskäivitatud piisavalt tihti, nagu ette nähtud juhendis. Põhjuseid täpsemalt uurides selgus aga, et kaose tinginud viga oli tarkvara tootja jaoks teadaolev viga, kuid ta ei suutnud adekvaatselt hinnata selle mõju lennujuhtimiskeskuse tööle. Teisisõnu, testijad olid teinud oma töö vea leidmisel, kuid puudulikuks oli jäänud kommunikatsioon teadaolevate vigade kohta ning tarkvara ostja poolne mõjuanalüüs. Kui selline viga jäi tähelepanuta, tekib küsimus, kas ostja teostas piisavad vastuvõtutestid ja kas tal oli selleks üldse piisav kompetents?

Siin jõuame tõdemuseni, et testimine üksi ei suuda tarkvara kuidagi paremaks muuta. Laiemalt võttes tegeleb tarkvara kvaliteedi tõstmisega valdkond, mida nimetatakse kvaliteedijuhtimiseks , kuid keskendume fookuse hoidmise nimel siiski testimisega vahetult seotud aspektidele. Niisiis on tarkvara paremaks muutmiseks vajalik esmalt vigade parandamine, sest kunagi ei saa anda 100% kindlust, et tarkvara kasutatakse täpselt kindlaksmääratud tingimustes ja keskkonnas. Teiseks aga on oluline vigadest ja nende mõjust arusaamine. Kas tegu on kosmeetilise vea või äritegevust takistava veaga? Selliste otsuste tegemiseks on hädavajalik põhjalikult tunda tegevusvaldkonda, mida konkreetne tarkvara toetab. Kes aga tunneks oma äri paremini kui tarkvara tellija ise?

Tarkvara eduka juurutuse üks saladustest on kahtlemata tellija kaasamine ning harimine tarkvaraarenduse ala. Tihti ei oska või ei viitsi tellijad küsida „õigeid“ küsimusi, vaid eeldavad, et tarkvaraarendaja on ekspert ka nende äris või vähemasti oskab lugeda mõtteid. Hea tellija, kui tarkvaraarendaja oleks ekspert Sinu äris, siis oleks ta ilmselt juba Sinu konkurent.

Tarkvaraarendajad aga eeldavad, et nad teavad valdkonnast isegi piisavalt palju, või siis ei oska ega viitsi tellijat tema mugavustsoonist välja tirida. Hea tarkvaraarendaja, kuna Sinu tellija igapäevatööks ei ole tarkvaraprojektide läbiviimine, siis on loomulik, et ta vajab selgitamist ja õpetamist, kuidas seda edukalt teha. Arendusprojekt, sealhulgas ka selle testimine, nõuab mõlema osapoole pühendumist maksimaalse tulemuse nimel. Võib öelda, et arendusprojekti käigus arendatakse küll tarkvara, kuid arenevad nii tellija kui täitja.

Otsus või hasartmäng?
Tulles tarkvara testimise juurest tagasi teiste objektide testimise juurde - kas Sina vaatasid uue auto ostu planeerides, mitu „tärni“ Su tulevane auto EURO NCAP testides sai? Mis järeldusi Sa sellest tegid või oleksid võinud teha – kas jätsid auto vahetamata, leides, et vana on veel küllalt hea ja turvaline? Valisid kallima auto, mis on ühtlasi ka turvalisem? Ignoreerisid tulemusi, lootes, et Sinuga midagi ei juhtu? Kõik need on otsused, mida võiks auto ostmisel kaaluda, kuid lõpliku valiku tegemiseks peab otsustaja käsutuses olema piisavalt usaldusväärne info.

Autode testimisel simuleeritakse erinevaid ohu- ja õnnetussituatsioone, et uurida, kui turvalised on autod sellistes olukordades nii autos viibijatele kui ka teistele kokkupõrke osapooltele (nt jalakäijad). Milles väljendub turvatestimine tarkvara juures, seda kirjeldab põhjalikumalt Maidu artikkel. Euro NCAP on aga sõltumatu organisatsioon, mille huviks on anda objektiivne hinnang Euroopas enimmüüdud autode turvalisuse kohta nii autojuhtidele kui autotootjatele, ta teenib korraga mõlema osapoole huve.

Autojuhi kui autotööstuse tarbija jaoks on oluline, et temal enesel ja teistel autos viibijatel oleks turvaline olla, ehkki tal enesel ei pruugi olla piisavalt kompetentsi, et ise osata turvalisust hinnata. Eks ka tarkvara tellijale on oluline, et keegi annaks kindluse tarkvara nõuetele vastavuse osas. Kindluse saamiseks on erinevaid võimalusi. Tihti piirdutakse arendusfirma kinnitusega kvaliteedi kohta, kuid sõltumatu hinnangu saamiseks kasutatakse ka kolmanda osapoole poolt teostatavat testimist või auditit. Seda eriti juhul, kus tellijal enesel pole piisavalt oskusi või aega, et põhjalikult testida.

Autotootjate jaoks on testitulemused aga hindamatu tagasiside, kuidas oma tooted paremaks ning ostjaskonnale ihaldusväärsemaks muuta. Niisiis on testimine ja sellest saadav info väga oluline sisend paremaks saamisel ka tarkvaramaailmas. Testijad leiavad vead enne kui kliendid või kasutajad, ning aitavad sellega teha arendajatel paremat tarkvara, saavutada paremat mainet ja suuremat usaldusväärsust.

Kolme lausega…
Testimine on protsess, mis konverteerib testitava objektiga seotud riskid infoks nende riskide kohta. Testitakse ainult neid objekte, mille tõrkumisest midagi olulist sõltub, näiteks lennukeid, autosid ja tarkvara. Saadud info on ühest küljest tagasiside, mis aitab saada paremaks, teisest küljest aga oluline sisend, mille alusel võtta vastu läbimõeldud otsuseid. Head otsused ja soov saada paremaks koos kübekese õnnega on suhteliselt kindel tee oma eesmärkide saavutamise poole.

NB. Kui leidsid ülalolevast tekstist mõne vea, siis võid selle raporteerida maili@asaquality.ee või kirjutada otse kommentaaridesse.

Viiteid jutu seest ja muidu kasulikku lugemist:
http://www.testijateliit.ee/ – Eesti Testijate Liit – testimisest huvitatud eraisikute organisatsioon, mille missiooniks teadvustada testimise kui distsipliini olemust ning aidata kaasa erialase oskusteabe levitamisele ja kompetentside arendamisele

http://infutik.mtk.ut.ee/www/kodu/jvju/personali-juhtimine-05.pdf - Personali juhtimine

http://www.justkitplanes.com/ - ehita endale ise lennuk ~300 000 Eesti krooni eest

http://www.airport-data.com/forums/topic1123.html - Cessna: ebaõnnestunud katselend või õnnestunud test?

http://www.slideshare.net/shakeeiil/software-failure-air-traffic-control-system - Lennujuhtimise ajaloo halvim õudusunenägu

http://www.asaquality.ee/teenused/kvaliteedijuhtimine - kvaliteet juhtub, kui oled kõik eelnevalt teinud õigesti

http://www.euroncap.com/home.aspx - Euro NCAP on organisatsioon, mis pakub nii juhtidele kui autotootjatele sõltumatut hinnangut Euroopas enimmüüdud automarkide turvalisuse kohta

Seminar "Arengud ja võimalused IT-s"

2010-10-27T08:39:00.001-07:00

Hommikuseminar toimub 11. novembril Swissôtel Tallinna 30. korruse saalis (Tornimäe 3, Tallinn).
9:00 - 9:30 Hommikukohv, kogunemine
9:30 - 9:45 Seminari avamine
Priit Lätt, advokaadibüroo GLIMSTEDT juhtivpartner

9:45 - 10:10 ITechLaw
Hele Karja, advokaadibüroo GLIMSTEDT
Hele räägib maailma juhtiva tehnoloogiaõiguse
organisatsiooni ITechLaw konverentsil 27.10-29.10.2010 kajastatud uudistest ja arengutest (info)tehnoloogia õiguse valdkonnas.

10:10 – 10:40 Creative Commons Eestis
Ene Koitla, Eesti Infotehnoloogia Sihtasutus
Ene tutvustab Creative Commonsi projekti Eestis – kuidas see kõik algas, miks see tähtis on ja mis saab edasi.

10:40 – 11:10 Riskid infotehnoloogias Maili Markvardt, ASA Quality Services
Maili tutvustab IT riske, kust need tulevad (alates hankest ja sisenditest arendajale) ja kuidas neid riske maandada.

11:10 – 12:00 Eesti IKT sektor - kas jää sulab?
Taavi Kotka, Eesti Infotehnoloogia ja Telekommunikatsiooni Liit, AS WebMedia
Taavi annab ülevaate Eesti IKT sektori viimastest arenguaastatest ja lähiaja arengusuundadest.

Seminarile palume end registreerida kuni 5. novembrini k.a e-posti aadressil: glimstedt@glimstedt.ee või telefonil 630 9170.

Osavõtt tasuta!

EURO seminar

2010-09-07T05:40:00.001-07:00

Swedbank ja tarkvarakvaliteedi ettevõtte ASA Quality Services korraldavad ühepäevase praktilise seminari organisatsioonide võtmeisikutele , kes viivad läbi ja vastutavad ettevõtte tarkvarade tulemusliku EUROle ülemineku eest. Keskendutakse praktilistele küsimustele ja esinejateks on spetsialistid, kes on tegevad erinevate ettevõtete ja organisatsioonide EURO projektis. Peaesinejaks on Slovakkiast pärit Andrej Bradac, kes aitas telekomi ettevõttel Orange Slovensko minna üle eurole 2007-2009.a. Peagi tulemas lisainformatsiooni

ASA Quality Services OÜ aitab EUROle üle minna

2010-08-25T04:35:00.001-07:00

Eurole sujuva ülemineku tagamiseks toimub alates €-päevast kahe nädalane periood, mil kroon ja euro on sularahas võrdväärsed maksevahendid. Kauplustes saab maksta nii kroonides kui eurodes, vahetusraha antakse üldjuhul tagasi eurodes. Pärast antud kahe nädalast perioodi on Eestis ainsaks maksevahendiks Euro. Mismoodi tagada oma organisatsiooni võimekus sellise olukorraga ilma suuremate probleemideta toime tulla? Loe lähemalt siit