reede, 19. detsember 2014

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

esmaspäev, 3. november 2014

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.

reede, 31. oktoober 2014

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

neljapäev, 23. oktoober 2014

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

    kolmapäev, 22. oktoober 2014

    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

    reede, 3. oktoober 2014

    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

    teisipäev, 23. september 2014

    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

    esmaspäev, 18. august 2014

    Kust tuleb tolm ja kuhu kaob raha?

    Ei ole mingi uudis, et esemed kipuvad ajapikku tolmuga kattuma, kui nad jäetakse kasutult pööningule või keldrisse vedelema. Sama võib öelda ka oskuste, mõtete ja inimeste kohta, kui neile pidevalt uusi väljakutseid ei esita. Lõpuks kipub minema sedasi, et vana asi vajab kallist restaureerimist ja oma oskustega ajale jalgujäänud inimene kaotab sponsorid.

    Täpselt sama probleem vaevab ka ettevõtteid, sest turg nõuab pidevalt uudseid ja innovaatilisi lahendusi. Kui ASA Quality Services 10 aastat tagasi alustas, siis olid testimine, testija ja kvaliteedikonsultant uued osalised Eesti turul ning ega väga kellelgi polnud aimu, mis tegelastega on tegu. Õnneks on hea tõdeda, et ASA on endiselt turul ning testimine, testija ja QA (Quality Assurance) ei ole enam uudissõnad. Kasutan juhust tänada siinkohal ASA meeskonda, kes pole selle aja jooksul tolmukorraga kattunud ning on näinud igapäevaselt enda vajalikkuse tõestamisega kurja vaeva.

    Samamoodi nagu maailm, on pidevas muutumises ka QA turg ja trendid. Selles postituses üritangi võimalikult lihtsalt välja tuua suurimad väljakutsed ja soovitused, mis ootavad tarkvaraarendust ja QA turgu ees aastatel 2014-2015.

    1. QA organisatsioonid hakkavad endi funktsioone ärivajadustele vastavalt tsentraliseerima ja parendama, et saavutada suurem efektiivsus ja kuluoptimaalsus

    See tähendab üldjoontes seda, et kvaliteediinimesed ja testijad on läbimas nii oma käitumises kui ka mõttelaadis suurt muutust suurema küpsusastme poole ja hakkavad järjest enam toimetama ettevõtteüleselt aga mitte projektipõhiselt nagu seni. Eelkõige tähendab see seda, et arendajad peavad hakkama projekti kontekstis arvestama QA poolt lauale toodud skoobiväliste ärivajadustega, ning kõiki või enamus majasiseseid arendusi hallatakse ühtse metoodika järgi.

    Taolisi QA kehi nimetatakse ühise nimetajana TCOE-deks (Test Center of Excellence) ja selleks võivad olla nii majasisesed, kui ka -välised kvaliteediüksused, kes on võimelised pakkuma erinevaid kvaliteediteenuseid kogu tarkvara elutsükli vältel.

    Senine levinud mudel, kus testijaid hangiti projektipõhiselt meeskonnale täienduseks, on drastiliselt kadumas, kuna selle efektiivsus ja kuluoptimaalsus on suhtliselt madal. Kui 2013. aastal oli 6% ettevõtetel kas majasisene TCOE või täitis seda rolli väline partner, siis sel aastal on vastav näitaja tõusnud 19%-le ning täiendaval 13% ettevõtetel on plaanis taoline keha kahe aasta jooksul kas tekitada või hankida.

    2. IT eelarvest investeeritakse üha rohkem QA operatsioonidesse.

    10 aastat tagasi tegin ma jämeda ja julge rehkenduse, kui palju maksab kvaliteedimõõtme toomine tarkvaraarendusse. Ma sain tulemuseks, et suurusjärku 20-25% ja ma nimetasin seda kirvemeetodiks, et anda kliendile aimu, kui palju ASA teenus maksab. Ma oleksin võinud muigugi küsida ka kliendilt, mitu viga tal süsteemis on ja ma oleksin osanud kohe öelda palju nende leidmine maksma läheb. Siiski otsustasin minna raskemat teed.

    Aastal 2012 oli maailmas selle investeeringu keskmine suurus 18% IT eelarvest. 2013 aastal 23% ja 2015 aastaks prognoositakse 28%. Selline kasv ületab klassikalist 2-3%-aastas-keskmiselt reeglit märgatavalt ning on osaliselt põhjendatav asjaoluga, et ettevõtted vajavad kõrgema kvaliteediga tarkvarasid, mis on käideldavad, turvalised ja mugavad kasutada.
    Samas väärib märkimist, et need trendid näitavad investeeringute suuremat suunamist uute tehnoloogiate kasutuselevõtu suunal ja vähenemist olemasolevate süsteemide käitamiseks vajalike testimiste läbiviimiseks. Olemasolevate süsteemide haldamiseks kasutatakse järjest rohkem testimise automatiseerimist, mis muudab selle kuluefektiivsemaks.

    3. Klassikaline arusaam testimise kaasamisest arendusse ja testimise üldine toetumine reaktiivsetele meetrikatele muudab testimise vajalikkuse õigustamise ja küpsusastme kasvatamise keeruliseks

    Klassikaliselt ollakse harjunud testimist kaasama siis, kui on mida testida ehk arendus on jõudnud mingisuguse töötava koodini. See hetk on aga liiga hilja, et testimine saaks ennetada vigu ja olla proaktiivne. Peaaegu pooled ettevõtted (45%) kaasavad testimise kas arenduse jooksul või peale seda, mis on liiga hilja, et mõjutada süsteemi kvaliteeti laiemalt kui vigade otsimine ja parandamine. Eriti problemaatilised on selles vaates lühikeste arendusiteratsioonidega arendused.

    Samuti on siinkohal suur roll ka kasutatavatel meetrikatel. Väga suur enamus ettevõtteid keskendub endiselt testimise operatiivmõõdikutele nagu leitud vigade arv (73%) , testiloo hind (55%) jne. Kuigi need meetrikad on testimise jaoks olulised, siis võiksid testijad pakkuda enamat, et näidata oma seotust ja lisandväärtuse loomist ärioperatsioonidele. Näiteks mõõta QA panust toote või teenusega turuletuleku aja lühendamisse (time-to-market) ennetades vigu ja probleeme enne, kui need jõutakse koodi kirjutada.

    4. Nutiseadmetel testimise (mobiiltestimine) trend on järsul tõusul ja muutumas võtmedistsipliiniks, kuid turul puuduvad vastavad metoodikad, oskused ja keskkonnad.

    Sel aastal näitas mobiiltestimine ülisuurt kasvu fookusega nii funktsionaalsuse, jõudluse kui ka turvatestimisele. 55% ettevõtetest tegeleb aktiivselt oma rakenduste mobiiltestimisega võrreldes 31%-ga eelmisel aastal. Nutiseadmetel jooksvate rakenduste peamine fookus on endiselt jõudlusel ja funktsionaalsusel (59%), kuid suure hüppe on teinud turvatestimise osakaal (56% võrreldes eelmise aasta 18%-ga). See näitab, et nutiseadmed on saamas äriettevõtete jaoks olulisteks meediumiteks nende ja klientide vahel tavaliste arvutite kõrval ning uute süsteemide loomisel tuleb tõsiselt kaaluda nutiseadmete võimalusi ja piiranguid. Tõenäoliselt saab mobiilturvalisus lähima kahe aasta jooksul fookusalaks nr 1.

    Kui varemalt pidasid mobiiltestimisega tegelevad ettevõtted suurimaks probleemiks vastavate tööriistade puudust, siis tänaseks on murekohad liikunud sobilike metoodikate (34% pealt 56%-le), oskuste (29%-lt 48%-le) ja keskkondade puudusele. Mobiiltestimise spetsiifika peitub sadade erinevate seadmete ja operatsioonisüsteemide variatsioonide testimises, mille hulgas on ka tootmisest maasolevad mudelid aga mida endiselt maailmas on palju kasutusel. See muutus, mis liigutas murekoha tööriistadelt keskkondade ja metoodikate puudusele näitab, et mobiiltestimine on ettevõtete jaoks saamas oma eripärade ja nõuetega QA eriditsipliiniks.

    5. Pilve kasutuselevõtt ja pilvepõhine testimine on pidurdunud, sest ettevõtted maadlevad turva ja jõudlusprobleemidega.

    Kuigi üldiselt on ettevõtete suhtumine pilve positiivne, siis paljude jaoks on probleemiks pilves endas toimuv segadus ja vastutuse hajusus. Kui ettevõte käitleb sensitiivseid andmeid, siis täna ei paku pilveteenuse pakkuja sulle garantiid, et need andmed on teiste pilvekasutajate eest kindlalt kaitstud või ei kasutata näteks selle sama pilve võimsust sinu ründamiseks. Kui need probleemid saavad lahendatud, siis on oodata suuremat pilve kolimise lainet, mis toob endaga kaasa ka pilvepõhise testimise kasvu ning testkeskkondade pilve viimise.

    6. Investeerimine testkeskkondadesse on samuti pidurdunud, kuna turul pole saada vastavat kompetentsi

    Testkeskkonnad ja sobivad tööriistad on kvaliteedi tagamisel üliolulise tähtsusega, mida kinnitavad ka QA organisatsioonide investeeringute jaotised. Testkeskkondadesse investeeritakse kuni 40% QA eelarvest ja 28% tööriistadesse. Enamik ettevõtteid kasutavad püsivat testkeskkonda (63%) ja 23% kasutavad rakendusepõhist ajutist keskkonda.

    Sellegipoolest kurdavad 67% ettevõtteid, et neil pole õigeid testimisvahendeid ja keskkondi hoolimata investeeringutest ja 53% on hädas mitme testkeskkonna ja riistvara haldamisega ning 37% ettevõtteil on probleem piisava kiirusega testkeskkondade ülesehitamisega.

    Seetõttu on need ettevõtted hakanud nägema Test Environment Management-i (TEM) kui uut testimisoskust ja rutiini. Ilma testkeskkondade loomise spetsiaalse planeerimiseta ja rakendamiseta võib testimeeskond raisata väärtuslikku aega ja raha ning kaotada tsentraliseerimisest tekkiva efekti.

    Samuti on ettevõtetel probleeme piisava katvuse ja loogilise ülesehitusega testandmete genereerimisega, mis kuulub ka TEM kompetentsidesse.

    7. Agiilne arendus on moes, kuid põhjustab testimisele suuri probleeme. Turul ei leidu sobivaid metoodikaid ja oskusi.

    83% ettevõtteist tunnistavad, et nad kasutavad agiilseid arendusmetoodikaid kas kõigis või osades enda projektides. Põhjuseks tõenäoliselt agiilse arenduse lubadus tarnida kiiresti takvara, mis on muutuvatele turuvajadustele kiirelt kohanduv. Samas 64% ettevõtetest tunnevad puudust jätkusuutlikest testimismeetoditest agiilsete arenduste testimises. 56% ettevõtetel on probleemid testide automatiseerimisega ja 49% ei suuda agiilse testimise fookust täpselt paika seada.

    Need näitajad näitavad selgelt probleemi, mis täna valitseb agiilses arenduses. Nimelt keskenduvad agiilsed arendusmeeskonnad liigselt koodi kiirele väljalaskmisele, kuid selleks, et agiilne arendus oleks edukas, peaks meeskond igas iteratsioonis keskenduma koodi asemel ärivajadustele ja -väärtustele, mida TCOE-d saavad pidevalt valideerida ja verifitseerida. Kindlasti tekib lähiajal sellele problemile lahendus ning agiilsed arendused ei põhjusta tellijatele selles mahus enam peavalu.

    Kokkuvõtteks

    Selle lühikokkuvõtte aluseks on World Quality Report 2013-2014. Raportit lugedes võrdlesin ma tahes-tahtmata trende täna ASAs toimuvaga ning oma heameeleks avastasin, et me oleme juba hulk aega tundnud sama, mida raport välja tõi ja oleme pikemat aega endid sisemiselt kõvasti arendanud. Oleme saavutanud TCOE võimekuse lüües ettevõtetes kaasa arendusstrateegiate ja kvaliteedipoliitika loomisest kuni reaalse tarkvara juurdumiseni ning oleme võimelised ka agiilseid meeskondi suunama õigele ja ärile olulisele teele. Juurde on tekkinud turvatestimise kompetents ja testkeskkondade ning testandmete loomise ja haldamise võimekus ning mis peamine - meil silm särab ja me ei karda sirge seljaga tulevikule vastu marssida. Tolmu meie pealt ei leia!

    Sander Vallaots
    ASA Quality Services
    juhatuse liige

    reede, 11. juuli 2014

    Tule testijuhtimise meistriklassi, mis toimub 4.-8. augustil. Viimased kohad!

    4. -8. augustil toimub Lloyd Rodeni juhtimisel ISTQB Advanced Level Test Manager koolitus, mida võib ülesannete keerukuse ja intensiivsuse tõttu pidada tõeliseks testijuhtimise meistriklassiks. Koolitusele on veel mõned vabad kohad.

    Mida õpid testijuhtimise meistriklassis (peale valmisoleku saada ISTQB CTAL TM sertifikaat)?

    Koolitus toimub ISTQB Advanced Level õppeprogrammi järgi, mis tähendab, et sügavuti ning koos praktiliste harjutustega läbitakse järgnevad teemad:
    -    Testiprotsessi ülesehitus, erinevad projektid, minimaalne vajalik testimispanus;
    -    Testiprotsessi juhtimine – riskipõhine ja väärtuspõhine lähenemine, testimise mahtude hindamine, testimine väljast (outsoucing), standardne testidokumentatsioon ja meetrikate kasutamine;
    -    Läbivaatused ehk staatiline testimine kui kvaliteedi tagamise osa
    -    Vigade haldamine, vigadehalduse protsess, meetrikad, vigade korrektne kirjeldamine
    -    Testimisprotsesside parenadmise TPI, CMMi, CTP, STEP mudelid
    -    Testivahendid ja testide automatiseerimine, tööriistade valik, meetrikad tööriistade hindamiseks
    -    Inimeseoskused  tarkvaraprojektis, meeskonna motivatsioon, kommunikatsioon, värbamine ja meeskonna loomine ning sobitamine organisatsioonis.


    Koolitajaks on Lloyd Roden (Inglismaa, http://lloydrodenconsultancy.com/)
    Lloyd Rodeni kogemus tarkvaraarenduses arendaja, testianalüütiku ja testijuhina on üle kolmekümne aasta. Aastatel 1999-2011 töötas ta konsultandina, aastal 2011 asutas isikliku koolitus- ning konsultatsiooniettevõtte. Lloyd on tuntud esineja mitmetel testimisalastel konverentsidel nagu EuroStar, StarEast, StarWest, samuti on ta esinenud meie kodumaisel Nordic Testing Days konverentsil.
    Lloyd peab kõigil oma koolitustel oluliseks sisu praktilisust ja rakendatavust igapäevatöös: koolitus annab osalejale konkreetsed näpunäited, juhised, mallid, mida pärast koolitust tööle naastes kohe kasutama asuda.

    Niisiis, kui soovid saada tõeliselt kõva trenni professionaalse testijuhtimise treeneri käe all, siis tule koolitusele:
    Aeg ja koht: 4.- 8. August 2014 Tallinnas, Lõõtsa 8 II korrus.
    Hind: 2500€+KM, alates kahest osalejast ühest ettevõttest -10%. Hinnas sisaldub toitlustus ja vajalikud materjalid eksamiks valmistumiseks, kuid ei sisaldu sertifikaadieksami tasu. Tegemist on intensiivse ja personaalse koolitusega, seetõttu on kohtade arv piiratud.


    Koolituse eesmärk ja sihtrühm: koolitus aitab süvendada teadmisi testijuhtimisest, mistõttu on vajalik praktiline kokkupuude testimise ja/või testijuhtimisega. Koolitus annab vajalikud teadmised ja oskused ISTQB CTAL TM sertifikadieksami sooritamiseks. Koolitus toimub ISTQB õppeprogrammi järgi, mida on võimalik vaadata siit: http://www.istqb.org/downloads/finish/46/96.html .  Sertifikaadieksami sooritamine eeldab ISTQB CTFL (või samaväärse) sertifikaadi olemasolu, kuid koolitusel pole keelatud osaleda ilma seda omamata.

    Sertifikaadieksami sooritamise võimalus: 11. augustil, hind 250€+KM. Edaspidi korraldab eksameid Eesti Testijate Liit (www.testijateliit.ee).
     

    ISTQB Advanced Level Test Manageri koolitusele järgnevad 2015. aastal ka ISTQB Advanced Level Test Analyst (4 päeva) ja Technical Test Analyst (3 päeva) koolitused, samuti ISTQB Foundation  Level Certified Tester Agile Tester Add-on koolitus.

    neljapäev, 3. juuli 2014

    Hasartselt testimisest

    1. jaanuarist 2016 jõustub hasartmänguseaduse muudatus, mis peaks võimaldama senisest suuremat kontrolli (potentsiaalsete) hasartmängusõltlaste ahvatlustest eemalhoidmiseks. Puhtalt professionaalsest hasardist proovisin seadusemuudatuse osadeks lahti võtta ning hinnata, mida mõned muudetud paragrahvid ja lõiked IT süsteemide ja testimise mõistes kaasa toovad.


    Hetkel on võimalik isikutel, kes soovivad end hasartmängude (õnnemängude) mängimisest eemal hoida, lasta end lisada õnnemängu mängimise piirangutega isikute nimekirja (OMPI nimekiri). Selleks on füüsilisel isikul kolm võimalust:
    • esitada avaldus EMTA teeninduspunktis, 
    • õnnemängu korraldaja juures või 
    • teha seda ise läbi eesti.ee portaali. 
    Kõik esitatud avaldused jõuavad piirangutena EMTA hallatavasse OMPI andmekogusse, kust õnnemängukorraldajatel on kohustuslik teostada kontroll. Mängima tulnud isiku kuulumist OMPI nimekirja võimalik kontrollida kas käsitsi portaali eesti.ee kaudu või oma infosüsteemi integreerituna OMPI x-tee liidese kaudu. Kui mängupiirang kehtib, siis ei tohi korraldaja isikut mängima lubada.

    Hasartmäng, õnnemäng, loterii

    Teeme esmalt lühidalt ja lihtsustatult selgeks mõisted (aluseks on hasartmänguseaduse paragrahvid 3 ja 4). Hasartmäng on üldmõiste, mis väljendab mistahes mängu, mille puhul mängus osaleja teeb rahas mõõdetava panuse ning ta võib võita rahas mõõdetava auhinna või hüve, kuid ei pruugi. Võit ja kaotus sõltuvad juhuslikkusest või mõnest muust mängijale eelnevalt mitte teadaolevast asjaolust.

    Õnnemäng on läbi vahendaja või mehaanilise/elektroonilise automaadi abil mängitavad hasartmäng, mille tulemus oleneb juhusest (mänguautomaadid, mängulauad). Loterii on  hasartmäng, mille tulemus sõltub juhusest ja selgub mänguvälja avamisel (kiirloterii) või loosimisel (klassikaline loterii). Toto on lihtsustatult öeldes auhinnaline ennustusvõistlus - võit oleneb sündmuse toimumisest, toimumata jäämisest või toimumise viisist ning mängijal ega mängu korraldajal ei tohi olla mingit võimalust seda mõjutada. Toto alla kuuluvad näiteks spordiennustusvõistlused. Hasartmänge võib korraldada nii otse kui ka telekommunikatsioonivahendite abil. Viimasel juhul nimetatakse neid kaughasartmängudeks.

    Väike muudatus paberil ... ?
    1. jaanuaril 2016 jõustuv seadusemuudatus toob endaga kaasa kaks suuremat sisulist muudatust, mis puudutavad infosüsteeme. Teised planeeritavad muudatused on pigem protsessilised ja infosüsteeme oluliselt ei mõjuta.

    Esiteks kohaldatakse 1. jaanuarist piiranguid ka klassikalise loterii ja toto mängijatele, seejuures saab isik valida, missugust liiki mängudele ligipääsu ta piirata soovib. Hetkel kehtiv seadus võimaldab piiranguid seada vaid õnnemängule.

    Teiseks muudatuseks on asjaolu, et piirang ei lõpe enam isiku poolt määratud tähtaja möödudes automaatselt, vaid selleks on vaja esitada avaldus. Piirangu tähtaeg määrab vaid selle, missuguse aja möödudes saab isik esitada avalduse piirangu lõpetamiseks. Hetkel saab piirangut määrata tähtajaga alates kuuest lõpetades 36 kuuga. Tähtaja möödumisel piirang lõpeb automaatselt.

    ... Suur muudatus infosüsteemis! 

    Inimesena, kellele testimine on elustiil, mõtlesin kohe, missugune võiks olla selle seadusemuudatuse mõju infosüsteemidele ja kui ulatuslikke teste oleks tarvilik läbi viia, et ka pärast 1. jaanuari 2016 olla seadusega kooskõlas.
    Niisiis jõudsin järgnevatele järeldustele seadusemuudatuse mõju ning vajalike testide osas:
    • Ulatuslikud muudatused tuleb teha Õnnemängu mängimise piiranguga isikute nimekirja hoidvas andmekogus - arvestades seadusemuudatuse sisulist mahtu, peaks muutuma juba ka andmekogu nimi. Hetkel hoiab andmekogu tõesti vaid õnnemängude piiranguid, 2016. aastast peab aga vastu võtma ka klassikalise loterii ja toto piiranguid.
    • Täielikult muutub piirangu lõppemise loogika - kui varem lõppes piirang tähtaja möödumisel automaatselt, siis tulevikus on selle jaoks tarvilik isiku vastavasisuline avaldus. Avaldust on võimalik esitada alles pärast piirangu tähtaja möödumist. Tegemist on täiesti uut tüüpi avaldusega. Muudatus mõjutab nii andmekogu pidajat EMTAt kui ka hasartmängukorraldajat. EMTA peab koguma ja töötlema mõlemat liiki avaldusi (piirangu kehtestamine ja lõpetamine) ning hasartmängukorraldaja vastavalt sellele infole juurdepääsu lubama või piirama.
    • Avaldusi piirangute määramiseks saab esitada EMTA teeninduspunktis ja ka eesti.ee portaalis, mis tähendab, et need avalduse esitamise kanalid vajavad eelnimetatud muudatusi ja testimist.
    • Muudatuste mõjul muutub andmete koosseis ja formaat andmekogus. See eeldab hetkel olemasolevate andmete konverteerimist (migreerimist) uuele kujule ja kontrollimist, et ka nende puhul hakkaks uus loogika toimima. Olenevalt migreeritavate andmete mahust võib probleemiks osutuda ka migreerimisprotsessi kiirus (suure andmehulga korral).
    • Andmemahud andmekogus ja päringute sagedus EMTA andmekogu vastu tõenäoliselt kasvavad, kuna paljudel hasartmängukorraldajatel, kellel varem ei olnud kohustust piiranguid kontrollida, see kohustus tekib. Andmekogule on kehtestatud ka turvalisuse nõuded ja muudatused ei tohi seada ohtu nende täitmist.
    • Muudatused loto/toto teenusepakkuja poolel olenevad olulisel määral teenusepakkuja infosüsteemide hetkeolukorrast - kas ja kuidas toimub isikutuvastus ja piirangute küsimine OMPI nimekirjast, kas seda varem üldse realiseeriti ja kas see toimub automaatselt või käsitsi eesti.ee portaali kaudu. Kuna siiani kehtis kohustus piiranguid arvestada vaid õnnemängu korraldajatele, siis loterii- ja totokorraldajad peavad tõenäoliselt piirangute kontrolli oma IT süsteemidesse juurde arendama.
    Need on suuremad muudatused, mis kohe nö "peale vaadates" näha on. Detailsete arendusvajaduste skoobi väljaselgitamine peab toimuma siiski iga infosüsteemi jaoks lähtuvalt selle spetsiifikast ja hetkeolukorrast.

    "Aga me ei muuda ju midagi?!"

    Lisaks muudatuste mõju hindamisele ja muudatuste korrektsuse testimisele tahaksin südamele panna, et isegi kui teie infosüsteem on juba varasemast ajast integreeritud teise osapoolega (antud juhul loto/toto teenusepakkuja või EMTA), siis muudatused teise poole süsteemides võivad "kogu ahela" (äri- või toimisprotsessi) katki teha ning pärast teise osapoole muudatuste live'i minemist lahendus enam ei tööta. Üldjuhul oleks viisakas küll teisi osapooli muudatustest teavitada, kuid ka kommunikatsioonis tuleb ette lünki ja seetõttu targad ja ettenägelikud usaldavad, aga kontrollivad.

    Seetõttu on oluline ka juhul, kui oma süsteeme ei muudeta, aga muutuvad ahela teised lülid, kogu ahela toimimine läbi proovida. Alati on võimalus, et muudatus oleks olnud vajalik ja möödapääsmatu, kuid keegi arendusmeeskonnast ei tabanud mõju ära.

    Testimise napoleoni kook

    Testid tuleks planeerida kihiliselt, napoleoni koogi põhimõttel: esmalt realiseerida moodulid või alamsüsteemid ja testida need eraldiseisvalt. Moodultestimise vastutus on programmeerijal, alamsüsteemi funktsionaalsust ja kõiki "ülalpool asuvaid" teste võiks teha aga professionaalne testija, kes nõutud funktsionaalsuse elementaarosadeni proovile paneb.

    Integratsioonide väljaarendamisel on mõistlik esialgu kontrollida oma liidese toimimine vastu mocki (staatilist komponenti) ning kohe pärast integreeritava "teise otsa" valmimist ka andmevahetuse toimimist kahe süsteemi vahel.

    Kindlasti ei tohi unustada ka lõppkasutajate (EMTA ametnike ja hasartmängukorraldaja töötajate) poolset testimist, mis täidab suures osas ka koolituse eesmärki. Lõplikult valmis saadud IT arenduse vastuvõtuteste, millesse võib asutusesisese kompetentsi puudumisel kaasata sõltumatu kolmanda osapoole.

    Veel rõhutan registripidaja ja teenusepakkujate koostööle - suurte muudatuste puhul on oluline hoida üksteist arendustööde progressiga kursis ja koostada ühine testiplaan, millal eelnimetatud teste võimalik ja vajalik teha on.


    Kokkuvõtlikult soovitan: alustage mõjuanalüüsist ja selgitage välja, mida tuleb olemasolevas süsteemis muuta ja mida lisada, ehk esmalt pöörake tähelepanu nõuetele. Nõuete väljaselgitamisel tekkinud vigadeks aega ei ole, sest seadusest tulenev tähtaeg on ees.
    Kohe seejärel planeerige vajalikud testid, hinnake nende mahte ja veenduge, et selleks sobilik ressurss on olemas. Lähtuge reaalsusest - testida on alati vaja rohkem kui üks kord arenduse lõpus, lõppkasutajatel napib vähegi suurema projekti puhul selleks nii oskusi kui aega. Integratsiooniprojektide testimisel, eriti kui hõlmatud on erinevad organisatsioonid, sisaldab testimine muuhulgas ka suhteliselt suurt koordineerimistööd - kes, millal, mida testima peab ning missugused takistused tuleb kõrvaldada - see on testijuhi ülesanne. Testimine ei paranda küll ühtegi viga, aga vähemalt on vigade kohta informatsioon õigeaegselt olemas, ja see suurendab ka nende õigeaegse parandamise tõenäosust.

    PS.  Ka tarkvaraarendus ja testimine on hasarti tekitavad tegevused - kas mõni kriitiline viga lipsab töökeskkonda või mitte? ASA Quality Services realiseeris selle lauamänguna, mida kõik huvilised võivad ise mängida ja vaadata, kas juhus on nende poolt või ei. Tegemist ei ole hasartmänguga, v.a juhul kui soovite kasutada mängus rahalisi panuseid :) Mängu saab alla laadida siit: https://www.asaquality.ee/attachments/Game_of_ASA.pdf

    Sarnaste mõtteharjutustega saad kindlasti end proovile panna ka augusti alguses toimuvas Lloyd Rodeni testijuhtimise meistriklassis.

    Kutse koolitusele
    Koolitus: ISTQB Certified Tester Advanced Level Test Manager (ISTQB CTAL TM)
    Aeg ja koht: 4.- 8. august 2014 Tallinnas, klassiruum täpsustub
    Hind: 2500€+KM, alates kahest osalejast ühest ettevõttest -10%

    Registeerumine ja lisainfo: Maili Markvardt, maili [at] asaquality.ee , anna oma huvist märku enne suurt puhkusteaega, st hiljemalt 11.juuliks!
    Koolitus toimub inglise keeles. Hinnas sisalduvad toitlustus ja vajalikud materjalid eksamiks valmistumiseks, kuid ei sisaldu sertifikaadieksami tasu. Kohtade arv on piiratud (10 osalejat), kuna tegemist on intensiivse ja personaalse koolitusega.

    Koolituse eesmärk ja sihtrühm: koolitus aitab süvendada teadmisi testijuhtimisest, mistõttu on vajalik praktiline kokkupuude testimise ja/või testijuhtimisega. Koolitus annab vajalikud teadmised ja oskused ISTQB CTAL TM sertifikaadieksami sooritamiseks. Koolitus toimub ISTQB õppeprogrammi järgi, mida on võimalik vaadata siit: http://www.istqb.org/downloads/finish/46/96.html . Sertifikaadieksami sooritamine eeldab ISTQB CTFL (või samaväärse) sertifikaadi olemasolu, kuid koolitusel pole keelatud osaleda ilma seda omamata.

    Koolitaja: Lloyd Roden (Inglismaa, http://lloydrodenconsultancy.com/)

    Sertifikaadieksami sooritamise võimalus: 11. augustil, hind 250€+KM. Edaspidi korraldab eksameid Eesti Testijate Liit (www.testijateliit.ee).

    ISTQB Advanced Level Test Manageri koolitusele järgnevad 2015. aastal ka ISTQB Advanced Level Test Analyst (4 päeva) ja Technical Test Analyst (3 päeva) koolitused, samuti ISTQB Foundation  Level Certified Tester Agile Tester Add-on koolitus. 

    Maili Markvardt

    ASA Kvaliteediakadeemia

    neljapäev, 19. juuni 2014

    5 asja, mida hea testijuht teeb

    Eelmisel nädalal kirjutasin, mis juhtub siis, kui testijuhi ülesandeid mitte keegi ei täida ja kuidas testimine siis "korrast ära läheb". Kokkuvõtlikult tagab testijuht testimisteemalise informatsiooni liikumise ja kättesaadavuse – informatsioon tööde kohta testimeeskonnale (kommunikatsioon sissepoole), informatsioon testitulemuste kohta ülejäänud projektimeeskonnale (kommunikatsioon väljapoole). Mida kasutajasõbralikumal viisil (näiteks koos maasikatega hõbekandikul), seda parem.

    Mida tähendab antud juhul "kasutajasõbralik," on juba eraldi küsimus, kuid vihjeks nii palju, et programmeerija ootab testimisest eelkõige vigade taastekitamist võimaldavaid vigade raporteid, projektijuht testimise tähtaegset lõpetamist ja tellija kindlustunnet, et kõik vajalik on testitud ja töötab, või siis maandamata riskide loetelu.

    Vaatame üle mõned tegevused, mida hea testijuht teeb.
    1. Testijuht vaatab üle projektiplaani, ajakava ja ulatuse ning vastavalt sellele planeerib testija(te) tööd, et testimiste plaan oleks realistlik ja piisavas mahus testijaid oleks töödesse kaasatud, ning olukorra muutudes (nt mõni arendus valmib hiljem) tõstatab vajaduse plaanide muutmiseks. Nii on võimalik õigel ajal kaasata lisatestijaid või muuta testimise lõpetamise tähtaega.
    2. Testijuht loob vigade halduses korra. Ta kommunikeerib ja rõhutab vigu ja probleeme, mis takistavad testimist ja seetõttu tuleks lahendada esmajärjekorras. Samuti aitab eristada väheolulisi probleeme ja välja selgitada workarounde, kui viga ei saa parandada. Sellega aitab testijuht fokuseerida nii testijate kui ka arendusmeeskonna tööd, hoides tähelepanu olulisel.
    3. Testijuht planeerib kordustestid. Üldteada on asjaolu, et pärast vigade parandamist tuleb teste korrata. „Väikeseks“ probleemiks selle juures on, et vigu ei tea me kunagi enne testimist ette, mistõttu ei saa me ka kordustesti plaani väga täpselt proaktiivselt koostada. Vigade ilmnemisel planeerib testijuht kordustestid ja regressioonitestid ning nende ulatuse, kuid pahatihti ka testimise katkestamise. See osutub vajalikuks juhul, kui ilmnevad vead või testkeskkonna puudujäägid, mille parandamise järgselt eelmised testitulemused enam väärtust ei oma (ehk testimise jätkamine on ajaraisk).
    4. Testijuht on alati valmis kommunikeerima (ja teeb seda ka perioodiliselt), kuidas testimise progress on, kui palju aega planeeritud testimisele veel kulub, kas plaane tuleb muuta, kui „hea“ on testitav tarkvara, missugused on suuremad vead ning mis hakkab juhtuma (äriliselt, kasutajate jaoks), kui üht või teist viga ei parandata. Kuna üldjuhul tunnevad testijad süsteemi kõige paremini (sest nad on testimise käigus saanud väga põhjaliku kasutajakogemuse), siis on testijuhile see informatsioon tihti kõige lähemal. 
    5. Hea testijuht on lõppkasutajast testija kõige suurem sõber, kes vajadusel õpetab, kuidas testijad mõtlevad ja vigu raporteerivad, nii et olulised kontrollid saaksid tehtud ja paadunud IT inimesed saaksid ka aru, miks kasutaja ütleb: „See ei tööta.“ Kuna kasutajatestijad leiavad tihti olulisi ärilisi vigu, siis on nende tagasiside liiga väärtuslik, et see tõlkes kaduma läheks. Oma võimaluste piires on testijuht ka lõppkasutajast testijate motiveerija, kuna need on mingis mõttes tema tiimi liikmed.
    Nüüd mõtleb hea lugeja kindlasti, et alati ei ole ju otstarbekas ja võimalik eraldi testijuhti (või isegi mitut) palgata?! Lohutuseks võin öelda, et testijuhi rolli võib täita ükskõik kes projektimeeskonnast, aga..!! Pea-asi, et selle rolli täitjal oleks nende ülesannete jaoks piisavalt aega ja teadmisi! Väikestes projektimeeskondades on täiesti tavaline, et testijuhi ülesandeid täidab projektijuht, testija või analüütik. Suurema projekti juhul ei mängi see välja, kuna teiste rollide esindajatel ei ole nii palju aega, tahtmist ega ka testimisalaseid kogemusi, et testimine „korras hoida“. 

    Spetsiaalse (dedicated) testijuhi puhul tuleb kasuks nn teine vaatepunkt, kuna testijuht kõrvalseisjana märkab tihti riske ja küsib küsimusi, mida teised rollid ei märka või peavad ekslikult enesestmõistetavaks. Nii on testijuht ka hea nõuandja projektijuhile (nt projektiplaanist ununes välja testkeskkondade ettevalmistamine) või analüütikule ("kasutajad kurtsid testimise ajal, et tegelikult nad sisestavad andmeid teises järjekorras märkmepaberi pealt, kuna kliendilt saadud andmed on ebatäpsed").

    Häid ja paremaid nõuandeid kuuled ka augusti alguses toimuvas Lloyd Rodeni testijuhtimise meistriklassis.

    Kutse koolitusele
    Koolitus: ISTQB Certified Tester Advanced Level Test Manager (ISTQB CTAL TM)
    Aeg ja koht: 4.- 8. august 2014 Tallinnas, Lõõtsa 8 II korrus
    Hind: 2500€+KM, alates kahest osalejast ühest ettevõttest -10%

    Registeerumine ja lisainfo: Maili Markvardt, maili [at] asaquality.ee
    Koolitus toimub inglise keeles. Hinnas sisalduvad toitlustus ja vajalikud materjalid eksamiks valmistumiseks, kuid ei sisaldu sertifikaadieksami tasu. Kohtade arv on piiratud (10 osalejat), kuna tegemist on intensiivse ja personaalse koolitusega.

    Koolituse eesmärk ja sihtrühm: koolitus aitab süvendada teadmisi testijuhtimisest, mistõttu on vajalik praktiline kokkupuude testimise ja/või testijuhtimisega. Koolitus annab vajalikud teadmised ja oskused ISTQB CTAL TM sertifikaadieksami sooritamiseks. Koolitus toimub ISTQB õppeprogrammi järgi, mida on võimalik vaadata siit: http://www.istqb.org/downloads/finish/46/96.html . Sertifikaadieksami sooritamine eeldab ISTQB CTFL (või samaväärse) sertifikaadi olemasolu, kuid koolitusel pole keelatud osaleda ilma seda omamata.

    Koolitaja: Lloyd Roden (Inglismaa, http://lloydrodenconsultancy.com/)

    Sertifikaadieksami sooritamise võimalus: 11. augustil, hind 250€+KM. Edaspidi korraldab eksameid Eesti Testijate Liit (www.testijateliit.ee).

    ISTQB Advanced Level Test Manageri koolitusele järgnevad 2015. aastal ka ISTQB Advanced Level Test Analyst (4 päeva) ja Technical Test Analyst (3 päeva) koolitused, samuti ISTQB Foundation  Level Certified Tester Agile Tester Add-on koolitus. 

    Maili Markvardt
    ASA Kvaliteediakadeemia

    neljapäev, 12. juuni 2014

    Miks käib testijuht ringi hõbedase kandikuga?

    Testijuht hõbedase kandikuga
    Iga edukas tegevus vajab teatavat juhtimist ja suunamist, ka tarkvara testimine pole siin mingiks erandiks.

    Võin avaldada saladuse, et  isegi juhul, kui arendusprojektis keegi rinnasilti „Testijuht“ ei kanna, siis oma muude ülesannete kõrval keegi (alateadlikult) testijuhi ülesandeid täidab. Lühidalt öelduna on ju testijuht see, kes „hoiab testimise korras“.

    Oletame, et meil on täiesti tavaline arendusprojekt:  selles osaleb analüütik ja kolm (või mitu) arendajat, ning kõike seda juhib projektijuht – nagu IT projektid ikka on. Kusagil „eemal“ on ka tellija esindaja – tegus ja tõsine töötegija, kes IT-st väga palju ei tea, aga on väga hea oma töö tegemises (ja tal on seda väga palju). Projektis on ka testija. Testijale annavad ülesandeid arendajad, suunates tema nimele töödehaldussüsteemis kirjeldatud ülesanded. Testija testib ning märgib ülesandeid ühekaupa „testitud, töötab“, või raporteerib vigu.

    Pealtnäha tundub, et kõik on korras, aga mis juhtub, kui ...
    • Projekt algab -> kes ütleb, mida tuleb testida ja kui palju aega selleks kulub? Funktsionaalsus küll, aga jõudlus? Turvalisus?
    • Kõigi arendajate tööd saavad valmis üheaegselt -> testija muutub pudelikaelaks?
    • Vigu ilmneb palju -> kaob ülevaade, missugused tuleb parandada enne ja millistega on aega? 
    • Vigu parandatakse -> missuguseid teste tuleb korrata (regressiooniteste, kordusteste)?
    • Keset testimist küsib tellija esindaja (või projektijuht või mistahes juht): „Mis seis on?“
      • -> keegi ei oska hästi vastata, kas testimine (ja vigadeparanduste testimine) lõpeb tähtaegselt;
      • -> keegi ei oma üldpilti, kui palju on vigu ja missugused riskid on maandamata (mis juhtub, kui „kohe praegu live’i läheme“).
    • Lõppkasutajad osalevad testimises -> osutub, et see on vähese kasuteguriga – testide katvus on väike ja kontrollimatu (igaüks testib, mis meelde tuleb; kui tuleb), vigade raportid ei ole piisavad, et viga taastekitada (a’la „See ei tööta“)
    Mida suurem ja keerukam projekt, seda tõenäolisem, et nimetatud probleemid tekivad. Kuidas testijuht neid probleeme lahendab, saad aimu juba järgmisel nädalal ilmuvast blogipostitusest. Täpsemalt võid kõike ise läbi harjutada aga augustikuus toimuvas Lloyd Rodeni testijuhtimise meistriklassis. 

    Kutse koolitusele
    Koolitus: ISTQB Certified Tester Advanced Level Test Manager (ISTQB CTAL TM)
    Aeg ja koht: 4.- 8. august 2014 Tallinnas, Lõõtsa 8 II korrus.
    Hind: 2500€+KM, alates kahest osalejast ühest ettevõttest -10%

    Registeerumine ja lisainfo: Maili Markvardt, maili [at] asaquality.ee
    Koolitus toimub inglise keeles. Hinnas sisaldub toitlustus ja vajalikud materjalid eksamiks valmistumiseks, kuid ei sisaldu sertifikaadieksami tasu. Kohtade arv on piiratud (10 osalejat), kuna tegemist on intensiivse ja personaalse koolitusega.

    Koolituse eesmärk ja sihtrühm: koolitus aitab süvendada teadmisi testijuhtimisest, mistõttu on vajalik praktiline kokkupuude testimise ja/või testijuhtimisega. Koolitus annab vajalikud teadmised ja oskused ISTQB CTAL TM sertifikaadieksami sooritamiseks. Koolitus toimub ISTQB õppeprogrammi järgi, mida on võimalik vaadata siit: http://www.istqb.org/downloads/finish/46/96.html . Sertifikaadieksami sooritamine eeldab ISTQB CTFL (või samaväärse) sertifikaadi olemasolu, kuid koolitusel pole keelatud osaleda ilma seda omamata.

    Koolitaja: Lloyd Roden (Inglismaa, http://lloydrodenconsultancy.com/)

    Sertifikaadieksami sooritamise võimalus: 11. augustil, hind 250€+KM. Edaspidi korraldab eksameid Eesti Testijate Liit (www.testijateliit.ee).

    ISTQB Advanced Level Test Manageri koolitusele järgnevad 2015. aastal ka ISTQB Advanced Level Test Analyst (4 päeva) ja Technical Test Analyst (3 päeva) koolitused, samuti ISTQB Foundation  Level Certified Tester Agile Tester Add-on koolitus. 

    Maili Markvardt
    ASA Kvaliteediakadeemia

    reede, 30. mai 2014

    Tehnosotsiaalne sahkerdamine

    Sotsiaalne sahkerdamine (Social engineering) on meetod, mille käigus kasutatakse infole või ressurssidele (nt IT-süsteemidele) omavolilise ligipääsu saamiseks erinevaid inimestega manipuleerimise tehnikaid. Oskusliku pettuse tõkestamine on üpriski keeruline, sest inimeste loomuses (ja sageli ka töökirjelduses) on olla abivalmis ja kuulekas. Seetõttu on isegi umbusklikul töötajal raske keelduda autoriteetse ja enesekindla häälega jagatud juhistest või hädasolija abipalvest. Mis see sotsiaalne sahkerdamine aga ikkagi täpsemalt on ja kuidas sellega kaasnevatest kurbadest tagajärgedest hoiduda?


    Sotsiaalne mõjutamine

    Teiste inimeste mõjutamine kui meetod oma eesmärkide saavutamiseks pärineb juba eelajaloolisest ajast, sest ilma üksteise mõjutamiseta on praktiliselt võimatu koostööd teha. Sotsiaalse sahkerdamise all on aga antud kontekstis mõeldud pigem omakasupüüdlikku manipulatsiooni, mis võimaldab saavutada vajaliku tulemuse lihtsa suhtluse abil. Küberturvalisuse kontekstis rõhutab social engineering võimalust inimeste manipuleerimise abil mööda hiilida tehnilistest turvameetmetest. Näiteks võib e-posti kontole ligipääsemiseks keeruka häkkimise asemel lihtsalt kasutajalt otse küsida. Kui õnnestub jätta mulje, et seda nõuab ülemus, politsei või keegi teine autoriteetne isik, siis ei ole sugugi välistatud, et kasutaja oma parooli näiteks telefonikõnes vabatahtlikult avaldab. Veel üks levinud võte personaalset informatsiooni välja petta on teenindava personali kaudu, kelle tööülesandeks on inimesi aidata. Hädasoleva kliendi või väidetava kolleegi aitamiseks võivad mitmed teenindajad kogemata manipulatiivsele ründajale konfidentsiaalset informatsiooni paljastada.

    Tehnosotsiaalne sahkerdamine 

    Eriti tõhus (ja seetõttu ohtlik) on sotsiaalne mõjutamine, kui seda kombineerida tehnilise küberrünnakuga. Näiteks võib rünnatav arvutikasutaja keelduda oma kasutajanime ja parooli telefoni teel avalikustamast, kuid installib kuulekalt väidetava IT-toe poolt saadetava turvauuenduse, mis võib tegelikult olla viirus, klahvinuhk (keylogger) või muu pahavara. Tänapäevaste vabalt Internetis levitavate häkkimisvahenditega on lihtne luua vajalikust veebilehest suhteliselt täpne koopia, mis salamisi külastajate arvutitest turvaauke püüab leida. Vahel pole isegi turvaauku vaja leida, kui õnnestub rünnatavat kasutajat veenda oma isiklikke andmeid vabatahtlikult sisestama.

    Tehnilisi ja sotsiaalseid oskusi meisterlikult kasutades suutis Kevin Mitnick, üks tuntumaid sotsiaalseid sahkerdajaid, kolm aastat FBI-ga kassi-hiirt mängida. Kui FBI agendid (enda meelest) ootamatult Mitnick’i korterit külastasid, leidsid nad külmkapist paki sõõrikuid pilkava sildiga “FBI donuts.” Mitnicki enda sõnul tegeles ta inimeste tüssamisega peamiselt enda lõbuks, mitte rahalistel eesmärkidel.

    Aina rohkem on aga küberkriminaalid hakanud inimeste lihtsameelust ja abivalmidust kurjalt ära kasutama just sooviga - kas siis otseselt (nt inimestelt raha või hinnalist infot välja pettes) või kaudselt (nt konkurendi mainet kahjustades) - rikastuda. Kuna sotsiaalne sahkerdamine on oma olemuselt väga lihtne, siis on seda ennetada üpris keeruline. Näiteks pommiähvardusega saab hakkama isegi algkooli õpilane ja tegelikku ähvardust võltsist eraldada on praktiliselt võimatu. Kuidas siis ikkagi vähendada riski tehnosotsiaalse sahkerdamise ohvriks sattuda?

    Sahkerdamisvastased abinõud

    Tehnosotsiaalse sahkerdamise vastu tegutsemist tasub organisatsioonides alustada uutest töötajatest, sest just nemad on oma ebakindluse ja kogenematusega libekeelsete ründajate lemmiksihtrühm. Võimalikult varakult tuleks veenduda, et kõik töötajad on kursis organisatsiooni eeskirjade ja tavadega. Lisaks tuleks kõigile töötajatele selgeks teha, kuidas potentsiaalseid pettureid ära tunda ja mida sel juhul teha.

    Näiteks tasub eriti ettevaatlik olla tundmatute inimestega, kellel on väga kiire. Hädaolukorra (vähemalt näilik) loomine takistab rünnataval isikul selge pilguga olukorda hinnata ja suurendab tõenäosust, et tegutsetakse mõtlematult petturi abistamiseks. Peaaegu alati on võimalik korraks aeg maha võtta ja pakilist probleemi rahulikult lahata. Abiks oleks kindlasti ka täpsed eeskirjad, mida erinevate hädaolukordade puhul tuleks järgida.

    Teine märk, mis peaks koheselt valvsust suurendama, on salasõna küsimine. Professionaalne IT-töötaja, koristaja, naaber alumiselt korruselt, teller pangas ega keegi teine ei tohiks huvi tunda kellegi teise isikliku salasõna või koodi vastu.

    Valvsust peaks koheselt suurendama ka e-kirjas sisalduv viide või manustatud fail. Kui e-kiri pärineb tuttavalt inimeselt, kuid selle sisu on vähimalgi määral ebatavaline, siis tasub võimaluse korral saatjaga (näiteks telefoni teel) ühendust võtta ja kontrollida, et kiri tõepoolest pärineb väidetavalt isikult.

    Lisaks tehnilistele tulemüüridele ja viirusekaitseprogrammidele tasuks üle vaadata ka arvuti füüsiline kaitse. Näiteks pole sugugi välistatud, et suuremates organisatsioonides saab enesekindla olekuga kurikael sületäie sülearvutitega tähtsal ilmel asutuse peauksest välja marssida ilma, et keegi midagi kahtlustaks. Töökohas oma arvuti tagant lahkudes tasub see kindlasti lukustada. ASA Quality Services kontoris on näiteks selline kord, et järelvalveta ning lukustamata jäetud arvuti omanik toob kolleegidele maiustamiseks koogi. Säärased meetmed tekitavad ka uutes töötajates kiirelt harjumuse laua tagant lahkudes oma arvuti eeskirjade kohaselt lukustada.

    Turvalisuse mitu kihti

    Erinevate inimmanipulatsioonide vältimisel ei maksa aga unustada ka tavapärast turvarutiini. Mitmeastmeline autentimine ja korralik paroolihaldus aitavad võimaliku infolekke levimist tõkestada ning tarkvarauuendused takistavad laialdaselt teadaolevate turvaaukude ärakasutamist. Nii nagu maja ehitamisel ja korras hoidmisel tuleb tähelepanu pöörata igale seinale (ning meeles pidada ka vundamenti ja katust kontrollida), nii tasub ka küberturvalisuse puhul tähelepanu pöörata lisaks arvutitevahelist suhtlust kirjeldava OSI mudeli seitsmele suhtlustasandile ka kaheksandale – inimfaktorit sisaldavale kihile. Kõige tõhusam kaitse küberrünnakute vastu on terviklik turvapoliitika: lisaks tehniliste rünnete vältimisele tuleks hoiduda ka sotsiaalse sahkerdamise eest.




    Sten Mäses
    ASA Quality Services

    Piltide allikad: img.gawkerassets.com ja edugeeks.in

    neljapäev, 29. mai 2014

    Automaattestimine - mis see on?

    Kõik infotehnoloogiaga tegelevad ettevõtted teavad, et testimine on vajalik, kuid tihti leitakse ka juba töötavas ehk live-süsteemis vigu. Mida siis tehakse valesti? Kas testimiseks kulutatakse liiga vähe aega? Puuduvad oskused testida või ei testita seda, mida vaja? Räägin järgnevalt ühest võimalikust lahendusest, mis võib muuta testimise protsessi oluliselt kiiremaks – nimelt automaattestimisest.

    allikas: http://www.wallpele.com/robot-3d-hd-wallpaper/robot-3d-hd-wallpaper/

    Mis siis ikkagi on automaattestimine? See on arvuti õpetamine, kuidas mingit infosüsteemi testida. Kirjutatakse valmis koodijupid, mille käivitamisel teeb arvuti läbi tegevused, mida muidu testija peaks käsitsi tegema. Manuaaltestimisest erinebki see selle poolest, et sisaldab endas koodikirjutamist. Testide automatiseerimine on aeganõudev tegevus, kuid tasub ära, kui testimisfaasis on tegevused, mida manuaaltestija peab mitmeid kordi kordama.

    Automaattestimise kasutusjuhud

    Millistel tingimustel on mõttekas testide automatiseerimist kasutada?

    • Kui tegemist on suure infosüsteemiga, mille käsitsitestimine võtab nii palju aega, et see muutub pudelikaelaks arendusprotsessis.
    • Kui osa süsteemist on juba valmis, kuid arendamine veel käib. Sellisel juhul on regressioonitestide* tegemine väga oluline. Enamasti automatiseeritakse just regressiooniteste.


    Millistel tingimustel võiks selle mõtte välistada?

    • Kui testimiseks on väga vähe aega.
    • Kui planeeritud testimisringe on ainult mõni (näiteks üks või kaks).
    • Kui käsil on UAT (vastuvõtutestimise) faas.
    • Kui tegu on väikese süsteemiga, millele ei tule lisaarendusi.

    Muidugi on olemas erandeid ja puudub 100% õige variant, kuidas süsteem saaks piisavalt testitud. Piisava testimise all ei mõtle ma täielikku testimist (exhaustive testing). Pidagem silmas, et täielik testimine pole otstarbekas ja on üsna võimatu. See on ajamahukam, kui infosüsteemi arendamine, ja võib isegi öelda, et nn kilplaslik tegevus. Piisava testimise all mõtlen ma seda, et kõik ärinõuded on kontrollitud, täidetud ning ärinõuete järgi arendatu töötab. Automaattestimine on üks võimalus, kuidas süsteemi testimise protsessi kiirendada. Seega aitab see ka etteantud ajapiirangu sees suuremat osa süsteemis olevat funktsionaalsust kontrollida võrreldes ainult käsitsitestimise kasutamisega.

    Automatiseeritud testikomplektide haldamine 

    Automaattestimist võib võrrelda programmeerimisega, sest selles protsessis kirjutatakse koodi ning kasutatakse erinevaid programme ja platvorme. Samuti on oluline versioonihaldus ehk kirjutatud koodijupid peavad olema korralikult organiseeritud ning loetavad. Harjumuspärane tegevus on ka testikomplektide hooldus, sest valmiskirjutatud skriptid võivad kergelt katki minna. Nagu näha – testide automatiseerimine sisaldab endas palju tööd.

    Veel märkuseid

    • Kõiki teste pole mõttekas automatiseerida – alati tuleb mõned osad süsteemist käsitsi läbi testida, kuna masinat ei saa täielikult usaldada.
    • Testide automatiseerimine on kallis.
    • Automatiseerimiseks on väga palju erinevaid vahendeid ning enne automaattestide kirjutamist tuleks enda jaoks selgeks teha, milline neist on parim.
    • Automaattestimise eelduseks on korralik testianalüüs ehk peab olema välja selgitatud, mida automatiseerida. Kindlasti ei saa teha nii, et hakatakse eelneva planeerimiseta lihtsalt mingist süsteemiosast testilugudele automaatteste kirjutama, sest pärast on raske saada ülevaadet, millised osad on kaetud ja mis mitte.
    • OHT: ebarealistlikud ootused – levinuim viga, mille tõttu võib automatiseerimine läbi kukkuda. Sellised on näiteks ootused, et testimine muutub palju odavamaks või et leitakse kõik vead. 


    Edulugusid

    Tegelikkuses tasub automaattestimine end kuhjaga ära – seda tuleb vaid õiges kohas rakendada. Näiteid edukast automatiseerimisest on mitmeid. Näiteks Dorothy Grahami ja Mark Fewsteri raamatus „Experiences of Test Automation“ on mitmeid lugusid. Üks jutuke ses raamatus Randy Rice’i poolt räägib sellest, kuidas suures Wall Street’i ettevõttes kasutas ta seda võimalust. Nimelt - ühe õnnetu daami tööülesandeks oli iga päev 8 tundi järjest läbida samu testilugusid. Mees leidis, et peaks ressursse targemini ära kasutama ning võttis ühendust testide automatiseerimist pakkuva firmaga, kes automatiseeris kolme päevaga selle 8 tunni töö. Testilugude läbimiseks kulus nüüd daamil igal hommikul vaid 15 minutit ja ta sai kasutada oma aega uute funktsionaalsuste testimiseks.

    Pilt: Shutterstock


    Eduka automatiseerimise tulemuseks on ajaline ja ka rahaline võit. Sõna „edukas“ on suure kaaluga, sest nagu eelnevalt kirjutasin, on suur oht automatiseerimisest liiga palju oodata. Seda vales kohas kasutades võib see vaid kuluks osutuda.

    Kokkuvõtteks

    Loodan, et see postitus andis põgusa ülevaate ja arusaamise, millega tegemist on. Kui tekkis küsimusi või tahate hoopis vastu vaielda, ootan teid postitust kommenteerima.


    Kristi Paakspuu
    ASA Quality Services

    *regressioonitestid – igasugused tarkvara testid, mis otsivad muudatuste käigus ilmnenud vigu eelnevalt korrektselt funktsioneerinud koodis. Selle eesmärgiks on leida ootamatuid vigu.

    Kasutatud kirjandus:

    • Dorothy Graham, Mark Fewster „Experiences of Test Automation“, 2012



    teisipäev, 6. mai 2014

    IREB requirements engineeringu koolitus - täpsustatud kava

    10. - 12. mail 2016 toimub IREBi nõuete ehitamise (Requirements Engineering) koolitus.

    Tarkvara nõuete kogumisel ja kirjeldamisel tehtud vead tekivad varakult, jäävad leidmata ja ... nende parandamine on ülimalt kallis... Tahad teada, kuidas tarkvaranõudeid ehitada? Kas nõuetel on kohta agiilses tarkvaraarenduses? Kuidas vältida „tõlkes kadumaminemist“ tarkvaraprojektides? Kuidas tarkvaranõudeid testida? Kuidas tarkvaranõudeid vääriliselt hallata? Tule koolitusele! 
    Millal? 17. - 19. mail 2017
    Kus? Ehitajate tee 108, ASA koolitusklass
    Kui palju maksab? märtsis 1440€ +KM (edaspidi 1600€+KM). Hind sisaldab elektroonilisi ja trükitud materjale ning kohvipause ja lõunasööki kolmel päeval. Alates kolmest inimesest ühest ettevõttest soodustused
    Koolituse keel: inglise
    Registreerumine ja küsimused: maili [at] asaquality.ee
    Koolituse eesmärk: Anda põhiteadmised nõuete ehitamise (requirements engineering) põhilistest valdkondadest: süsteemi konteksti mõistmine, nõuete alusinfo kogumise tehnikad, korrektne ja üheseltmõistetav kirjapanemine, läbirääkimised vastuolude leidmiseks ning kõrvaldamiseks, nõuete haldamine ja abistavad tööriistad.
    Koolituse läbinul on võimalik lisatasu eest (280€) sooritada CPRE-FL sertifikaadieksam, mida pakub  IT Koolituskeskuse OÜ (www.koolitus.ee).

    Koolituse sihtrühm: Põhiline sihtgrupp on analüütikud (süsteemi- ja ärianalüütikud), kes nõuete ehitamisega igapäevaselt tegelevad. Laiemalt kõik rollid, kes peavad ära tundma, kas nõuded on kvaliteetselt kirjeldatud ja oskama öelda, mis vajab parandamist (näiteks kõrgema taseme testijad või testijuhid).

    Koolitajad: Matthias Koch, Eduard Groen (Fraunhofer IESE, www.fraunhofer.de)

    Matthias Koch studied computer science with a focus on software engineering. Since 2012, he is employed as engineer at Fraunhofer IESE and mainly addresses the topics of requirements engineering and business analysis. In this context, he was involved in research projects on the pre-project and requirements definition phase, case studies and product evaluations. In research as well as industry projects, he regularly acts as requirements responsible, conducts workshops with customers and provides consulting.

    Eduard C. Groen received his Master of Science in Psychology, with a specialization in Engineering Psychology, from the University of Twente in the Netherlands. He furthermore has experience with quality and sustainability management. His fascination with the rapid rise of man-machine interfaces and other changes that affect society inspires him to contribute with technologies that optimally make use of the potential that these developments bring. This is why he leads the development of “Crowd-based Requirements Engineering” at Fraunhofer IESE, a tool-based approach to elicit and validate requirements with large online crowds. He furthermore provides trainings, and consults in projects on process management and variability management.

    Päevakava (orienteeruv):
    Day 1 (09:00-17:00)
    Introduction & Basics - software requiremets
    Defining the System Context
    Requirements Elicitation (survey, creativity, observation and other techniques)
    Requirements Specification and documentation
    Exercises

    Day 2 (09:00–17:00)
    Repetition
    Requirements Specification and documentation continues
    Requirements Modeling (functional, data and behavioral models)
    Exercises

    Day 3(09:00–17:00)
    Repetition
    Requirements Validation & Negotiation
    Quality attributes of requrements
    Requirement testing methods
    Resolving requirements conflicts

    Requirements Management and versioning
    Establishing requirements traceability
    Prioritizing requirements
    Requirements Tools overview
    Wrap-up

    Teemast loe lähemalt veel siit: http://asaquality.blogspot.com.ee/2014/04/alustame-ehitamist-vundamendist.html