Ettevaatust! Satikad taskus!

Siinkohal ei pea ma silmas puuke, kes kevade saabudes välja ronivad ja inimestele kannatusi põhjustama hakkavad. Taskusse lähevad satikad hoopis koos sinu nutiseadmega, täpsemalt seal peal töötava tarkvaraga.
Tegelikult ei ole suurt vahet, kas tõrgub infosüsteem su arvutis, mobiilne veebileht, äpp telefonis või tahvlis - ühevõrra ebamugav on see nii või teisiti. Kasutajana sa läksid sinna mõnda vajalikku tegevust tegema, kuid tarkvara takistab sind eesmärgi saavutamisel.

Niisiis kehtivad mobiilitestimisel kõik "tavalise" testimise reeglid, aga on veel palju muudki, millega arvestada.

Lisakeerukus tuleneb näiteks nii seadme füüsilistest parameetritest, andmeühenduse olemasolust,  tüübist ja kvaliteedist kui ka erinevate platvormide rohkusest ja fragmenteerumisest. Kui ei usu, tee oma kontoris või sõpruskonnas küsitlus ja loe kokku, mitu erinevat seadet mitmelt erinevalt tootjalt mitme erineva operatsioonisüsteemi versiooniga, ekraani suuruse ja resolutsiooniga said.
Rääkimata sellest, et tavaarvutis toimetavat infosüsteemi üldjuhul ei patsutata ega raputata (gestures) ja samuti ei ole ohtu, et kasutaja nuppudele pihta ei saa (sest need on liiga väikesed või päikese käes liiga kehvasti nähtavad), samal ajal kui ta diivanil lesib või hoopis bussi peale jookseb. Arvutihiir on teatavasti suhteliselt täpne tööriist, erinevalt potentsiaalselt tömbist sõrmest.
Samuti tekib testimisele mõeldes põhjendatud küsimus, kas mul peavad kõikvõimalikud seadmed olemas olema, või kuidas ma muidu kontrollida saan, et ikka kõigi kasutajate telefonidel kõik õigesti toimib. Ja kui mu äpp on mõeldud kasutamiseks enam-vähem üle maailma, siis kuidas ma tean, et see Jaapanis ka töötab. Ja Uus-Meremaal.
Luban, et mobiilsete rakenduste testimisel (ja analüüsimisel, ja arendamisel) tekib hulk uus võimalusi ja kohustusi, mis tulenevad sellest, et testitav tarkvara .... käib kasutajaga kõikjal kaasas.

Erinevaid nüansse, soovitusi ja lahendusi on palju, kuid minu jaoks kõige olulisemad on järgmised:

1. Tunne oma kasutajat. Missugust seadet ta tõenäoliselt kasutab (pigem high- või low-end, platvorm) ja missuguses keskkonnas ta rakendust kasutab (kodus-tööl-puhkehetkel-elukriitilisel hetkel) ning loomulikult - mida kurja võivad võimalikud satikad talle põhjustada. Selle infoga saab juba üksjagu pihta hakata, et testimisele mõistlikud piirid seada nii testitavate stsenaariumide kui ka reaalsete seadmete vs emuleerimise taskaalu mõttes.
2. Ära unusta mobiilivaldkonna tüüpilisi nõudeid püstitada ja kontrollida. Mobiilses seadmes on võimalik kasutada asukoha, güroskoobi, kiirendusanduri jm füüsilise keskkonna anduritest saadavat infot. Samuti ei tasu unustada, et telefoni võiks lisaks äppimisele olla võimalik kasutada ka helistamiseks ja sõnumite saatmiseks. Ja et kasutajad üldjuhul solvuvad, kui äpp nende seadme aku 20 minutiga tühjaks imeb (loe: soojuseks muundab, nii et seadmel võib soovi korral liha grillida). 
3. Arvesta, et nii seadmed kui ka nende baastarkvara uuenevad kiiresti. See loob täiendava võimaluse ootamatute tõrgete tekkeks. Siinkohal võivad abiks olla mõistlikult automatiseeritud testid, mis aitavad kiirelt ja suhteliselt vähese vaevaga teada saada, kas tarkvara uuenenud platvormil ka ikka veel töötab. Kuna ka üle päeva veaparanduste saatmine kasutaja telefoni on nii kasutaja kui arendaja jaoks tüütu, siis on kõigile mugavam olulisi vigu mitte toodangusse lasta. Pea aga meeles, et automatiseerimine on vaid osa heast testistrateegiast - mobiilimaailmas on oi-kui-palju nüansse, mille headust saab hinnata vaid inimene (vt punkt 1).

Head mobiilset testimist! 

Sõltumata aastaajast, ära lase satikaid iseenda ja oma klientide taskusse!

Retsept tervisliku koogi ja tervisliku tarkvara valmistamiseks

ASAs on saabunud kevade puhul tervisliku koogi väljakutse. Me armastame kooke ja sööme neid aastaringselt, aga väikese vahelduse mõttes... kokkuvõetult tähendab see, et igal nädalal järgneva 8 nädala jooksul valmistab üks meist kolleegidele tervisliku koogi. Missugune kook on "tervislik", selles me ühele meelele ei jõudnudki, aga igaüks võib sellele oma lähenemise välja pakkuda.
Koogivõistluse avakoogiks sai kookosekook, mis sai üldise heakskiidu osaliseks ja võimalik, et sinagi soovid seda teha proovida.

See on suhteliselt lihtne: võta päris palju seda piima, mis pole lehma seest. Sega sinna sisse erinevaid jogurteid (lehmalise päritoluga). Siis lisa želatiini - piisavalt, et tarretuks, aga mitte liiga palju, et ei oleks nagu kummikomm. Magustamiseks pane suhkru asemel mett maitse järgi ja vaniljet näpuotsaga. Lisada võib veel konservmango tükke ja et koogi mõõdu välja annaks, ka kaerahelbeküpsisepuru. Kaunistuseks vaarikaid, melissilehti ja kassikäppi.

Sellise ülesande järgi valmistades on võimalik, et tuleb päris hea kook, vähemalt sama hea või isegi parem kui pildilolev. Samas on võimalik ka... et ei tule. Kui selle retsepti üle tõsiselt mõelda, siis tekib ilmselt erinevaid küsimusi, näiteks:

• Mis piim see on, mis ei ole lehmast? Variante on väga palju erinevaid, alates lambapiimast kuni linnupiimani, aga mina kasutasin kookospiima.
• Mis jogurt? Jogurteid on väga palju erinevaid, kuid mina kasutasin türgi jogurtit, kreeka jogurtit ja siis veel ühte teist kreeka jogurtit, sest kookospiim ise + mesi on juba suhteliselt lääged, seega mõni maitsestatud jogurt oleks olnud liiast. Miks ma kasutasin erinevaid? Sellepärast, et ei osanud ühte valida.
• Mett maitse järgi on umbes kui palju? Noh, tegelikult ei ole probleem, kui segu jooksvalt maitsta JA on terve suur purgitäis mett kodus olemas. Probleem on siis, kui pead mett ostma - kui suur purk valida? Ma arvan, et minul läks umbes... 5 supilusikatäit Võrumaa mesilaste kuldset käpatööd.
• Aga kui mulle mango üldse ei meeldi, kas siis võib seda asendada näiteks ananassikonserviga? Aga värskete ananassitükkidega? Kiiviga, mis on samuti tasakaalustavalt hapu ja võiks sobida? Ananassikonserv sobib, kuid värske ananass želatiiniga ei tarretu (keemilistel põhjustel). Samamoodi on ka kiiviga, kuid kiivi ei sobi lisaks hästi piimatoodetesse - tulemuseks võib olla mõru maitsenüanss.
• želatiini.. Ka želatiini peab oskama korrektselt kasutada, nt paisutada tuleb külmas vees, sulatades ega ka hiljem keema lasta ei tohi, et kõik ootuspäraselt toimiks.
• Kassikäpad?!!? Jah, šokolaadist.

Seega on analüüsidokument või spetsifikatsioon tarkvara koostamiseks paljuski nagu retsept koogi või toidu valmistamiseks.
Mõnedes asjades tuleb raudselt kokku leppida, et tulemus vastaks ootustele (nt ei sisalda valget suhkrut ja nisujahu), tehniliselt õnnestuks (nt želatiini kasutamine), aga midagi jääb alati katsetamise ja töö käigus otsustamise rõõmuks (võimalus leida värskeid vaarikaid).
Kui nii tellija kui tegija on kogenud sama valdkonna koogi / tarkvara tegemisel kogenud, siis on täpne lähteülesanne tulemuse saavutamise seisukohalt vähemkriitiline. Kogemus tasakaalustab, sest üks oskab küsida ja/või teine vastata ja juhtida tähelepanu.
Mida väiksem on osapoolte kogemus, mida uuem ja/või suurem on ülesanne, seda rohkem on analüüsis vaja detailsust, läbirääkimist, selgitamist, katsetamist ja seega - aega.

Ja koogi retsept (suurema tõenäosusega) taasesitamist võimaldavas vormis on järgmine:
Kogus: 15 portsjonit, mis mahuvad 280ml klaasidesse
Kookospiim (1 liiter)
Türgi jogurt (370gr)
Kreeka jogurt (380gr)
Teine kreeka jogurt (150gr)
Mesi (200ml)
Vanilje (näpuotsaga)
Mangokonservist mangotükke (2 ca 300ml purki)
Digestive suhkruvabasid küpsiseid (ca 10tk)
Želatiini (ca 100gr)
Kaunistuseks vaarikaid, melissi, kassikäppasid (šokolaadist)

Valmistamisaeg ca 45min + 4 tundi tarretumiseks.
Želatiin pane esmalt külma vette paisuma, seejärel sulata veevannil.
Soojenda kookospiima tasasel tulel 10kond minutit, aga ära keema lase. Sega sisse mesi ja vanilje. Soojasse segusse sega peene joana valades sulatatud želatiin.
Lase segul jahtuda (nii et sõrme ei kõrveta), sest liiga kuumale segule jogurtit lisades võib želatiin hakata tarduma ning tekivad tükid. Sega jogurtid ülejäänud seguga ühtlaseks massiks. Lase jahtuda toatemperatuurile.
Klaaside põhja pane mangotükke ning peale vala jogurti-piimasegu. Pane klaasid külmkappi ja lase seal tarretuda vähemalt 4 tundi. Enne serveerimist puista peale endale sobivas koguses küpsisepuru, vaarikaid ja/või muid meelepäraseid lisandeid.

Viis küberturvanippi tavakasutajale

Internet ei ole juba ammu enam turvaline paik. Kõikvõimalikud sihilikult ja kogemata süsteemidesse istutatud vead aitavad tänapäevastel kurjategijatel virtuaalseid kanaleid kaudu priskeid varandusi kokku ajada. Olukorda ära kasutades on tekkinud palju erinevaid turvalahendusi pakkuvaid asutusi, mis üksteise võidu pakuvad just seda õiget toodet või teenust ohutunde eemaldamiseks. Paraku jääb ainuüksi mõnusa ja turvalise tunde tekitamisest väheseks. Pigem aitab valedele alustele rajatud enesekindlus küberkurjategijatel kiiremini oma eesmärke saavutada.

Turvaaukudest tulvil netiteekond

IT spetsialistidele on hästi teada tõsiasi, et igasse süsteemi on võimalik sisse murda. Kuna tarkvara täielik testimine on võimatu, siis pole kunagi võimalik absoluutselt kõiki tarkvaravigu vältida. Isegi kui leiduks ideaalselt turvaline tarkvara, siis väga suure tõenäosusega on selle kasutajaks inimesed. Inimesi on aga võimalik mitmel eri viisil manipuleerida ning piisavalt hästi varustatud kurjategijad (või kolme- ja neljatähelised organisatsioonid) leiavad varem või hiljem viisi, kuidas oma eesmärgini jõuda. Seega tekib küsimus, kas tuleks paranoiliselt arvutitest võõranduda või hoopis kübermaailma ohtudega leppida. Kuna arvutitest võõrandumine on tänapäeva infoühiskonnas suhteliselt keeruline, siis valivad paljud ohtudega leppimise tee. "Kasutan jah ikka veel Windows XP-d, aga see ju töötab." "Räägitakse jah, et tuleks arvutit regulaarselt uuendada, aga see on ju hästi tüütu." "Tean küll, et piraattarkvara on ebaseaduslik ja ohtlik, kuid kõik ju kasutavad seda." "Mis need häkkerid ikka minu arvutiga teha saavad?" Selline lähenemine tekitab aga tarbetuid turvariske, mida saaks vähese vaevaga vältida.

Olukord on parem, kui paistab

Tavakasutajatele lohutuseks võib öelda, et interneti turvaolukord ei ole sugugi nii hirmus, kui esmapilgul paistab. Näiteks leidis GCIG (Global Commission on Internet Governance), et küberrünnakute hulka vaadatakse tavaliselt väljaspool konteksti. Nimelt on loogiline, et interneti levik toob endaga kaasa ka küberkurjategijate ning küberintsidentide laialdasema leviku. Kui aga vaadelda küberrünnakutega kaasnevaid näitajaid normaliseeritud kujul (ehk suhtarvuna, arvestades ka keskkonna muutumist), siis selgub, et olukord tervikuna on muutumas turvalisemaks.

Lisaks on tekkinud positiivne trend vastutuse suurenemise suunas. Kui kümmekond aastat tagasi kuvati küberrünnaku ohvriks langenud organisatsiooni pigem õnnetu ohvrina, siis praegu võib hoolimatus klientide andmetega ringi käimisel kaasa tuua kohtuasja, mainekahju ja veel mitmeid ebameeldivusi.

Eelmainitu ei tähenda aga kaugeltki seda, et tavakasutaja peaks end muretult tundma. Kõikvõimalikud andmelekked ja pahavaraga nakatumised algavad just pahatihti ühest pahaaimamatust tavakasutajast. Õnneks on mitmeid lihtsaid viise, kuidas oma turvataset märkimisväärselt tõsta.

1. Uuendused

Kuigi uuenduste paigaldamine on sageli tüütu, on oma arvuti ajakohastamine esmatähtis punkt turvalisuse tagamisel. Kui küberkurjategijatel õnnestub lappimata turvaauku ära kasutades kogu arvutit kontrollida, siis ei ole teistest turvameetmetest enam suurt kasu.

2. Tugev autentimine

Kasuta tugevat parooli (parem sala-lause, kui lihtsalt sõna) ning mitmeastmelist autentimist. Erinevate tugevate paroolide haldamiseks on hea kasutada spetsiaalset paroolihaldustarkvara. Isikliku tähendusega kuupäevad ja lähedaste nimed on targem salasõnadest välja jätta.

3. Erinevate brauserite kasutamine koos abistavate pluginatega

Kasuta privaatsust suurendavaid pluginaid (nt Privacy Badger) ja erinevaid brausereid. Näiteks tööasjadeks Mozilla Firefox'i ja meelelahutuseks Google Chrome'i. Nii on praktiliselt välistatud, et meelelahutuslikule leheküljele (nt uudisteportaal) tunginud pahatahtlik koodijupp pääseks ligi tundlikule informatsioonile (nt tööalased e-kirjad).

4. Krüpteeri, varunda ja krüpteeri

Krüpteerimine muudab andmed kõrvalistele isikutele loetamatuks. Oma privaatsusest hoolivatel arvutikasutajatel tasuks kindlasti hoida tundlikke faile krüpteeritud kujul. Soovitav oleks krüpteerida kogu kõvaketas ning varukoopiad. Varukoopiaid hakatakse tegema tavaliselt alles siis, kui vähemalt üks kord on kõvaketas saladuslikult loetamatuks muutunud või andmed muud moodi äkitselt kadunud. Targem oleks teha regulaarselt varukoopiaid kas siis välisele kõvakettale (või mälupulgale) või mõnda pilveruumi (vastava teenuse pakkujaid on mitmeid). Välisele kõvakettale või mälupulgale andmeid salvestades tasub meeles pidada, et tundliku sisuga failid tasub ka seal hoida krüpteerutuna.

5. Ole paranoiline (mõõdukal määral)

Lihtne reegel ütleb, et kui miski on liiga hea, et olla tõsi, siis nii see ka on - suurem osa uskumatutest vedamistest (nt loteriivõit või pärandus Nigeeriast) on tegelikult petuskeemid, mille eest pahatihti ei suuda kaitsta ka paremad arvutikaitse tarkvaralahendused. Lisaks internetist saabuvatele rõõmusõnumitele tasub ettevaatlik olla ka ähvardavate ja kurbade teadete suhtes. Teavitused arvutis pesitsevast viirusest, sotsiaalvõrgustiku sulgemisest või tuntud inimesega juhtunud õnnestusest võivad kõik olla järjekordsed küberkriminaalide katsed lihtsameelsete kasutajate meelitamiseks. Seega tasub linke pommuudistele avada näiteks eraldi brauseris (kuhu on paigaldatud NoScript plugin) või jätta üldse avamata.


Paranoilisemad tehnikahuvilised leiavad lisaks mainitud punktidele veel mitmeid kasulikke mõtteid Linuxi sihtasutuse juhendist tööarvuti turvamiseks. Kuigi juhend on eelkõige Linuxi kasutajatele suunatud, on mitmed põhimõtted rakendatavad ka teiste operatsioonisüsteemide korral. 

Kes, mida ja kui palju peaks testima, et oleks "piisav"?

Kui tihti oled kuulnud tarkvaraarendusprojektidest, mis eelarves ei püsi? Või ajakavas? Kui palju seda su enda projektidega juhtunud on? Kui meenus vähemalt kaks (või üks, aga hästi suur), loe edasi. Loodetavasti aitab.

Mis on testimine ja miks see aidata võiks?

Ühe rahvusvahelise definitsiooni järgi on testimine protsess, mis koosneb kõigist tarkvara elutsüklis sisalduvatest tegevustest, mis tegelevad tarkvaraprodukti ja seotud töötulemite hindamise planeerimise, ettevalmistamise ja läbiviimisega, et:

• selgitada välja, kas ja mil määral nad vastavad nõuetele;
• näidata nende sobivust eesmärgi saavutamiseks ning
• leida vigu.

Mida paremini sobib tehtud töö eesmärgi saavutamiseks ja vastab nõuetele, seda vähem peab tööd ümber tegema. Mida varem vead leitakse ja parandatakse, seda vähem tuleb tööd ümber teha. Aga sellest kõigest varsti lähemalt.

Kõige Olulisem Küsimus

Kõik ASA inimesed – kvaliteedikonsultandid, testijuhid, testijad – kuulevad nii müügitegevuses kui ka igapäevastes vestlustes sageli küsimust: „Kui palju peaks testimisele aega/raha kulutama?“ Et aga ainult suhtarv ütleb vähe, sõnastame küsimuse natuke laiemalt:

Kes, mida ja kui palju peaks testima, et oleks "piisav"?

Kirjutise järgnevad peatükid otsivadki antud küsimusele vastust, andes huvitatud lugejale vihjeid edasiseks lugemiseks. Kuna testimine ja tarkvaraarenduse kvaliteeditegevused üldisemalt on üsna lai teema, ei ole antud artikli skoobis võimalik pakkuda enamat põgusa sissejuhatuse andmisest.

Testimise tükeldamine

Ka kõige lihtsamate infosüsteemide puhul saab võimalikke testitavaid sisendite kombinatsioone välja mõelda lõpmatul hulgal, seega on täielik testimine võimatu. Selleks, et testimine erinevate rollide vahel mõistlikult ära jagada, tuleb tööd tükeldada. Seda saab teha nii horisontaalselt, erinevate kvaliteediatribuutide kaudu, kui ka vertikaalselt, vastavalt abstratktsioonitasemetele.  Seejuures võivad teostajad erineda nii testiliikide kui ka –tasemete lõikes. Kõlas keeruliselt? Ilmselt küll. Aga tegelikult ei ole testiliigid ja -tasemed välja mõeldud mitte selleks, et keerulisem oleks, vaid vastupidi -- lihtsam. Kuna tarkvara ise on sageli suur ja keeruline, on mõistlik arendusprotsess (ja selle kvaliteedikontroll) väiksemateks loogilisteks osadeks jagada.

Testiliigid

Testimist saab jagada liikideks vastavalt tarkvara kvaliteediatribuutidele. Viimaste kategooriaid on ISO/IEC 9126 järgi 6:

1. funktsionaalsus;
2. töökindlus;
3. kasutuskõlblikkus;
4. tõhusus;
5. hooldatavus ning
6. porditavus.

Arvatavasti kõige tuntum osa testimisest, üldjuhul ka kõige töömahukam – funktsionaalne testimine – hõlmab esimest kategooriat. Ülejäänud kategooriad võetakse üldjuhul ühise nimetaja alla "mittefunktsionaalsed nõuded" ning nendega seondub palju erinevaid (mittefunktsionaalseid) testiliike, muuhulgas:

• jõudlustestimine ja selle erijuhud (koormus- ja stressitestimine);
• robustsustestimine (testimine vigaste andmetega);
• kasutatavuse testimine;
• paigaldatavuse testimine;
• turvatestimine;
• jpm.

Lisaks eeltoodule saab testimist jagada liikidesse vastavalt sellele, kas programmikood käivitatakse või mitte. Esimesel puhul, mis on taaskord tuntum, on tegu dünaamilise testimisega. Staatiline testimine, mille käigus koodi ei käivitata, võimaldab testida sisuliselt kõike alates ärinõuetest ja prototüüpidest ning lõpetades paigaldus- ja kasutusjuhenditega.

Testitasemed

ISTQB selgitab arendusprotsessi läbi 4-tasemelise  V-mudeli, milles igale arendustasemele vastab testitase:

1. moodul- ehk ühiktestimine (unit testing) toimub arendatavale koodile kõige lähemal, testitakse loodavate tarkvaramoodulite (meetodid, klassid) toimivust vastu mooduli disainidokumentatsiooni;
2. integratsioonitestimises (integration testing) kontrollitakse moodulite omavahelist koostoimivust;
3. süsteemitestimise (system testing) tasemel kontrollitakse juba kogu süsteemi läbivate äriprotsesside toimivust süsteemidisaini vastu;
4. vastuvõtutestimise (acceptance testing) eesmärk on veenduda, et süsteem teeb seda, milleks ta loodud on.

Lähtuvalt erinevast abstraktsiooniastmest ja vaatenurgast on igal testitasemel erinevad vastutajad ning eesmärgid. Näiteks vastuvõtutestimise eesmärk ei tohiks kindlasti enam olla vigade leidmine ja parandamine, vaid pigem kindlustunde tekitamine lõppkasutajates. Samuti on testija mõiste igal testitasemel pisut erinev -- näiteks arendajad peaksid kindlasti osalema moodultestimises, seevastu äripool on absoluutselt asendamatu vastuvõtutestimise tasemel.

Lisaks eeltoodule ei tasu testimist unustada ka vahetult pärast programmikoodi ülekandmist toodangukeskkonda (nö. toodangusse vastuvõtu testimine).

Varajane testimine

„Mida varem, seda parem,“ ütleb rahvatarkus. Tõepoolest, see kehtib ka tarkvara testimise puhul, nagu näitas juba Barry Boehm oma 1976. aastal avaldatud artiklis „Software Engineering“ (1976). Täpsemalt, mida hiljem avastatakse tarkvaras viga, seda rohkem on selleks ajaks valesti tehtud tööd, mida ümber teha. Mida abstraktsem on töö, seda suurem on tõenäosus teha vigu. Seega tehakse tõenäolisemalt vigu nõuete kogumise faasis. Sellest omakorda järeldub, et varajane testimine, eelkõige staatiline testimine enne kodeerimise algust, võimaldab saavutada kõige suuremat kokkuhoidu.

Oponendid väidavad nüüd kindlasti, et eeltoodud põhimõte kehtib ainult klassi­kalise koskmudeli puhul ja mitte agiilsetes arendusmetoodikates. Tõsi, inkre­mentaal­sete-iteratiivsete mudelite puhul on inkremendid/iteratsioonid lühemad kui koskmudeli kogu arendustsükkel, seega tehakse dokumen­teeri­mi­sest töötava koodini jõudmiseks vähem tööd, mistõttu on potent­siaalsed kao­tu­sed, vähemalt ühe iteratsiooni piires, tõenäoliselt väiksemad. Ometi on ka siin varajane testi­mine oluline – kui näiteks esimeses iteratsioonis on tehtud funda­mentaalne viga, tuleb selle avastamisel mitu iteratsiooni hiljem ümber teha ka kõigi vahepealsete iteratsioonide tööd.

Testimise osakaal arendusprojektis

Aastal 1988 viidi läbi uuring, kus koostati kolme ettevõtte põhjal tarkvaraprojektide käekäigu simuleerimiseks mudel ning verifitseeriti mudelit seejärel neljanda, sõltumatu projekti raames. Tulemused olid üllatavad: mudel suutis neljanda projekti käekäiku ennustada erinevates mõõtepunktides üsna täpselt.

Uuringust selgus, et antud projektimeeskonna puhul olnuks ideaalne kulutada 15% projekti töötundidest testimis- ehk kvaliteeditegevustele. Antud tulemuse tõlgendamisel tuleb arvesse võtta kaht olulist aspekti. Esiteks vajab mudel sisendiks väga detailseid andmeid projektimeeskonna võimekusest (näiteks vigade esinemise sagedust), mistõttu ei ole see üldjuhul Eesti projektidesse kohaldatav. Teiseks oli vaadeldava projekti teostajaks NASA, mistõttu olid nii meeskonnaliikmete valikul kui ka protsessides väga ranged nõuded ja reeglid. Uuringu põhjal avaldatud artiklit võid lugeda siit.

Erinevad allikad annavad erinevaid soovitusi testimistegevuste osakaalule pro-jekti kogumahus. Näiteks suuremate ERP-lahenduste puhul väidetakse see olevat 40%, mastide otsas kasutatavate telekom-seadmete puhul aga vähemalt 60%. Viimane World Quality Report näitab trendi, et testimise osakaal kogu IT-eelarvest on tõusnud viimase paari aastaga 18% pealt 23% peale ning aastaks 2014 juba 26%-ni. 2017. aastaks ennustatakse, et testimine hõlmab keskmisest IT-eelarvest juba 29%.

Kokkuvõtvalt

Peab nentima, et alguses õhku paisatud küsimusele ühtset ja konkreetset vastust, mis igas projektis paika peaks, ei olegi.

Kes peaks testima? Kõik projekti osapooled, olenevalt vajalikest testiliikidest. Testija rollis võivad olla elukutselised testijad, aga kindlasti ka arendajad, analüütikud, lõppkasutajad, administraatorid, tellijad, tootejuhid jne.

Mida peaks testima? Lähtuma peaks kindlasti kvaliteediatribuutidest, mida antud projekti puhul olulisteks edu faktoriteks peetakse.

Kui palju peaks testima? See sõltub väga palju projekti iseloomust, kuid levinud praktika on hetkel 26% kogu ettevõtte IT-eelarvest kulutada testimistegevustele.

Viimases kahes punktis võiks ühtlasi lähtuda riskihinnangust – testimine kui meede riskide ennetamiseks ei ole kindlasti kasulik, kui sellele kulutada riski realiseerumisel saadavast potentsiaalsest kahjust rohkem.

Koolitus tehnilisest testimisest - mida peab iga testija ja arendaja teadma tarkvara siseelust?

Tarkvaraprojektides jooksevad testijad ja arendajadki tihti peaga vastu seina - testitakse küll ja justkui pühendunult ja päris korralikult, aga "tavaline" testimine ei leia kõiki olulisi vigu üles. Teine ebameeldiv võimalus on, et vead tulevad välja liiga hilja - vahetult enne live'i tähtaega või juba toodangukeskkonnas, põhjustades nii kõigile osapooltele sõnulseletamatuid kannatusi. Veel tahaksid uudishimulikud tarkvaraprofid saada ka objektiivset ülevaadet oma testimise põhjalikkusest - näiteks vastusena küsimustele "Kui suure osa koodist mu testid katavad?" või "Kas mu koodis on testimata osasid?"

Ka kliendid ei ole kitsid tarkvarale kõrgete nõuete esitamisega - tarkvara peab olema kiire, teenindama suure hulga paralleelseid kasutajaid, olema turvaline ja ilma probleemideta hallatav ning edasi arendatav, modulaarne ja filigraanne. Testijad aga teavad, et kui on nõue, tuleb ka testida, kas nõue on täidetud. Mõnikord aga... nagu hästi ei oska. Ja isegi kui oskaks, siis missuguseid tööriistu oleks kõige õigem kasutada? Mida automatiseerida ja mida mitte?

Tehnilise testija koolitus käsitleb testimise aspekte, mis on olulised nii tehnilisemate ülesannetega kokku puutuvale testijale (näiteks agiilses arendustiimis) kui ka arendajale.

Põhiliseks koolituse fookuseks on meetodid, tehnikad ja tööriistad, mida kasutada "tavapärasele" musta kasti käsitsitestimisele lisaks, et leida vigu lihtsamini (väiksema aja/rahakuluga) ning kontrollida kvaliteeti terviklikumalt kui vaid funktsionaalsusele rõhku pöörates. Et kullakarvalise kasutajaliidese all ei oleks liialt siiruviiruline kood. 

Väike ülevaade käsitletavatest teemadest on järgmine:

• koodi testikate (test coverage) - kuidas seda eesmärgistada, mõõta, kasvatada ja mitte üle pingutada,
• tarkvara sisekvaliteedi (hallatavus, hooldatavus) hindamine - koodistandardid ja staatiline analüüs,
• koodi käitumise uurimine - dünaamiline analüüs, profileerimine,
• tehnilist laadi testide planeerimine ja läbiviimine - jõudlustestid, turvatestid, tarkvara töökindluse tagamine,
• testide automatiseerimine - millal ja kuidas peaks ja ei tohiks, 
• tehnilise testija tööriistakast ja oma isikliku tööriistakasti komplekteerimine.

Koolitus, kuhu on oodatud nii testijad kui ka arendajad, toimub juba 24. - 26. augustil. Koolitajaks on Lloyd Roden (http://lloydrodenconsultancy.com), kes on nii AKA eelmistel koolitustel kui ka erinevatel testimise alastel konverentsidel saanud positiivse tagasiside kui praktilise kogemusega mänguline treener. Koolitusel igav ei hakka! 

Lisainfo ja registreerumine aadressil maili [at] asaquality.ee.
Registreerudes enne jaanipäeva on kolmepäevase koolituse hind 1500€+KM, edaspidi 1600€+KM (sisaldab toitlustust ja kõiki materjale, ei sisalda sertifikaadieksami tasu).

Koolitus põhineb ISTQB Certified Tester Advanced Level Technical Test Analyst õppekaval ning koolituse läbinutel on võimalik sooritada sertifikaadieksam (eksami sooritamise eelduseks on ISTQB CTFL sertifikaadi olemasolu, koolitusel saab osaleda ka ilma CTFL sertifikaadita). 

Kuidas mõõta turvalisust?

Mida vähem turvalisust, seda parem – niiviisi mõelda tundub esialgu veider, sest turvalisus on pigem positiivne ja ihaldatud omadus. Kui seda aga mõõta ei osata või ei taheta, siis jääb iga turvalisusega seonduv nõue, soov ja visioon sisutühjaks loosungiks. Seega turvalisuse reguleerimiseks on tarvis miskit mõõta. Mõõtmiseks on aga vaja kõigepealt see "miski" täpsemalt määratleda. Tunnetuslikult tähendab turvalisus igale inimesele midagi, aga selle täpsemal defineerimisel jäädakse sageli hätta. Täpsem turvalisuse mõiste seletus sõltub muidugi kontekstist, kuid suures plaanis on võimalik rääkida tunnetatavast turvalisusest ja mõõdetavast turvalisusest.

Turvatunne

Laiemas mõttes peetakse turvalisuse all tavaliselt silmas turvatunnet, mis on Maslow' vajaduste hierarhiat iseloomustavas püramiidimudelis hõivanud täiesti omaette taseme. Kui mõelda mõnele ekstreemsele olukorrale (näiteks aktiivne sõjategevus või looduskatastroof), siis on üpris loogiline, et turvatunde saavutamine on väga prioriteetsel kohal. Surmahirmus inimesed ei mõtle tavaliselt tunnustusele ega gastronoomilistele naudingutele. Pigem fokusseerib inimkeha kõik oma ressursid selleks, et jõuda ohutu(ma)sse seisundisse. Ohtude vältimiseks ja turvatunde tekitamiseks on inimkond loonud kõikvõimalikud seadmed ja konstruktsioonid (muu hulgas näiteks kindlused ja kindlustused, turvavööd ja tulemüürid, helkur- ja kuulivestid, abielu- ja töölepingud). Paraku on tunnetel põhinev turvalisus väga individuaalne, sest iga inimese julge olek on ümbritseva keskkonnaga omamoodi suhtes – mõnele on julgeks olemiseks tarvis soomusrüüd, teisele reisikindlustust.

Tarkvara puhul võib ju selle kasutaja käest küsida, kui turvaliseks ta antud rakendust või süsteemi peab, kuid pahatihti ei pruugi tunnetuslik hinnang tegelikkusele vastata (kuigi vahel on tarkvara looja vaatenurgast lõppkasutaja hea enesetunne palju tähtsam kui süsteemi tegelikud turvaomadused). Seetõttu on tark lisaks kasutajate tagasiside kogumisele paika panna mõõdikud, mis annaks turvalisuse tasemest objektiivsema ülevaate.

Mõõdetud turvalisus

Nõuete ja eesmärkide seadmisel on tähtis, et need oleksid mõõdetavad. Vastasel korral on väga keeruline tõestada, et soovitud tulemus on saavutatud. Turvalisuse mõõtmiseks võib kasutada mitmeid andmeid. Näiteks võib loendada 2014. aastal USAs raporteeritud tarkvara haavatavused ning järeldada, et kõige haavatavamad operatsioonisüsteemid olid Apple Mac OS X, Apple iOS ning Linux kernel. Võib ka üles lugeda anti-viirus-programmi poolt avastatud pahavara-ründed või kokku liita tavakasutajate tehniliste probleemidega seonduvad appikutsed. Igal juhul annavad täpselt mõõdetavad numbrid võimaluse joonestada erinevaid graafikuid ning aitavad turvalisuse tasemest veidi objektiivsemat ülevaadet saada.

Teatud mõõdikute komplektid on muutunud sedavõrd populaarseks, et nendest on välja kujunenud standardid. Kuigi ka standardites võivad mõned mõõdikud ja definitsioonid jääda ebatäpseks, on nendest siiski suur kasu turvalisuse taseme hindamisel. Erinevad standardid (näiteks rahvusvaheline ISO 27000 seeria, kodumaine ISKE, veebirakendustele keskendunud OWASP ASVS, jne) võimaldavad kontrollida, millisel määral järgib kontrollitav produkt (tarkvara, teenus, protsess) spetsialistide poolt kehtestatud nõudeid. Standardid aitavad piiritleda testimise skoopi ning samuti parendada erinevate osapoolte vahelist suhtlust (eeldusel, et kõik osapooled on tuttavad standardis määratletud mõistetega).

Igaühele oma standard

Samas ei tohiks mõõdikute usaldamisega liialdada. Mõõdikud näitavad ainult neid haavatavusi, mis leiti üles ja raporteeriti. Näiteks mustal turul on kõrges hinnas haavatavused, mis on veel ametlikult raporteerimata, ning pahavarad, mis oskavad viirusetõrjeprogrammidele nähtamatuks jääda. Lisaks peitub igas tarkvaras veel hulgaliselt täiesti avastamata haavatavusi. Seega on väga oluline aru saada, mis peitub mõõdetud numbrite taga. Tuleb meeles pidada, et kõik sõltub alati kontekstist ning lihtsalt kahe numbri võrdlusest ei piisa adekvaatsete otsuste tegemiseks. Pahatihti tehakse aga lihtsustatud mudelite põhjal laiahaardelisi järeldusi. Rohkem vigu ühes või teises programmis või rakenduses ei pruugi sugugi tähendada, et see oleks sellevõrra rohkem või vähem turvaline. Tänapäeva tarkvara on sedavõrd kompleksne, et on mõttetu väita, et üks brauser, tekstiredaktor või operatsioonisüsteem on turvalisem kui teine.

Kokkuvõttes võib tõdeda, et turvalisuse mõõtmine ei ole lihtne. Turvataseme hindamiseks on otstarbekas igale juhtumile individuaalselt läheneda, sest mõtestamata mõõdikute väär tõlgendamine võib viia kurbade tagajärgedeni. Üldine turvateadlikkus ja turvaküsimuste üle mõtisklemine tuleb aga igal juhul kasuks.

Sten Mäses
ASA Quality Services

Küber-identiteedivargus – süütu nali või tõsine kuritegu?

Minu esimesed kokkupuuted Internetiga olid vanuses 11-12, ehk varajases puberteedieas. Nägin jututubade-buumi, mis hiljem asendus foorumitega. Kümmekond aastat hiljem alustas praegu „tipus“ trooniv sotsiaalmeedia oma võidukäiku. Kui paarkümmend aastat tagasi peitus enamik neti-inimesi varjunime taha, siis viimaste aastate trend on pigem iseenda näo ja nime näitamine – Google pidas seda lausa nii iseenesestmõistetavaks, et nõudis rangelt iseendana esinemist. Kogu vaadeldava perioodi jooksul on üht probleemi aga üsna tõsisemaks hakatud pidama: identiteedivargused.

Interneti massidesse jõudmise algusaegadel, 90ndate aastate keskpaigas, olid reeglid üsna kaootilised. Kirjapandud reegleid otseselt ei olnudki, riiklikul tasandil seadustest rääkimata. Et kasutajaid oli vähe, toimisid keskkondade sisemised reeglid, ühest-kahest moderaatorist piisas. Kuna kasutajanime valimisel piiranguid polnud, valisid paljud end küberruumis esindama mõne iidoli nime. Ma ise kasutasin nimesid KarmoK (kooli arvutiklassi kasutajanimi), ChrisMan (vrd Batman või Spider-Man) ja 1998. aastast Garfield, millest pärast loomulikku lühenemisprotsessi sai „garf“. Ometi ei garanteerinud miski, et selle nime taga just mind leida võiks – ja ega keegi tõenäoliselt ei eeldanud ka. Internet oli huvitav mänguasi, mitte midagi tõsist. Huvitava võrdlusena võib siia kõrvale tuua Fidoneti, kus EW.* gruppidesse pidi igaüks rangelt oma kodanikunime alt kirjutama. Internetis valitses sellega võrreldes anarhia.

Keskkooli lõpu paiku (aastatel 2001-2003) sattusin tihedamalt ühte Inglise Vormel 1-teemalisse foorumisse. Kui suurem osa sealsest seltskonnast oli heatahtlik, leidus siiski ka juba paar „trolli“, kes ühe konkureeriva vormelifoorumi moderaatoriga tülli olid läinud ja arvete klaarimiseks tema nime ja pildiga „varikontosid“ vorpisid teha. Mustamiskampaania põhiline sisu oli noormehe väidetavalt massist erinev seksuaalne orientatsioon – nimelt fantaseeriti kokku kõiksugu orgiaid erinevate muude sihtmärkidega, kes kõik ühel või teisel põhjusel „trollidega“ pahuksisse olid sattunud. Üritasin „trollide“ mõtteviisist aru saamiseks nendega suhelda – sain vastuseks, et Internet on ju ainult mäng ja ega nad siis paha pärast. Julgesin väita, et tegelikult on iga ekraani taga siiski päris inimene ja sellisel laimul võivad nende jaoks ka reaalsed tagajärjed olla ning juba olidki lugudes uued tegelased – mina ja mu tolleaegne tüdruksõber.

Kui eelmises loos oli tegu „ainult“ emotsionaalse traumaga, siis 2009. aasta veebruaris avaldas Eesti Ekspress loo naisest, kes Soome kohtus oma eksmehe vastu võidu saavutas, kuna kohalikud võimud ei leidnud seadusandlusest ühtki asjassepuutuvat pügalat (Kärmas, 2009). Artikli ilmumise ajaks oli – küll napilt nädal varem – juba kooskõlastusringile jõudnud Karistusseadustiku muutmise seaduse eelnõu, millega seadusesse lisandus § 157² „Teise isiku identiteedi ebaseaduslik kasutamine“ (Riigikantselei, 2009). Probleemi hakati tunnetama seadusandja tasemel.

Ometi ei olnud sellest seadusemuudatusest kasu, kui välismaised kurjategijad möödunud aasta alguses mu ema Google’i konto enda valdusesse said ja kõigile kontaktidele petukirja laiali saatsid – justkui oleks konto omanik Bradfordis varguse ohvriks langenud ja vajaks nüüd kiiret rahalist abi (Karmo, 2014). Kuna tegu oli rahvusvahelise juhtumiga – ohver Eestis, teenusepakkuja Ameerikas, kurjategija ei-tea-kus – tunnistas politsei taaskord võimetust aidata. Umbes samal ajal oli sarnaseid juhtumeid Eestis teisigi. Seejuures olid identiteedivargad jälgede kustutamisel üsna põhjalikud: Google’i konto pandi üsna kiiresti pärast ülevõtmist kinni ning loodi sama kasutajanimega uus. Nii ei toiminud ka standardsed viisid konto taastamiseks.

Mis selles viimases juhtumis siis nii hullu oli? Mäletan omast kogemusest, kui palju aega ja energiat kulus uue Google’i konto tegemisele, kogu info vanalt kontolt uuele migreerimisele, arvete ja muu olulise info uuele aadressile tellimisele jms tegevustele. Seejuures oli minu vana konto minu käsutuses. Antud juhul tuligi emal eelkõige kõigi oluliste teenusepakkujatega lepingud ümber teha – arved uuele e-posti aadressile suunata. Lisaks – kuidas teavitada kõiki kontakte uuest aadressist, kui kontaktibaas „hävis“ koos kontoga? Paari päeva jooksul tuli murelikele petukirja saanud tuttavatele selgitada, et tegelikult ei ole midagi hullu juhtunud ja raha ei pea saatma – või siis lihtsalt noogutada järjekordse teavituse peale, et keegi saadab tema e-posti aadressilt kahtlaseid petukirju. Nutitelefon ja tahvelarvuti tuli uuele Google’i kontole ümber seadistada. Oleks vana konto krediitkaardiga seotud olnud, tulnuks ka krediitkaart sulgeda. Seda nimekirja võiks veel üsna pikalt jätkata. Niisiis – üheainsa konto kaotamisest tekkis omajagu ebamugavusi ja planeerimata lisatööd. Oleks võinud tekkida muidki sekeldusi, näiteks mõne vanale aadressile saadetud arve maksmata jätmise tõttu. Seejuures oli kurjategijate esmane eesmärk justnimelt identiteedivargus – saata usaldusväärse nime tagant sõpradele-tuttavatele rahasooviga kiri. Mõni nõrgema eesti keele oskusega ohver oleks vabalt võinudki õnge minna.

Igal juhul on identiteedivarguse näol tegu kuriteoga, mis väärib ennetamist ja karistamist. Ennetamise osas saavad palju ära teha kasutajad ise – kasutades mitmeastmelist kasutajatuvastust või vähemalt turvalisi paroole – aga eelkõige siiski teenusepakkujad ja tarkvaraarendajad, tehes turvalise isikutuvastuse võimalikult mugavaks. Sest kui kasutaja saab valida, eelistab ta esimese hooga alati mugavust turvalisusele. Suureks abiks on kindlasti ka muutuv suhtumine Internetti ja identiteedivargustesse – tundub, et enam ei peeta seda massiliselt süütuks mänguks. Õnneks.

Kristjan Karmo
ASA Quality Services

Algselt avaldatud 18.01.2015 Kristjani isiklikus blogis: Küber-identiteedivargus - süütu nali või tõsine kuritegu?

Uued koolitused testijatele: testimise südame saladused ja muudatustest rõõmu tundmine

Veebruaris on AKAs tulemas kaks uut koolitust testijatele. Õpime testimise südame saladusi ning muudatustest rõõmu tundmist.

Testimise südame terviseks!

Testianalüüs on testimise süda - kui see on kehvasti tehtud, lipsavad vead testijate silme eest läbi, hammustavad meid live'is ning põhjustavad kõigile osapooltele sõnulseletamatuid kannatusi. Esimene uutest koolitustest ongi testianalüütiku koolitus.
Kes on testianalüütik? Testianalüütiku rollis olev inimene üritab tarkvara ja IT süsteeme üle kavaldada: mõtleb välja, missugused stsenaariumid ja toimimised on võimalikud ja mis peaks juhtuma. Hea testianalüütik on ka hea nõuete-spetsifikatsioonide kritiseerija ja uuristaja - ta saab juba spetsifikatsioonist aru, et nii ei saa need asjad toimida või siis osa informatsiooni on jäänud kirja panemata. Niisiis on testianalüüs vajalik selleks, et testid leiaksid võimalikult palju vigu (kui neid on) ja seda juba spetsifikatsioonidest/analüüsidest/ülesandepüstitustest. Hea testianalüütik ei kohku ära isegi sel juhul, kui kirjapandud nõudeid justkui ei olegi või testimiseks on jäänud "tervelt" 60 minutit aega.

Teisest küljest võtab nii testide kirjutamine kui ka läbiviimine üksjagu aega, seega ei saa teste olla ülemäära palju. Tarkvarasüsteemid on enamasti aga keerukad ja võib tekkida tunne, et "põhjalikuks testimiseks" tuleks testida kõikvõimalikke andmete kombinatsioone ja infovoogusid. Testianalüütiku ülesanne on hoida kaalukausse tasakaalus - et testid leiaksid üles olulised vead, aga samas võtaksid mõistliku aja.

Koolitus läheb Sinu jaoks täie ette, kui tahad teada saada, kuidas:
- kasutada erinevaid meetodeid testide disainimiseks ja nende hulga optimeerimiseks,
- kasutada uurivat testimist, kus sobilik,
- üle kavaldada (lisaks tarkvarale) ka spetsifikatsioone,
- mitte üle pingutada testide dokumenteerimisega (aga ka mitte alahinnata selle väärtust),
- leida ja valida testidisaini abistavaid töövahendeid,
- koostada kasutusmugavuse, juurdepääsetavuse (accessibility) jt mittefunktsionaalsete nõuete teste.

Kuna koolitus järgib täpselt ISTQB Certified Tester Advanced Level Test Analyst programmi, siis sobib pärast koolitust ka vastavale sertifikaadieksamile minna.
Koolitus toimub 02. - 05. veebruaril Tallinnas. Koolituse maksumus on 2000€+KM (ei sisalda sertifikaadieksami tasu 250€, KM ei lisandu).

Kõik muutub... testimine samuti

Teine on agiilse testija koolitus. Milleks on vaja üldse säärast koolitust testijate jaoks välja mõelda? On ju olemas lihtsalt Scrumi metoodika koolitused ning põhjalikud Scrum Masteri ja Product Owneri koolitused. Need on loomulikult kasulikud ja vajalikud, aga nende otseseks sihtrühmaks ei ole siiski testija. Neis on palju kasulikku infot, kuid suurem rõhk on eelkõige juhtimisteemadel. Pahatihti ei peetagi vajalikuks testijat sellisele koolitusele saata - "projektijuht ju juhib ja korraldab kõik ära, küll ta saab testijatega ka hakkama". Noh, võib-olla tõesti, aga kas poleks kõigil tiimiliikmetel parem ja mugavam elu, kui kõik räägivad "sama keelt"?

Agiilse testija koolitusel tehaksegi esmalt selgeks põhitõed - mis see agiilne tarkvaraarendus üldse on ja kuidas seda süüa tuleb. See on aga ainult pool võitu, mistõttu tavalisest Scrumi metoodika koolitusest jääb õigele testijale natuke väheseks.
Võiks ju arvata, et testimine on ikka testimine, sõltumata arendusmetoodikast. Ühest küljest on see muidugi õige, sest näiteks vigade otsimine-raporteerimine toimub igal juhul. Teisest küljest aga on agiilsel testimisel väga iseloomulikud võimalused, mida oskuslikult ära kasutades ei ole ohtu, et testimine muutuks pudelikaelaks.

Muuhulgas saavad vastuse järgmised küsimused:
- Kuidas tervitada muudatusi (nt nõuetes) ilma ööund ja liigseid närvirakke kaotamata?
- Mind kutsuti retrole esindama testijate tundeid ja mõtteid. Appi, mida ma rääkima peaksin?
- Äripool ju testib kogu aeg ja võtab tarkvara vastu. Kas nüüd lastakse testijad lahti? Testija roll agiilses tarkvaraarenduses.
- Mis asi on kasutajalugu? Kas ma pean koostama ka testilood? Kus (mis vahendis) ma testilood koostama pean?
- Mida teha, kui keegi ütleb, et "meie dokumentatsioon on koodis"?
- Mul läheb testilugude koostamise peale liiga palju aega ja ma ei jõua testimiseni! APPI! Mida teha?
- "Mina" vs "meie" vs "teie": ma olen arendusmeeskonna täieõiguslik liige, me kõik võitleme ühe eesmärgi nimel, ent samas ma ju torpedeerin nende tööd - kuidas on lood testija sõltumatusega agiilses arendustiimis?
- Äri vahetu osalus agiilses arenduses on oluline. Kuidas nendega (näiteks leitud vigade teemal) suhelda, kui sõnad "integratsioon", "socket", "koormusjaotur" jm külvavad pigem segadust kui selgust. Kas ma pean raporteerima vigu topelt - ühed arendajatele ja teised ärile?
- Missugused oskused (sh pehmed oskused) on agiilses tarkvaraarenduses testijale olulised?

Agiilse testija koolitus vastab ISTQB Certified Tester Foundation Level Agile Extension õppekavale ja pärast koolitust on osalejal julge tunne minna vastavat sertifikaadieksamit sooritama.

Koolitus toimub 10. - 11. veebruaril Tallinnas. Koolituse maksumus 1200€+KM (ei sisalda sertifikaadieksami tasu 250€, KM ei lisandu).

Mis neid kahte koolitust ühendab?

Koolitaja Lloyd Roden (www.lloydrodenconsultancy.com), loomulikult. Lisaks koolitamisele on Lloyd ka tegevkonsultant tarkvara kvaliteedi alal ning populaarne esineja erinevatel konverentsidel alates Nordic Testing Daysist kuni EuroStarini. Mõned tema koolitusi iseloomustavad märksõnad on:
- näited oma konsultatsioonitöödest,
- kohe kasutusele võetavad "vidinad",
- hea tunnetus sellest, mis tüüpi "konksudega" küsimused on eksamil,
- mänguline stiil informatsiooni ajukäärdude vahele istutamiseks,
- lisaväärtuseks hea huumorimeel :)


Registreerimine ja küsimused on teretunud aadressil maili [at] asaquality.ee

Piraatlus kui tehnosotsiaalne sahkerdamine

Tehnosotsiaalne sahkerdamine

Infosüsteemide turvamisel rakendatakse erinevaid meetmeid, mis takistavad soovimatutel osapooltel konfidentsiaalsele teabele ligipääsu. Paraku jäetakse masinate kaitsmise käigus inimfaktor sageli hooletusse ning tehnosotsiaalne sahkerdamine põhjustab üha rohkem kriitilisi andmelekkeid. Nimelt on pahaaimamatut kasutajat petta tavaliselt lihtsam kui läbi tungida korporatsioonide arvutivõrkusid ümbritsevatest kaitsekihtidest.

Kasutajat saab manipuleerida mitmeti. Levinud on näiteks e-kirjad konto kustutamisest, ebaõnnestunud maksest või uskumatust sooduspakkumisest. Tähelepanu köitvale tekstile on lisatud pahavara sisaldav dokument või viide kuritahtlikule veebilehele, mis püüab ühel või teisel moel väärtuslikule infole ligipääsu saada. Näiteks saabus hiljaaegu ASA Quality Services e-postkasti kiri appie.com domeenilt, mis meelitab Apple ID infot uuendama. 

Õnneks püüavad mitmed organisatsioonid (sealhulgas ka linkide lühendamise teenuse pakkujad) pettusi ja pahavara levikut tõkestada ning hoiatavad kasutajaid potentsiaalsete ohtude eest. Targem on muidugi mitte kahtlastele linkidele klikkida või siis vähemalt natukenegi eelnevalt otsimootorite abil uurida, kas keegi veel on sarnaseid e-kirju saanud.

Piraatlus kui atraktiivne ründevektor

Päris lihtlabase petukirja õnge enam paljud tavakasutajad ei lähe ning spämm suunatakse üpris kiiresti prügikasti. Teistmoodi on aga lugu ebaseaduslikult levitatava tarkvaraga. Nimelt muugitakse enamik hirmkalleid tarkvarapakette kopeerimise eest kaitsvad mehhanismid suhteliselt kiiresti lahti ning seejärel jagatakse pildi- ja videotöötlusprogrammid, arvutimängud ja muu kommertstarkvara erinevate failivahetussüsteemide kaudu kõigile kasutamiseks.

Piraatlusest huvitatud arvutikasutaja on tavaliselt piraattarkvara ebaseaduslikkusest teadlik ning järgib teadlikult tundmatute häkkerite installimisjuhendeid. Üldjuhul on piraattarkvara paigaldamiseks tarvis käivitada privilegeeritud kasutaja õigustes kahjurvara, mis suudaks erinevatest tarkvara kasutamist piiravatest turvamehhanismidest läbi murda.



Juhul kui kahjurprogramm suudab piraattarkvara edukalt aidata, siis teeb tavakasutaja kõik endast oleneva, et see tema arvutis rahulikult edasi toimetada saaks. Suure tõenäosusega tegeleb aga kahjurvara lisaks piraattarkvara abistamisele veel mitmete kõrvaltegevustega - näiteks salvestab klahvivajutusi, saadab isiklikke faile kolmandatele osapooltele, kaevandab bitimünte.

Eriti võimekad on illegaalselt jagatavate operatsioonisüsteemidega kaasas olevad pahavarad, mis pääsevad nii sügavale süsteemi sisse, et viirusetõrjeprogrammidel on nende tegevust väga keeruline tuvastada, rääkimata eemaldamisest. 

Mida teha

Ei ole vast kellelegi uudiseks, et soovitatav oleks paigaldada (usaldusväärsest allikast) oma arvutisse viirusekaitse programm. Kummalisel kombel leidub veel üllatavalt palju inimesi, kes pole aru saanud, et kaitset vajavad mitte ainult laua- ja sülearvutid, vaid ka nutitelefonid ja muud taibukad seadmed (nt telerid ja külmikud).Viirusekaitse programmid ei ole küll imerohi, mis iga pahavara vastu aitaks, kuid sellegipoolest aitavad need tunduvalt vähendada arvuti või mõne muu nutiseadme nakatumise riski.

Lisaks viirusetõrjeprogrammi kasutamisele tasuks hoiduda tarkvarapiraatluse ahvatlustest või vähemalt arvestada sellega, et täienduseks juriidilistele probleemidele (nt rahatrahv, mainekaotus, tegutsemiskeeld jne) võib illegaalse tarkvara kasutamine endaga kaasa tuua ka hulgaliselt pahavara.

Õnneks aitab (lisaks erinevatele tõrjeprogrammidele) ahvatlevate tehnosotsiaalsete sahkerdajate pakkumistele vastu seista hoogne vaba tarkvara levik. Kuigi isegi tasuta jagatavat avatud lähtekoodiga tarkvara ei saa nimetada 100% turvaliseks (mitte ükski tarkvara pole 100% turvaline), eemaldab see vajaduse piraatluse järele. Praeguseks on suurt populaarsust kogunud vabavaralised veebilehtede sisuhaldussüsteemid (WordPress, Joomla, Drupal, MODx, Magento) ning tasuta alternatiive on võimalik leida praktiliselt kõigile kommertstarkvaradele. Ka erinevad Linux operatsioonisüsteemid muutuvad aina kasutajasõbralikumaks. Vaieldamatult on mitmes valdkonnas tasulised suletud lähtekoodiga programmid efektiivsemad, kuid üha rohkem suudavad vabavaralised lahendused kommertstarkvaraga edukalt võistelda.

Aina enam on ka suurkorporatsioonid hakanud kasutama ja toetama avatud lähtekoodiga lahendusi. Oma panuse piraatluse ja pahavara leviku tõkestamiseks saab anda aga igaüks, kes kasutab ainult legaalset tarkvara ja/või annetab oma raha või aega avatud lähtekoodiga projektidele (nt Vikipeedia artiklite täiustamine ei nõua üldjuhul erilist tehnilist ekspertiisi).


Sten Mäses
ASA Quality Services

7+1 põhjust, miks tasub koolitusele tulla

Aeg-ajalt tekib ilmselt paljudel küsimus, miks peaks minema koolitusele, kui tänapäeval on internet materjale täis ja raamatudki suhteliselt kättesaadavad. Milleks siis üldse koolitused, võib ju ise õppida? Järgnevalt panen kirja mõned eelised, mis on koolitusel osalemisel iseõppimise ees.

1. Koolitusel on võimalus küsida koolitajatelt (või ka kaasõppuritelt) nende kogemuste ja arvamuste kohta. On väga tõenäoline, et nii saad mõnegi hea mõtte või uue vaatenurga oma ammuste kitsaskohtade laiendamiseks. 
2. Kui koolitusel millestki aru ei saa, siis on võimalik kohe koolitaja ja kaasõppurite käest selgitusi nõuda.
3. Ennast raamatut lugema või harjutusi tegema motiveerida võib olla üsna vaevanõudev ning tihti tulevad "igapäevatööd" sellele vahele. Koolitusel on raske kõrvalistele ahvatlustele järele anda, ajakava soodustab õppimist. :) 
4. Kui keegi otsa lahti teha aitab, on märksa lihtsam vajadusel ise edasi uurida. 
5. Saad kuulda ja näha, missugused väljakutsed on teistel sama ala inimestel ning lood uusi kontakte. 
6. Sertifikaadikoolituste puhul on üldjuhul nii, et koolitaja teab üsna hästi, mida rõhutada ja millele tähelepanu pöörata, et eksami sooritamine muretult läheks. 
7. Hea koolitus motiveerib ja inspireerib, pakub võimalust korraks töökeskkonnast välja saada ja teha endale väike tööalane restart ;) 
8. ASA Akadeemia koolitusel saab lisaks teadmistele üldjuhul ka kooki. 

Meie ASA Akadeemias läheme nüüd kooki sööma ja siis koolitusele. Tahad ka? Koolituste kava saad vaadata aadressil https://www.asaquality.ee/akadeemia.

Muinasjutt Maailmaparandajate kuningriigist

Halloweeni puhul tahaksin rääkida teile ühe hirmuäratava muinasjutu.

Kord ennemuistsel ajal, väga-väga ammu, elasid Maailmaparandajate riigis Punamütsike ja võlur Automaag. Neid ja teisi Maailmaparandajaid juhtis Hea Vaim, võimas headuse eest võitleja, kel oli maailmaparandamises lausa must vöö.

Ükskord saatis Hea Vaim oma sõdalased Punamütsikese ja Automaagi naaberkuningriiki, et aidata sealse kuninganna Businessa muresid lahendada.

Kui nad lossi olid jõudnud, tundis Automaag kohe mustade jõudude juuresolekut, kuid ei lasknud ennast ära hirmutada ja nii astusid nad julgelt sisse. Väejuht tuli sooja naeratusega neid tervitama ning rääkis oma murest: Kuninganna Businessa tahab, et sõjakäigud oleksid kiiremad, kuid tema armeel ei ole jõudu nii kiiresti raudrüüsid toota ja samas veel kvaliteedi eest hoolitseda, treenida.

Esialgu pidid Punamütsike ja Automaag raudrüüde tootmise olukorraga tutvuma ja oma osavust Väejuhile tõestama. Küll aga ei pidanud Väejuht vajalikuks keskööl kolme tilka verd vahetada -- kõigepealt pidid  Maailmaparandajad niisama oma headust tõestama ja alles siis räägitavat lepingutest ja väärilisest tasust.

Punamütsike, sinisilmne nagu alati, üritas kohe kõike paremaks teha ning lobises muretult:
"Ärge muretsege! Automaag saab kõikega hakkama, võlub siin ja seal. Teeme raudrüüde proovimiseks spetsiaalsed raamid ja koostame sealt ka Businessa õukonnale meeldivad lipukesed ja ongi kuninganna õnnelik!" Ja nii leppisidki nad kokku, et Automaag jääb nädalaks lossi ja üritab Väejuhile tõestada, et on võimeline kohalike muredega hakkama saama. Punamütsike kirjeldas ära, kuidas raamid võiksid välja näha ja Automaag jäi võluma.

Kui Automaag oli üksi lossi jäänud, hakkasid kohe toimuma imelikud asjad. Ta tundis külma hingeõhku oma kuklas, kuid pead pöörates ei paistnud seal olevat mitte kedagi. Alles meeletu keskendumine tõi vaevu-vaevu nähtavale neiu, kes teda igal sammul jälgis.

Väejuht näitas nüüd oma tõelist palet: malbe naeratuse tagant paljastusid vampiiri kihvad. Dracula hakkas tasapisi Automaagi jõudu endale kiskuma ning teadmisi tema peast välja noppima. Juba teisel päeval kutsus ta võluri oma koopasse ning üritas teda enda poole meelitada, pakkudes vampiiride maailma võlu ning enda asetäitja kohta. Vapper Automaag aga üllatas teda julgelt „EI“ öeldes. Ta jooksis koopast välja ja võlus kodu poole ühe kiire appikutse.

Hea Vaim ja Punamütsike tulid viivitamatult appi. Dracula muidugi ei andnud nii lihtsalt alla, vaid üritas oma võimu näidata: "Kaduge koju! Või veel parem -- las Automaag jääb siia ja täidab mu käsku!"

Kuid kuna Hea Vaim ei olnud nõrgemate killast, püstitas ta kohe oma inimeste ümber kaitsevõrgu ning ütles, et nüüdsest tegutseme me siin kuningriigis alles pärast seda, kui mõlemad pooled on oma kavatsuste kinnituseks kolm tilka verd andnud. Dracula üritas veel kaitsest läbi murda, kuid kõik tema katsed olid nüüd jõuetud. Hea Vaim seisis kindlalt ja kaitses oma inimesi. Dracula andis alla ning ütles, et siis peab ta ise Businessaga hakkama saama, laseb oma trollidel õukondlastele raudrüüsid esitleda ja las nad siis ise otsivad sealt auke.

Nii pääsesid Maailmaparandajad lossist välja ning suundusid tagasi kodukuningriiki.

Teel koju küsis Punamütsike murelikult: "Aga mis saab nüüd kuninganna Businessast?" Hea Vaim vastas talle lahkelt: "Ära muretse, küll aeg kõik paika paneb ja varsti näeb temagi Dracula tõelist palet. Ma millegipärast arvan, et me saame juba õige pea Businessat päästma minna..."

Nagu iga muinasjutt, lõppes ka see õnnelikult. Head inimesed jõudsid kodukuningriiki ning jätkasid maailma paremaks muutmist. Kuid nagu igal muinasjutul, on ka siin oma moraal - sa võid oma naabreid küll usaldada, aga hoia neil silma peal. Eriti Halloweeninädalal. Ning nagu kordab väsimatult ka (tänasesse päeva üsna sobiva nimega) ClientsFromHell.com: ära tee (tasuta) tööd ilma lepinguta! ;)

Siiralt Teie,

Punamütsike

Sertifitseeritud võrguliiklus - miks ja kuidas

Enamik inimesi on huvitatud sellest, et nende personaalne info püsiks Internetis ringi liikudes vajalikul määral konfidentsiaalsena. Samas leidub väheseid, kes julgevad krüptograafiaga seonduvasse spetsiifikasse põhjalikumalt süveneda. SSL, SHA, RSA, HTTPS, PFS ja teiste salapäraste tähelühendite sügavam sisu võib matemaatikavõõrale tavakasutajale esmapilgul hirmutav näida, kuid krüpteerimisega seonduvate riskide teadvustamine aitab hoiduda oma isiklike andmete lekitamisest soovimatutele osapooltele.

HTTP

Internet (nii suure kui ka väikese algustähega) on arvutitevaheline võrgustik, kus liiklust reguleeritakse erinevate protokollidega, mis sätestavad efektiivseks suhtluseks vajalikud reeglid. Kõige tuntum internetiliiklusega seonduv protokoll on tõenäoliselt HTTP ehk hüperteksti edastuse protokoll (HyperText Transfer Protocol), mis võimaldab brauseri abil erinevaid veebilehti vaadata. Kuigi kaasaegsed veebilehitsejad on hakanud peitma http:// lühendit veebilehtede aadressi alguses, on HTTP endiselt veebistruktuuri üks peamiseid alustalasid.

HTTP on oma olemuselt üsna lihtsakoeline. Kasutaja saadab veebiserverile lihtteksti kujul päringu ning saab lihtteksti kujul ka oma päringule vastuse. Lihtteksti kujul liikuvast infost on aga pealtkuulajal võimalik vähese vaevaga üles leida salasõnad, paroolid ja muu huvi pakkuv. 

Teatud lehtede puhul ei pruugi muidugi toimingute nähtavus kolmandatele osapooltele olla eriti kriitiline. Näiteks uudiseportaali küsitlusele vastamine või artikli kommenteerimine ei ole üldjuhul tegevused, millega seonduva info lekkimisel kolmandatele osapooltele erakordset hirmu peaks tekitama. Kasutajanime ja parooli saatmine HTTP protokolli kasutades on aga üsnagi hoolimatu tegevus ning tuleks eeldada, et pärast sellist olukorda teab sisselogimiseks vajalikke andmeid ka keegi teine. Õnneks on turvariskide vähendamiseks leiutatud HTTPS (HTTP Secure ehk turvaline hüperteksti edastuse protokoll).

HTTPS

Veebilehitsemise turvalisuse tõstmiseks loodi HTTPS protokoll, mis sisuliselt tähendab HTTP kasutamist krüpteeritud kanali kaudu. Infokanali krüpteerimine muudab võrguliikluse kõrvalseisja jaoks arusaamatuks sümbolijadaks. Nii on konfidentsiaalne info ideaalis nähtav ainult valitud osapooltele.

Turbeprotokollile vastava krüpteeritud ühenduse algatamiseks on tarvis võtmeid, mille abil edaspidine infovahetus arusaadavaks muuta. Lisaks võtmetele on tarvis veenduda, et veebiserveril on usaldusväärne turvasertifikaat. Turvasertifikaate võib teha ise (nt MakeCert või OpenSSL abil), aga usaldatavuse suurendamiseks on ka võimalik hankida sertifikaat mõnelt sertifitseerimiskeskuselt. Rahvusvaheliselt on tuntumad sertifitseerijad näiteks GoDaddy, VeriSign, DigiCert, GeoTrust, Symantec ja Comodo.

Turvasertifikaadi võltsimisel on küberkurjategijatel võimalik usaldusväärse organisatsiooni identiteet kaaperdada ning esitleda end kellegi teisena. Seetõttu on äärmiselt oluline veenduda turvasertifikaadi autentsuses. Autentsuse kontrollimiseks kasutatakse räsialgoritme, mis oskavad suvalise suurusega faili või sõnumi põhjal koostada ühesuunalise krüpteerimise teel püsipikkusega bitijada ehk räsi. Tugeva räsialgoritmi puhul peab olema võimalikult keeruline räsi põhjal algset faili või sõnumit konstrueerida. Samuti peab olema võimalikult keeruline luua kaht erinevat faili, millele vastaks identne räsiväärtus.

Tehnika areng ning arvutusvõimsuse pidev kasv toob endaga kaasa aga vajaduse räsialgoritme aina tugevamaks teha. Näiteks 1990-ndatel laialdaselt kasutusel olnud räsialgoritm MD5 on võimalik tänapäeval tavalise koduarvutiga vähem kui sekundiga lahti murda ehk tekitada sarnase räsiga fail. 2012 aastal avastatud kurivara Flame oskas MD5 nõrkust ära kasutades lausa näidata end Microsofti poolt toodetud tarkvarana.

Praegusel ajal on räsifunktsioone küll mitmeid (BLAKE, GOST, RIPEMD jne), kuid kõige tuntumaks võib pidada NSA loodud SHA funktsioonide perekonda. Esimesed SHA põlvkonnad (SHA-0 ja SHA-1) on praeguseks juba aegunud, kuid paraku on SHA-1 endiselt laialdaselt levinud – muuhulgas ka turvasertifikaatide autentsuse kontrollimisel. Microsoft on küll teatanud, et SHA-1 algoritmi ei tohiks enam kasutada 2016. aasta algusest ja Google Chrome hakkab astmeliselt SHA-1 kasutamist piirama juba 2014. novembrist, kuid ka väiksematel organisatsioonidel tasuks enda valduses asuvad veebilehtede serverid kriitilise pilguga üle vaadata. Abiks on siinkohal näiteks veebilehed https://shaaaaaaaaaaaaa.com ja https://www.ssllabs.com/ssltest.

SSL Labs annab hea ülevaate kasutusel olevatest turvameetmetest.

Kui server on kliendile turvasertifikaadi saatnud ning kliendi arvuti on räsialgoritmide kaasabil sertifikaadi autentsuses veendunud, siis on aeg infokanal serveri ja kliendi vahel krüpteerida. Selleks peaks HTTPS ühendus kasutama transpordikihi turbeprotokolli (Transport Layer Security ehk lühidalt TLS), mille praegusel hetkel kõige uuem versioon on TLS 1.2. Paraku kasutatakse mitmel pool veel TLS eelkäijat SSL (turvasoklikiht ehk Secure Sockets Layer) tehnoloogiat, mis on nüüdseks lahti häkitud ehk haavatav. Seega tasuks serverite haldajatel kasutusel oleva turbeprotokolli ajakohasus üle kontrollida ning uuendada ka erinevates hangetes, lepingutes ja muudes dokumentides sisalduvaid nõudeid, kus sageli kasutatakse SSL ühendust turvalise ühendusega võrdväärselt.

Valdav enamus Eesti veebipoodidest paraku HTTPS ühendust veel ei kasuta ja kuigi pangalingi kaudu sooritatud maksed on õnneks suhteliselt turvalised, siis ees- ja perenimi, aadress, telefoni number ja muu kontaktinfo saadetakse üldjuhul krüpteerimata kujul veebipoe andmebaasi. Eriti tõsist riski võib põhjustada turvamata veebilehel registreerumine salasõnaga, mis on juba kasutusel ka mujal. Kui näiteks e-poe klient registreerub kasutajaks salasõnaga "5up3r$ala;jane?!" ning märgib enda kontaktinfosse e-posti aadressi, siis on igati ootuspärane, et keegi proovib varsti sama salasõna kasutades e-maili kontole ligi pääseda. Seega tasuks hoolikalt uurida, kas veebilehe aadressi ees on https:// tähistamaks krüpteeritud ühendust. Kui vastav märgistus puudub, siis edastatakse andmeid üle turvamata HTTP ühenduse ning kõik saadetav info on kõrvalseisjatele vabalt nähtav.

Kokkuvõtteks

Ülevaatlikult veelkord olulisemad näpunäited:

1.  Kontrolli, kas veebileht, kuhu konfidentsiaalset infot sisestad, kasutab turvalist HTTPS protokolli. Aadressiriba alguses kuvatakse siis üldjuhul https:// ning tabalukk, millele klikkides näeb rohkem infot turvasertifikaadi kohta. 
   
   
   
   Juhul, kui HTTPS ühendust ei kasutata, arvesta sellega, et vormidesse sisestatud info võib suure tõenäosusega lekkida kolmandatele osapooltele.
2. Kontrolli, et veebilehte serveeriv süsteem kasutaks turvalise ühenduse loomisel ajakohaseid tehnoloogiaid - https://www.ssllabs.com/ssltest.

   

   SSL Labs hinnang ühele Eesti tuntud veebipoele.

   Kui test annab tulemuseks halva hinde, siis teavita kindlasti veebilehe haldajat - nii aitad kaasa üldise turvateadlikuse kasvule ning teed küberkurjategijate elu raskemaks.
3. Ära kasuta sama salasõna mitmes kohas! Võimalusel kasuta mitmeastmelist autentimist, tugevaid salasõnu ning paroolihaldureid.

Sten Mäses
ASA Quality Services

IKT Aastakonverents 2014: Kuhu edasi, Eesti IT?

14. oktoobril toimus ITuudiste  korraldamisel Tallinnas IKT Aastakonverents 2014. Konverents oli tänapäevasele IT-tiimile suunatud väga huvitava ja aktuaalse kavaga. Esinejad valgustasid uusi väljakutseid ja võimalusi ning jagasid oma kogemusi IT kiiresti muutuvas maailmas tegutsemisel. Loomulikult vaatasime seda kõike testija perspektiivist. Ning meie – igaveste maailmaparandajate ja skeptikute – arvates sai kogu konverentsi ühe väljapaistvama etendusega maha Andres Kütt. Ettekandes (mille lühikokkuvõtet saab lugeda ITuudiste portaalist: http://ituudised.ee/article/2014/10/20/andres-kutt-ei-ole-eestit-ilma-e-riigita) jagas ta oma mõtteid Eesti IT-arenduse tulevikuvõimalustest, olles kantud presidendi kõnest: „Mis toond on meid siia, see enam edasi ei vii“.

Alustades Eesti IT ajaloost, märkis Kütt, et kuigi meie riigis on olemas vähemalt üks diplomeeritud pungiuurija, ei ole kedagi, kes oleks teaduslikult lähenenud Eesti IT ajaloole. Nii nagu iga Startup, alustasid ka Eestis IT arenduste loomisega inimesed, kes olid ühtse ideega ning huviga ühendatud. Startup-i õnnestumisele aitas kaasa inimeste motivatsioon, kogukonnatunne ja võime kohandada ning kaasa minna muudatustega, mida IT maailmas tuleb ette igal sekundil. Probleeme lahendati koos ja dünaamiliselt. Toona polnud muret, mille vastu näts ja teip ei aitaks: nt murdunud labaga printeri ventilaatoril murti üle ühe laba ära, et ventilaator tasakaalu saada. Töötas!

Nüüd aga järgmine etapp. Lihtsad probleemid on praeguseks lahendatud ja põlve otsas tehtud häkkidega enam edasi ei saa minna. Peame olema suutlikud suuremate muudatustega toime tulema.
Sedasama näeme ka meie, testijad. Õnneks või kahjuks on testimine tihtipeale esindatud projektides ainult UAT (User Acceptance Test / kasutaja vastuvõtutest) näol, mil äripool eneselegi teadmata sooritab tarkvara vastu võttes nii funktsionaalseid kui ka mittefunktsionaalseid teste.

Kahjuks, sest sellisel juhul kujuneb UAT palju kallimaks, kui algselt planeeritud. Või kui üldse mõistlik oleks. Arendusprojekti elutsükli varasemates faasides leitud vea parandamine maksab UAT-s leitud vea parandamisest kordades vähem. Vastuvõtufaasis seab massiline vigade leidmine aga otseselt kogu projekti õnnestumise kahtluse alla.

Õnneks aga võrreldes projektidega, kus testimist ei ole üldse planeeritud või selleni lihtsalt ei jõuta – tarnitakse korralikult testimata arendustöö ning testivad juba reaalsed kasutajad toodangukeskkonnas. Kvaliteedi saavutamine ei tohiks aga olla õnnemäng!

Kütt pakkus välja lahendusi, mis oleksid kindlasti tulemuslikud ka testimise valdkonnas:

• Inimestesse investeerimine
Inimestesse investeerimine on tõesti jätkusuutlikkuse üks eeldus. Võiksime ju lihtsalt palgata hordide viisi testimisspetsialiste või lausa kvaliteedijuhi, kes ainuisikuliselt vastutaks kvaliteedi eest, kuid selline lähenemine ei vii kaugele.

Kvaliteet ei tähenda perfektsionismi, see ei ole standard või protseduur. Kvaliteet ei ole ka mõõdik või asja karakteristik. Kuid ta näitab, mil määral üks või teine karakteristik seatud nõuetele vastab. Iga toode, teenus, protsess ja otsus võib olla kas vastuvõetav või vastuvõetamatu. Seega on kvaliteet tegelikult peidus kõiges, mida organisatsioon teeb ning igaüks peab oma töös pöörama tähelepanu kvaliteedile. Kvaliteedi tõstmiseks tuleb niisiis inimesi harida – alustades tellijatest, et nad juba ülesandepüstitusse kirjutataks sisse nõuded testimisele ja kvaliteedile.

• Juhtidesse investeerimine
Suur osa Eesti IT-inimesi on harjunud kvaliteetse juhtimisega ja leiavad suure tõenäosusega parema pakkumise, kui juhtimiskvaliteet logiseb. Juhtkonna mure on võimaldada spetsialistidel efektiivselt ning tulemuslikult tööd teha, hoolitsedes motivatsiooni eest. Kui testimine on alati projekti lõpu poole ja selleks ei jää kunagi piisavalt aega; kui leitud vead loovad ainult negatiivseid emotsioone, siis paratamatult kipub testija töötegemise motivatsioon nullile lähenema.

Sõnum projektijuhtidele: planeerides projekti testimistegevusi, ärge paigutage neid mitte lõpupoole ühe suure kastina „testimine“, vaid jagage see (nagu iga teinegi mahukam töö) väiksematesse osadesse, hinnates ja analüüsides iga testimistaset koostöös testijuhtide ja testijatega võimalikult vara.

• Protsessidesse investeerimine
Nagu ütles Kütt, on elementaarsed hügieenifaktorid tihti täitmata. Tarkvara tellides ei mainita paljudel juhtudel testimist endiselt poole sõnagagi, nagu ka 10a tagasi. Küti sõnul on  küpsusaste meie riigis paraku veel madal: esimese sammuna oleks vaja testimisega natukenegi tegelema hakata. Ja miks on meil veel aastal 2014 arendusettevõtteid, kelle arvates ei peagi arendusfaasis mitte midagi üles kirjutama?

Kõik need küsimused on otseselt seotud kvaliteedi tagamisega. Protsesside parendamisel tuleks aga arvestada muudatuste omaksvõtmise kiirusega. Probleemide lahendamisel kasutada prioriteete ning pidevalt teha tagasivaateid, olukorda uuesti analüüsides. Iga protsessimuudatus toob kaasa muutusi kogu keskkonnas, millega peab kindlasti arvestama. Sedasama mainis ka Kütt, et meie E-riigi jätkusuutlikus (mis on suuresti erasektori kätes), ei ole enam mugavusküsimus, vaid riikliku julgeoleku alustala. Kiirete ja lihtsate häkkidega aga tõepoolest julgeolekut kindlustada ei saa. Julgeme väita, et kvaliteedist ongi just hetkel puudu. Ka sellele on vaja samamoodi süsteemselt panustada.
Kahjuks ei aita ükski kvaliteedijuhtimise ega protsesside parendamise metoodika hoiduda juhtide valedest otsustest, kuid mõõdikute algusest peale paikapanemine ning parendusprotsessi mõju pidev mõõtmine aitavad aru saada, mis suunas organisatsioon liigub ning suunda kontrolli all hoida.
Kvaliteeti – nagu enamikke IT-arendustöö tulemusi – on võimalik saavutada üsna kergesti, kuid jätkusuutlikkus nõuab suuremaid pingutusi.

Testimist ja kvaliteeti hõlmav kogukond on samas arenguetapis, mis kogu eesti riigi IT-sektor. Vajatakse suunamuutust, et akadeemilise haridusega inimestest ka kasu oleks – lahendatavate ülesannete keerukuse kasvades läheb akadeemiline lähenemine järjest olulisemaks.

Nii nagu Andres Kütt, leiame ka meie, et suunamuutuseks oleme praegu soodsamas seisus kui kunagi varem ning seda muutust on vaja, sest sellest sõltub meie tulevik.

Olesja Savtšenko
Kristjan Karmo

Eesti Haigekassa ja bugipalavik

Septemberi keskel toimus järjekordne BugFever. Testisime kokku 22 inimesega ühe päeva jooksul Eesti Haigekassa uut veebilehte. Testijateks olid peamiselt Haigekassa oma töötajad, kel avanes võimalus harjutada testimist ja ühtlasi tutvuda uue välisveebi ülesehituse ja väljanägemisega. ASA poolt osales testimistalgutel ka 2 professionaalset testijat.

Haigekassa avalike suhete osakonna kommunikatsiooni peaspetsialist Kaili Kupits võttis üritusest saadud kasu kokku järgmiste sõnadega: "Sain vajaliku tagasiside, meie töötajad said testimiseks vajalikud oskused ja saadud teadmus pole kaugeltki mitte ühekordne, ka edaspidi saan koolituselt saadud oskusi ja materjale kasutada. Olen kogu üritusega rahul."

Rahule jäid ka osalejad, kes tõid muu hulgas välja, et ürituse teoreetiline osa oli igati sobilik tavakasutajale – materjalid olid lihtsad ja arusaadavad. Üks osaleja lisas omalt poolt: "Kuna tegemist oli otsast lõpuni igapäevase tööga seotud tegevusega, siis olen ülimalt positiivselt üllatunud."

BugFeveri eestvedaja Maili Markvardt kirjeldab üritust nii: "BugFeveri korraldamisel peame silmas asjaolu, et üritusest saaksid maksimaalselt kasu nii testjad kui ka testitava tarkvara pakkuja. Osalejad said kindlasti esmased teadmised ja oskused testimiseks – näiteks teadmise, et testija peabki kõike kahtluse alla seadma – ja oskuse vigu korrektselt raporteerida. Vähem oluline pole ka see, et osalejad, kes ei tegele igapäevaselt testimise ega tarkvaraarendusega, saaksid testimisest positiivse kogemuse.

Testitava tarkvara pakkujale annab BugFeveri käigus saadav tagasiside ülevaate, missuguseid emotsioone tarkvara potentsiaalsele kliendile pakub ja kui mugav on seda kasutada. Välja tuleb ka suuremaid ja väiksemaid funktsionaalseid vigu.

Tahan siiski rõhutada, et BugFever ei asenda süstemaatilist testimist arenduse käigus, sest ürituse läbiviimiseks peab olema tarkvara juba stabiilne ning viimistletud, vastasel juhul on osalejate negatiivne meelestatus tarkvara suhtes kindlustatud."

BugFever on ASA Quality Services OÜ poolt ellu kutsutud ja ASA Akadeemia abiga läbi viidav interaktiivne testimisüritus, mille eesmärgiks on läbi praktika tutvustada tarkvara kvaliteedi tagamisega seotud tegevusi ja erialasid ning levitada teadmust nende kohta.

Lisainfo BugFeveri kohta: https://www.asaquality.ee/bugfever/

Kontakt:
Maili Markvardt
+372 56 603 627
maili.markvardt@asaquality.ee

Kuidas tagada veebirakenduse sõbralikkust?

Veebirakenduse kasutajasõbralikkusest rääkides tulevad esimesena pähe lihtne ja selge visuaalne kujundus, mis võimaldab kasutajal intuitiivselt ning suure kasuteguriga oma eesmärke saavutada. Eesmärkideks võivad olla näiteks majandusaasta aruannete koostamine, müügitöö koordineerimine, e-poest meelepärase eseme tellimine või siis lihtsalt tuttavate piltide kommenteerimine ja meelelahutuslike videoklippide vaatamine. Tõhusam eesmärkide saavutamine loob sageli väärtusliku konkurentsieelise, seetõttu haaratakse uutest tehnoloogilistest võimalustest õhinaga kinni. Selge sisuesitluse ja intuitiivse funktsionaalsuse arendamisel kipub aga pahatihti tähelepanuta jääma rakenduse jõudlust määravate protsesside optimeerimine. Järgnevalt vaatleme, kuidas saab jõudlustestimine aidata kasutajasõbraliku rakenduse loomisel.

Kärsitu kiirustamine

Esimene jõudlusega seostuv parameeter, mis kasutajakogemust oluliselt mõjutab, on kiirus ehk aeg, mille jooksul rakendus suudab vajalikku infot kuvada. Kui 1990ndatel olid veebis surfajad harjunud kannatlikult enam kui 30 sekundit liivakellakujulist kursorit põrnitsema, siis nüüdseks on olukord drastiliselt muutunud. Arvutikasutajate kannatus katkeb üha kiiremini ning sageli otsustatakse juba paarisekundilise esmamulje põhjal, kas lehele jääda või mujale liikuda. Iga lisasekund lehe laadimisel võib seega rahulolevate kasutajate hulka märkimisväärselt vähendada.

Jõudlustestimine aitab saada ülevaadet sellest, kui kiiresti mingi veebirakenduse osa päringutele reageerib ning võimaldab kindlaks määrata rakenduse kõige aeglasemad kohad. Näiteks võivad optimeerimata andmebaasipäringud või virtuaalserveri vale konfiguratsioon põhjustada tarbetuid viivitusi, mida saaks vähese vaevaga parandada. Jõudlustestimine juhib sellistele pudelikaeladele tähelepanu ning aitab veenduda selles, et süsteemi kasutajatele kuvatakse vajalik info võimalikult kiiresti.

Skaleeritavus

Üksikute kasutajatega süsteemi testimisel ei pruugi välja tulla rakenduse võimekus hakkama saada suurema hulga päringutega. Ebaotstarbekalt süsteemi ressursse kulutav algoritm võib vähese arvu kasutajatega näiliselt edukalt toime tulla, kuid päringute arvu kasvades ootamatult kinni joosta. Jõudlustest aitab hinnata, mitut kasutajat suudab süsteem üheaegselt piisava kiirusega teenindada. Nii on võimalik kasutajatele süsteemi suure koormuse korral juba ennetavalt kuvada vabandav teade. Kasutajate piirarvu täitumisel uutele sisenejatele viisaka selgitusega sissepääsu takistamine on märksa kasutajasõbralikum lahendus kui ootamatud tõrked või talumatud viivitused.

Süsteemi skaleeritavuse planeerimisel tasub arvestada ka sellega, et süsteeme kasutatakse tavaliselt ebaregulaarselt ning keskmine lehekülastuste arv ei pruugi kasutajate käitumist piisavalt täpselt kirjeldada. Turunduskampaaniad, tähtajad, riigipühad ja mitmed muud faktorid võivad tavapärase süsteemi koormuse lühikese aja jooksul mitmekordistada. Näiteks kipuvad ülikoolide õppeinfosüsteemid olema kõige aeglasemad vahetult enne ainetele registreerumise tähtaegu ning piletimüügisüsteemid ägavad ülekoormuse käes, kui algab müük ülipopulaarsele üritusele.

Ebaregulaarsete kasutusmustrite tundmine võimaldab jõudlustesti tulemusi paremini mõtestada ning vastavalt ka rakenduse arendustegevusi planeerida. Lisaks mineviku mõtestamisele tasub mõelda ka tulevikuplaanidele. Ettevõtte laienemine ja uute tehnoloogiate (näiteks aina taibukamad nutiseadmed, täiendatud reaalsus, semantiline veeb, Big Data) kasutusele võtmine mõjutab märgatavalt kogu infovahetusprotsesside mahtu. Jõudlustestimine aitab kontrollida rakenduse skaleeritavust, et arendatav tarkvaralahendus oleks võimalikult jätkusuutlik.

Kasutusvoog

Kõikvõimalike testide üks peamine eesmärk on lõpptulemusena tagada rakenduse kasutajale võimalikult sujuv kasutusvoog (flow). Aeglane lehe laadimine, keerukatest menüüdest vajaliku funktsionaalsuse otsimine ja muud tarbetult aeganõudvad tegevused takistavad kõik sujuvat voogu rakenduse alguspunktist soovitud tulemini. Eriti häirivalt mõjuvad ootamatud tõrked ning tavakasutajale arusaamatud veateated (näiteks "0x361F ERRORIPSECIKE_SRVACQFAIL" või "Uncaught exception: Java.lang.Error at sun.plugin.util.PluginSysUtil $SysExecutionThread.run").

Ideaalses süsteemis toimiks kõik loogiliselt, kiiresti ning vigadeta, kuid reaalses elus on tarkvaravead praktiliselt vältimatud. Taibukamad süsteemid oskavad aga veasituatsioonidest väärikalt välja tulla. Nimelt ei kuvata komplitseeritud veakirjeldusi ega lakoonilisi 404-laadseid koode, vaid konstruktiivne ja viisakas teade, mis aitab võimalikult valutult kasutusvoogu jätkata. Mitmed lehed lähevad veel sammu kaugemale ning katsuvad potentsiaalse frustratsiooni vähendamiseks veateated lõbusaks teha.

Ükskõik kui meisterlikult loodud veateated ei aita aga pikemaajaliste ja sagedaste jõudlusprobleemide korral. Ka jõudlustestimine iseenesest veel jõudlusprobleeme ei lahenda, vaid annab ainult infot, mille põhjal edasi tegutseda. Näiteks kui on teada, et enam kui 10 paralleelse ühenduse korral on rakenduse töö häiritud, aga planeeritud kasutajate hulk päevas on ligikaudu 4000 inimest, siis on mõistlik kiiremas korras võtta kasutusele ettevaatusabinõud hiireviha tekitavate olukordade ennetamiseks. Jõudlushinnangu puudumisel võib julgelt kasutajate kannatusega katsetamine vägagi kulukalt lõppeda.

Edukalt läbitud jõudlustest ei tähenda, et ollakse kaitstud 400-gigabitiste rünnete eest. Küll aga on rakenduse haldajal märksa täpsem ülevaade vastava tarkvara võimekusest ning rohkem infot efektiivsete arendusotsuste tegemiseks, mis aitavad tagada rakenduse võimalikult kasutajasõbralikku käitumist.

Sten Mäses
ASA Quality Services