Hüvasti, Windows XP!

8. aprillist lõpetas Microsoft Windows XP tehnilise toe pakkumise ja seetõttu on XP kasutajatel tungivalt soovitatav kiiremas korras operatsioonisüsteem välja vahetada.

Windows XP jätkuv populaarsus

Windows XP on Microsofti loodud operatsioonisüsteemidest üks kõige õnnestunumaid. Sellele järgnenud Windows Vista-le loodi lausa eraldi võimalus tagasi XP juurde pöörduda (downgrade opportunity) ja oma populaarsuse tipul kasutas XP-d ligi 75% kõikidest arvutikasutajatest. Uuemate operatsioonisüsteemide tulekuga on XP populaarsus küll langenud, kuid eri andmetel (nt Trend Micro, NetMarketShare, Statista) kasutab seda jätkuvalt ikka veel enam kui viiendik arvutikasutajatest üle maailma ja RIA hinnangul lausa kolmandik arvutikasutajatest Eestis. Tehnilise toe säilitamine nõuab aga Microsofti poolt märkimisväärseid ressursse ja seetõttu otsustati 12 aastat kasutusel olnud operatsioonisüsteem maha kanda ja keskenduda kaasaegsemate tehnoloogiate arendamisele.

Lisaks tavakasutajatele kasutab Windows XP-d ka hirmuäratav kogus pangandussektorist. Nimelt tuginevad BusinessWeek’i andmetel 95% pangaautomaatidest maailmas endiselt Windows XP operatsioonisüsteemile. Tänu pankade ja teiste suurkorporatsioonide survele ongi XP üle kümne aasta vastu pidanud, kuid nüüd loodab Microsoft Windows XP tehnilise toe lõpetamisega mitmeid suurfirmasid kaasaegsemat tarkvara hankima sundida. Mitmed pangad aga väidavad, et aeguv tarkvara nende juurutatud lahenduste turvalisust ei mõjuta ja kasutavad pangaautomaatides Windows XP-d edasi.


Turvariskid

Sedavõrd populaarse operatsioonisüsteemi tehnilise toe lõpetamine tähendab seda, et enam ei pakuta uuendusi, mis kaitseksid leitud turvaaukude kuritarvitamise eest. Seetõttu on äärmiselt keeruline takistada pahavarade massilist levikut. Kasutajale nähtavalt ei pruugi aga veel tükk aega midagi arvuti töös muutuda ja võib arvata, et paljud kodukasutajad jätkavad turvariskidest hoolimata harjumuspärase Windows XP kasutamist. Asjaolu, et isegi Windows XP värskel paigaldamisel nakatub Internetti ühendatud operatsioonisüsteem vähem kui 4 minutiga  ei pruugi olla ilmne, sest nähtavasti õnnestub veebilehitsejaid ja muud tarkvara Windows XP masinas jätkuvalt edukalt kasutada ja kõik tundub ju töötavat ilusti.

Tegelikkuses on XP operatsioonisüsteemi kasutavad arvutid olnud juba mõnda aega küberkurjategijate üks lemmiksihtmärkidest. Näiteks muudab Windows XP puudulik paroolide käitlemine (sh suur- ja väiketähtede samaväärsus ja piirangud parooli pikkusele) kasutuks isegi kõrge turvalisusega paroolid ja graafilise liidese varjus toimuv protsessidevaheline suhtlus (IPC) on ebaturvaliseks loodud. Järjepidevad uuendused aitavad aga vähemalt mingil määral küberründeid takistada. Kui nüüd on aga lõpp igasugustel turvauuendustel, siis võib leitud vigu lõpmatuseni kuritarvitada. Küberkurjategija ei pea enam kartma, et Microsoft ühel hetkel kriitilise turvaaugu uuenduste abil ära parandab.

Kuidas riske vältida

Kõigil Windows XP kasutajatel tasuks hoolega järele mõelda, kas ikka tasub turvariskile vaatamata aegunud operatsioonisüsteemi edasi kasutada. Isegi kui arvutis endas ei ole konfidentsiaalseid andmeid saab lihtsa keylogger’i abil kergesti kätte erinevad salasõnad. Tõsi, mitmeastmelise enesetuvastuse abil saab kontode kaaperdamist vältida, kuid üldiselt tasuks ikkagi rakendada mõnda terviklikumat viisi oma turvalisuse parandamiseks. Isiklike andmete kadumisriskile lisaks on suur tõenäosus, et turvauuendusteta jäänud Windows XP masinad liidetakse mõne zombiarmeega, kus vastavalt käskudele saadetakse tavakasutajale nähtamatult tema arvutit kuritegelikel eesmärkidel rakendatakse.

Mida siis teha, et Windows XP aegumisega seonduvaid riske vältida? Vastus on lihtne: tuleb hankida endale tänapäevasem operatsioonisüsteem. Kui uut arvutit osta ei raatsi ja vana arvuti Windows 8.1 jaoks piisavalt võimekas ei tundu, siis tasub kaaluda tasuta Linuxi peale üleminekut. Eesti kasutajale suunatud Estobuntu ja maailma populaarseim Linuxi distributsioon Ubuntu Desktop saavad edukalt hakkama igapäevase veebilehitsemisega (sh ID-kaardiga sisse logimised ja allkirjastamised). Tasuta jagatavad kontoritarkvarad (OpenOffice ja LibreOffice) üheskoos veebipõhiste viisidega dokumente luua ja muuta (MS OneDrive, Google Drive) pakuvad rohkelt võimalusi Windows’iga lõplikult hüvasti jätta.

Loodame parimat ning soovime edu Windows XP operatsioonisüsteemiga hüvastijätmisel!

Sten Mäses
ASA Quality Services

Pildi allikas: finewallpaperss

IREB Requirements Engineering koolitus esmakordselt Eestis!

Tahad teada, kuidas nõudeid ehitada? Kuidas vältida inimlikku ja keelelist ekslikkust? Kuidas oma suure töö tulemust vääriliselt hallata? Tule koolitusele! IREB Certified Professional for Requirements Engineering koolitus esmakordselt Eestis!

Koolitus: Certified Professional for Requirements Engineering Foundation Level (CPRE-FL)
Koolituse aeg: 26. - 28. mai 2014

Hind: 1600€ (käibemaksu ei lisandu). Alates kolmest inimesest ühest organisatsioonist 10% soodustus. Kohtade arv on piiratud.

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 on Saksamaalt, Fraunhofer IESEst (http://www.iese.fraunhofer.de/en.html). Koolitus toimub inglise keeles. Hinna sees on toitlustus ja trükitud materjalid ning võimalus kasutada internetist allalaaditavaid materjale. Koolitajad on akrediteeritud IREB'i (International Requirements Engineering Board, www.ireb.org) poolt.

IREB on rahvusvaheline organisatsioon, kes seisab hea nõuete ehitamise ja tarkvara (süsteemi/äri) analüüsiga seotud praktikate väljatöötamise ja levitamise eest.

Täpsem info ja koolitusele registreerumine: Maili Markvardt, maili@asaquality.ee

Loe ka Maili eelmist kirjutist nõuetest: http://asaquality.blogspot.com/2014/04/alustame-ehitamist-vundamendist.html

Alustame ehitamist vundamendist!

Tarkvaranõuetel ja ehitiste vundamentidel on palju ühist. Kolmnurkse vundamendi peale nelinurkset maja ei ehita. Hooletult ehitatud vundament vajub ära, võttes kaasa ka selle peale ehitatud maja. Vundamendi parandamine, kui maja on juba peale ehitatud, on kordades kallim kui vundamendi parandamine enne maja ehitamist. Vundamendi kvaliteeti on keskmisel majaelanikul keerukas hinnata; selleks on vaja erilisi teadmisi. Pigem kipuvad silma paistma, häirima ja kahju tegema puudujäägid maja kvaliteedis. Hea vundament ei garanteeri, et maja tuleb kvaliteetne, kuid kehv vundament garanteerib üldjuhul vildaka maja.

Kui teha asendused „vundament“ - > „nõuded, „maja“ - > „tarkvara“, „keskmine majaelanik“ -> „keskmine tarkvara kasutaja“, siis jäävad nimetatud väited siiski kehtima.

Isegi kui me aktsepteerime asjaolu, et väljend „külmutatud nõuded“ on oksüümoron*, ei saa nõuetesse suhtuda hooletult ja pealiskaudselt, mõeldes, et „need niikuinii muutuvad, ei pea vaeva nägema“. Nõuete kirjeldamise puhul peaks olema eesmärgiks saada kirja kõik vajalik (ja mitte sõnagi rohkem), eemaldada mitmetimõistetavused – mis on tihti keelelise ebatäpsuse ja inimliku ekslikkuse tulemus – ja hoolitseda saadud tulemuse eest kuninga kassi vääriliselt.

Missuguse kivi all on nõuded peidus?

Nõuded pole tegelikult miski, mida saab „rehaga kokku rehitseda“ või tavapäraselt „koguda“. Kuna loodav tarkvara on midagi uut (keegi ei tee ju uut tarkvara, et see oleks täpselt samasugune, kui juba mõni olemasolev), siis valmis nõudeid lihtsalt ei ole olemas! Olemas on reaalse maailma poolt tulevad ootused, vajadused, aimdused, piirangud ja kohustused, mis asuvad erinevate osapoolte peades. Kas peade omanikud oskavad oma mõtteid alati väljendada? Kas nõuete „koguja“ oskab alati leida õige allika?

Sisuliselt õigem väljend oleks hoopiski „nõuete väljatöötamine" või „nõuete ehitamine“. Ingliskeelne väljend kõlab requirements engineering, kuid päris head eestikeelset vastet ma polegi osanud sellele sõnapaarile leida.

Nõuded on niisiis vajaduse, ootuse või piirangu kirjalik, taasesitust ja kommunikatsiooni võimaldav esitusviis. Nõuded võivad tuleneda loodava tarkvara tulevastelt kasutajatelt, aga ka muudelt huvipooltelt. Oluline on kõik nõuete allikad üles leida.

Näiteks, kui me arendaksime kooli õppeinfosüsteemi, siis kust tulevad nõuded sellele? Kas lisaks sisseastujate, õppurite, õpetajate, juhtkonna ning kooli personali vajadustele peaksime arvestama veel millegagi? Aga loomulikult. Üheks oluliseks nõuete allikaks on ka valdkonda reguleeriv seadusandlus. Kooli õppeinfosüsteemi loomisel peame arvatavasti arvestama (olenevalt kooli tasemest ja funktsionaalsuse ulatusest) ülikooliseadusega, erakooliseadusega, haridusseadusega, raamatupidamisseadusega, võlaõigusseadusega...

Tihti lähevad olulised nõuete allikad, näiteks eelnimetatud seadused, lihtsalt meelest.. Tüüpiline puudus, mida testimise käigus nõuete ülevaatusel täheldanud olen, on ka näiteks kasutajaõiguste halduse ning rollide kirjeldamata unustamine. Seda pärast tarkvarale „juurde pookida“ on juba keeruline. Vilunud (või kontrollnimekirja omav) analüütik teab, kus kivi all nõuded peidus on, ja oskab sinna vaadata.

Luuletused, haikud ja novellid ... programmeerija ja testija laual

Inimkeel on imeline asi oma väljendusrikkuses ja annab lõpmatul hulgal materjali ilusate luuletuste ja sügavamõtteliste romaanide kirjutamiseks, kus tekstiridadesse on kirjutatud vähem kui nende vahele. Tarkvaraspetsifikatsioonid on aga tähtsad dokumendid, ning nende juures pole inimkeele värvikus just kiiduväärt omadus.

Sõnade tähendused keeles on suhteliselt kokkuleppelised, seetõttu inimesed lähtuvalt oma taustast, haridusest ja kujutlusvõimest võivad mõista sõnu erinevalt. „Tõlkes kadumaminek“ võib juhtuda vähemalt neljas erinevas kohas:

1. Idee autor ei suuda oma mõtteid väljendada nii nagu ta mõtleb;
2. Idee kirjapanija (analüütik) ei oska aru saada (kuulata) nii nagu idee autor mõtleb;
3. Idee kirjapanija ei suuda end väljendada nii nagu ta tahaks;
4. Kirjutatu lugeja (nt programmeerija) ei saa aru nii nagu kirjutaja mõtles.

Niisiis on iga nõuet kirjeldades ainult umbes 1/5 tõenäosus, et see jõuab muutumatul kujul idee autorist programmeerijani.

Teatud keelelised iseärasused ei pruugi samuti soodustada kirjutatu üheseltmõisteavust. Võtame näiteks järgmise lause „Kõik lambid on seotud lülitiga“.

Hea lugeja, mõtle korraks, kuidas Sa sellist „konfiguratsiooni“ ette kujutaksid? Keeleliselt kannab see konstruktsioon nime „üldistus + mitmus“ ning ta on juba oma ülesehituselt  kahetimõistetav nii eesti, inglise kui ka saksa keeles.

Esimene interpretatsioon oleks selline: Iga lamp on seotud oma lülitiga (1:1 suhe).

Pildi allikas: flickr

Teine interpretatsioon oleks selline: Iga lamp elutoas on seotud kõigi lampide peale ühise lülitiga (1:N suhe).

Pildi allikas: wikimedia.org

Nii elektritöödel juhtmete vedamise kui ka andmebaasi ehitamise seisukohalt on tegemist kahe väga erineva lahendusega. Niisiis aitab ohtlike keelekonstruktsioonide teadmine (neid on palju rohkem kui eelnevalt käsitletud näide) neid vältida ja ära tunda – seega vältida võimalikku vääritimõistmist enne, kui see jõuab vale realisatsioonina koodi.


Kuidas hallata kuninga kassi?

Analüütik on lõpuks kõigi vajalike osapooltega vestelnud, uurinud seadusi ja standardeid ning nende põhjal nõuete komplekti valmis ehitanud. See kunstiteos ei ole mõeldud kindlasti kusagile sahtlisse tolmu koguma!

Esiteks peavad nõuded jõudma oma tarbijani, kelleks on nii realiseerijad/edasiarendajad (arhitektid, disainerid, programmeerijad) kui ka testijad. Missuguste tööriistadega seda kõige paremini saavutada? Kas tekstidokumentides „elavad“ nõuded on kõigile hästi leitavad ja kättesaadavad, või oleks tarvis mõnda nõuetehaldustarkvara, mis oleks ka integreeritud mõne testihaldustarkvaraga? Kõik see oleneb organisatsiooni ja projekti suurusest.

Teiseks, väljend „lõplikud nõuded“ kipub olema oksüümoron. Nõuded muutuvad ja see ongi elu. Kuid muudatustele tuleb reageerida ja neid hallata – ilma soojemaks muutudes on ju loogiline kasukas päikesevarju vastu vahetada. Üldjuhul peaks ka nõude muutumisele järgnema terve kaskaad tegevusest – muudatuse mahtude hindamine, seotud osade/komponentide/protsesside leidmine, disaini muutmine, ümberkodeerimine, testimine. Kõik need tegevused on vajalikud ja kõik osapooled, kes arendusprotsessis osalevad, peavad muudatuse info õigeaegselt saama, vastasel juhul väljendub see kohe tarkvara kvaliteedi languses.

Hea analüütik tagab ka selle, et tema raske töö tähtsat tulemust on võimalik teistel osapooltel kasutada, ja haldab nõuete muudatusi nii, et kõigil osapooltel oleks kättesaadaval just ajakohane ja antud ajahetkel õige info.

Kokkuvõtteks

Tarkvaranõuete puhul on oluline need kätte saada – unustamata ühtki osapoolt või mõjutajat – ja üheselt mõistetavalt kirja panna. Hea analüütik ja kindlasti ka hea testija peaks tundma konkse, kus informatsioon kaduma läheb ning moondub. Nõuetest endist pole vähem tähtis ka see, kuidas neid hiljem hallatakse ja kaasajastatakse. Juhin tähelepanu – nõuded on elusad olevused, nendega ei tohi hoolimatult ümber käia – surnud nõuded lähevad haisema!

Maili Markvardt
ASA Kvaliteediakadeemia

Maili on Eesti Testijate Liidu asutajaliige ja kuulub ka ETLi juhatusse. Ühtlasi õpetab ta tarkvara kvaliteediteemasid Tallinna Tehnikaülikoolis ja Eesti Infotehnoloogia Kolledžis. "Testimine ei ole elukutse, testimine on elustiil!"

* oksüümoron – vastandtähendusi sisaldav väljend

Kuidas luua head parooli?

Paroolid on enimlevinud vahend küberruumis enese tuvastamiseks ja seetõttu otseselt või kaudselt üks küberkriminaalide peamisi sihtmärke. Personaalsete veebiteenuste kasutamiseks tuleb paratamatult end kuidagi identifitseerida, seega käib tänapäevane veebis surfamine läbi paroolirägastiku. Paljud arvutikasutajad lähevad lihtsama vastupanu teed ja kasutavad sama parooli mitmes erinevas kohas, sest kümnete erinevate salasõnade meeles hoidmine on liiga keeruline. Lisaks valitakse sageli turvariskist hoolimata parooliks midagi sellist, mis võimalikult kergesti meelde jääks, näiteks kombinatsioon oma sünniajast, mõne sugulase nimest, aadressist ja telefoninumbrist. Selline tegutsemine suurendab aga märgatavalt riski, et mõni pahatahtlik isik suudab parooliga kaitstud kontole ligi pääseda. Kuidas siis ikkagi luua hea parool ja see ka korralikult meelde jätta?

Levinud ja lihtsasti äraarvatavad paroolid Järgnevalt mõned näited viisidest salasõnade loomiseks, mida tasub vältida, sest neid on suhteliselt lihtne ära arvata:

1. Sinu partneri, lapse või kodulooma nimi (või nimetähed), millele sageli järgneb number 1, 12 või 123 (sest alatasa nõutakse, et parool sisaldaks ka numbreid).
2. Sünniaeg – kuupäev või aasta, millal sündisid või mõni muu tähtis kuupäev, mille Sinu facebooki sõber kerge vaevaga üles leida suudaks.
3. Sinu aadress – tänav, linnaosa, linn või riik.
4. Sinu enda või mõne lähedase telefoninumber, mis on aja jooksul pähe kulunud.
5. “tere”, “teretere”, “123456”, “qwerty”, “salas6na”, “Pa$$w0rd” või mõni muu laialdaselt levinud märgijada.
6. Kuulsuse nimi - poliitikud, sportlased, filmistaarid ja teised meediast tuntud isikud
7. Kombinatsioon eelnevalt loetletud punktidest, näiteks “tere1972” või “Rakvere123”

Õnneks ei lase enamik veebiteenuseid parooli mitu korda järjest proovida, kuid paraku ei ole harvad juhud, kus küberkurjategijatel õnnestub andmebaasidest kätte saada paroolide krüpteeritud räsi, mille abil veebiteenused paroolide õigsust kontrollivad.

Räsi leidmise algoritm peab olema ühesuunaline - see tähendab, et räsidest paroole tuletada on praktiliselt võimatu, kuid paroolist räsi tuletada on suhteliselt lihtne. Ründaja hakkab pärast edukat räside kättesaamist suurel kiirusel katsetama erinevaid paroole. Tänapäevasel lauaarvutil kulub http://www.passwordstrengthcalculator.org/index.php andmetel 8 kohalise salasõna (mis sisaldab väike- ja suurtähti ning numbreid) ära arvamiseks umbes 44 sekundit.

Näpunäiteid turvalise parooli loomiseks

Kuidas siis ikkagi luua turvaline parool, mis samas ka suhteliselt kergesti meeles püsiks? Mõned ideed meeldejääva parooli loomiseks:

1. Pikkus - mida pikem, seda parem, seega oleks kasulik sisestada salasõna asemel salalause, mis võiks sisaldada ka kirjavahemärke ning numbreid. Näiteks “Eile lõunaks sõin 2 õuna, 2 pirni ja ühe porgandi.” ära arvamiseks kuluks https://howsecureismypassword.net/ andmetel enam kui 10^60 aastat. Üldiselt tasuks kasutada vähemalt 12 märgi pikkuseid paroole.
2. Lisa suvalisi sümboleid keset parooli. Näiteks “va#alaskala”, “ka^namu?na”, “lauala~mp”
3. Kasuta suurtähti salasõna keskel. Näiteks “tuRvaline?paRool”, “salaJANEsõna”
4. Ainult endale arusaadav lühend pikemast lausest. Näiteks lausest “Küll on hea, kui õues on rohkem kui 0 kraadi” saab lühendi “Koh,kõ=rk0k.” ja lausest “Ruudulisel särgil on 2 varrukat ja 7 nööpi.” saab lühendi “#lisels=2v&7n”.
5. Slängi, erinevate keelte ja kirjavigade oskuslik kasutamine muudab paroole raskemini arvatavateks. Näiteks “Täiega tshill on 30-kraadises kontoris tšättida” või “Tavai, kus on tshekk-in nr7?”

Erinevate paroolide haldamine

Turvalisest paroolist üksi on aga vähe abi, kui sama parooli kasutada erinevates kohtades, sest nii on suur tõenäosus, et keegi kuskilt mõne salasõna kätte saab või ära arvab ning proovib leitud parooli ka teiste teenuste puhul. Kindlasti peavad unikaalse salasõnaga olema Sinu peamised meilikontod (tavaliselt üks tööga seonduv ning teine eraotstarbeline). Sotsiaalmeedia ja teised süsteemid, kus leidub olulisel määral isiklikku infot võiksid samuti olla omanäolise salasõnaga ning soovitatavalt ka mitmeastmeliselt turvatud. Vähemoluliste lehtedega võib kasutada mõnda järgnevatest strateegiatest:

1. Kasutada paroolihaldurit (nt KeePass või LastPass), mis oskavad ise turvalisi paroole luua ja meeles pidada. Paroolihalduri kasutamisel tuleks kindlasti valida unikaalne ja võimalikult turvaline üldparool.
2. Kasutada osade lehtede puhul kattuvat osa salasõnas ja lisada täiendeid vastavalt leheküljele. Näiteks võtame kattuvaks osaks eelnevalt pakutud “#lisels=2v&7n” ja lisame sellele Wordpressi jaoks “wordpr-S” ja Twitteri jaoks “twitt-R”. Lisades veel keskele @-märgi, saame salasõnadeks vastavalt “#lisels=2v&7n@wordpr-S” ja “#lisels=2v&7n@twitt-R”. Loodud salasõnu saab ka mõnes tekstifailis salvestada näiteks kujul “{*}wordpr-S” ja “{*}twitt-R” ning see on märksa turvalisem kui nende täielikul kujul hoiustamine oma virtuaalsete dokumentide hulgas või klaviatuuri alla peidetud märkmepaberil.

Ükskõik kui keerulisest paroolist on vähe kasu, kui ründajal õnnestub kuidagi klahvivajutusi või krüpteerimata võrguliiklust pealt kuulata või oskab veenvalt kasutajalt otse küsides vajaliku info kätte saada. Samuti tasub hoolikalt läbi mõelda turvaküsimused, mis esitatakse juhul, kui parool on ununenud. Kui vastus turvaküsimusele on triviaalne, siis on ründajal võimalik hoopis sealtkaudu kontole ligi pääseda. Paljud teenused saadavad parooli ununemise korral e-maili salasõna uuesti seadmiseks vajaliku viitega. Seega võimaldab ligipääs peamisele meilikontole muuta ära ka mitmeid teisi salasõnu. Seetõttu on lisaks tugevatele paroolidele äärmiselt soovitatav kasutada võimaluse korral mitmeastmelist autentimist näiteks ID-kaardi või mobiili abil.

Sten Mäses
ASA Quality Services

BugFever Kivimäe Põhikoolis

ASA Akadeemia käis 4. märtsil külas Kivimäe Põhikoolis, kus tutvustasime kaheksandale klassile tarkvara testimise kirevat maailma.

BugFeveri formaat näeb ette kolme komponenti:

• Tarkvara või süsteem, mida testitakse.
• Osalejad, kes tahavad testimist õppida ja praktiseerida.
• Väike teoreetiline ettevalmistus, mida praktikasse rakendada. 

Testimishuvilisteks olid kaheksanda klassi õpilased, kes, tuleb tunnistada, ei ole just ASA koolituste tavapärane sihtrühm. Seetõttu pidin olema tavalisest oluliselt ettevaatlikum igasuguste spetsiifiliste väljendite kasutamisega – ekvivalentsiklass, kompilaator, operatsioonisüsteem, spetsifikatsioon... Kuid väike teoreetiline ülevaade sellest, kuidas üldse tarkvara tehakse, miks vead on halvad ja kuidas neid raporteerida, on ju kindlasti vajalik. Kuidas seletada kaheksanda klassi õpilastele tarkvaraarenduse ja testimise põhitõdesid? Sellest saad täpsemalt lugeda siit.

Kindluse mõttes tegime pärast rollide tutvustust ka väikese hääletuse – kes õpilastest tahaksid olla pigem analüütikud, kes programmeerijad, kes testijad ja kes projektijuhid? Kõigisse rollidesse leidusid mõned huviliseid, kuid testijaks soovijaid oli kõige rohkem :).

Nüüd, kui tarkvara tegemine oli üldjoontes selgeks saanud, võisime asuda testimisega lähemalt tutvuma. Küsisin õpilaste käest, kas nad on kunagi mõne tarkvaravea otsa „koperdanud“. Tuli välja, et kõigil oli kunagi vähemasti „arvuti kokku jooksnud“ , ja kõik tunnistasid, et sellised apsakad on väga ebamugavad. Tarkvaravead ongi ebamugavad. Mõelda vaid, kui tahad saata e-kirja sõbrannale, aga tarkvaravea tõttu läheb see hoopis sinu emale... Rääkimata siis sellest, kui palju raha on sõna otseses mõttes „vastu taevast“ läinud näiteks kosmosetööstuses, kus nii mõnigi kallihinnaline kosmosetehnika on tarkvaravigade tõttu hävinenud.

Huvitav statistika on võib-olla seegi, et hinnangulised iga-aastased tarkvararavigade kahjud USAs [1] on umbes 6 korda suuremad kui Eesti riigi tulud 2013. aastal [2]. Niisiis on testimine üks vajalik tegevus, et vead üles leida enne, kui mõni kosmoserakett õhku lendab, lennuk alla kukub või arvuti kokku jookseb.

Kuidas testida?

Nagu juba varem öeldud – pane testitav tarkvara igasugustesse olukordadesse, mida vähegi suudad välja mõelda. Kindlasti proovi teha ka selliseid tegevusi, mida „ükski normaalne inimene kunagi ei tee“. Sellepärast, et tegijal juhtub nii mõndagi, ka selliseid asju, mida ei tohiks. Samuti võib vigade ilmnemine sõltuda sellest, missugust arvutit, tahvelarvutit, telefoni,  brauserit, ID-kaardi lugejat ja muid seadmeid sa testimisel kasutad. Ka keskmisest pikemad ning täpitähti ja sidekriipsu sisaldavad nimed on head testimisel kasutamiseks. Kui mõni väli on märgitud aga täitmisel kohustuslikuks, siis õige testija kontrollib alati järele, mis juhtub siis, kui see tühjaks jätta.

Tihti juhtubki nii, et mõni funktsionaalsus ei tööta. Siis peab testija kirja panema, mis siis ikka täpselt ei tööta, sest ega testija ise ühtegi viga ei paranda, seda teeb programmeerija. Vigade raporteerimine on ka paras kunst, aga kui meeles pidada lihtsaid reegleid, siis on see tegelikult päris lihtne:

• Pane oma bugile lühike kokkuvõtlik nimi, näiteks „Firefoxiga ID kaardiga sisselogimine ei õnnestu“.
• Kirjelda putukat nii, et ka teised (näiteks programmeerijad) selle ära tunneksid ja üles leiaksid – soovitavalt sammude kaupa.
• Kirjelda keskkonda, kus putukas „elab“ – missuguse operatsioonisüsteemi, brauseriga viga avaldus.
• Kirjelda, kui „mürgine“ see putukas on – kas surmav, või lihtsalt tüütu kõrva ääres piniseja. 

Ega hea testija ei ole see, kes ainult palju vigu leiab. Testimata tarkvara ja testitud tarkvara on täpselt sama head (halvad), sest ainult testimine ei tee tarkvara paremaks. Hea testija on see, kes annab teistele osapooltele (programmeerija, projektijuht, analüütik) võimalikult kvaliteetset infot tarkvara paremaks tegemiseks.

Pärast teooria selgitamist jagasime ülesanded kätte ning kõik grupid mõtlesid esmalt välja, missugustes olukordades nad oma tarkvarasid proovile panevad, ning siis läks juba testimiseks. Testisime näiteks Facebooki, Gmaili ja Forumcinemas kinokavasid. Lõppkokkuvõttes leidis iga grupp midagi, mis korralikult ei töötanud või võiks olla paremini arusaadav.

Pean kaheksandikke kiitma – võrreldes näiteks ülikooli IT tudengitega, kes on juba mõned aastad õppinud tarkvara arendamist, olid kaheksandikud palju avatuma suhtumisega testimisse. Ülikooliõpilastel on miskipärast juba päris tugevalt juurdunud mõtteviis: „ainult nõrgad teevad vigu“, „ega ükski normaalne inimene nii ju ei kasuta seda süsteemi“, „seda pole vaja kontrollida“ jne. See paneb mind mõtlema, mis „juhtuks“ siis, kui testimise baaskursus oleks noortele IT-inimestele kohustuslik aine esimesel õppeaastal?

Minu jaoks oli see kindlasti huvitav ja teistmoodi kogemus, kus sõnade ja näidetega pidi väga ettevaatlikult ümber käima, kuna minu ja kuulajate taustsüsteemid on väga erinevad. Loodan, et mõne osalejaga kohtun ka mõne aasta pärast ülikoolis ja võib-olla kunagi hiljem tööl.

Lõpetuseks ka üks tagasiside üritusel osalenud õpilaselt:

„Koolis toimunud arvuti tund. Minu arust oli see üritus väga tore ja põnev. Sain teada seal uusi asju tegeliku interneti maailma kohta. See andis mulle infot olla hoolikam internetis. Kõik, mis me seal õppisime, oli uus ja huvitav, igav ei hakanud. Meie grupil õnnestus päris hästi testimine, minu arust. Ühesõnaga see oli väga tore üritus!“

Maili Markvardt
ASA Quality Academy

Maili on Eesti Testijate Liidu asutajaliige ja kuulub ka ETLi juhatusse. Ühtlasi õpetab ta tarkvara kvaliteediteemasid Tallinna Tehnikaülikoolis ja Eesti Infotehnoloogia Kolledžis. "Testimine ei ole elukutse, testimine on elustiil!"

Kuidas seletada tarkvaraarendust 15-aastastele?

Tarkvara on tänapäeval kõikjal meie ümber: juba algkooliõpilased teavad ja on mänginud arvutimänge ning kasutanud nutitelefoni app’e. Kõik need suuremad ja väiksemad programmikesed kokku võetavad üldise mõiste tarkvara alla ning nende loomine ongi tarkvaraarendus.

Nagu maja ehitamisel ei piisa ainult müüriladujatest, on ka tarkvara loomisel vajalikud erinevad rollid. Kõige tähtsamad on tarkvara kasutajad – neist ja nende soovidest ja vajadustest algab kogu tarkvaraarendus, ja nende juures see ka lõpeb – valmis tarkvaraga. Tarkvaraarenduse ülimaks eesmärgiks on teha kasutaja õnnelikuks ja rahulolevaks :). Analüütik on see inimene, kes kogub kokku, mõtleb läbi ja paneb ilusasti kirja kõik selle, mida kasutajatele õnneks vaja oleks. Analüütikut tunned muuhulgas selle järgi, et talle meeldib teisi kuulata, infot süstematiseerida ja ka on ta väga hea kirjandite kirjutamisel.

Edasi läheb analüütiku kirjutatud „kirjand“ (ehk nõuded loodavale tarkvarale) programmeerija kätte. Tema on see, kes tarkvara tegelikult valmis programmeerib. Head programmeerijat iseloomustab vaimustumine tehnoloogiast ja uute oskuste õppimisest, aga samas ei pea ta olema tihti tähelepanu keskmes, vaid saab päris hästi hakkama ka siis, kui ainult analüütiku ning lähemate kolleegidega suhtleb.

Kui programmeerija on tarkvara enda meelest valmis saanud, siis tuleb mängu testija, kes seda kontrollib ja igakülgselt proovile paneb. Testija hea omadus on see, et ta ei pea mõtlema nagu kõik teised, vaid peabki mõtlema „kastist väljas“, ja ühtegi eksperimenti ei saa testijale pahaks panna. Testija on nagu detektiiv või varanduseotsija – hüljatud lossi on peidetud teadmata arv aardeid, ning testija ülesandeks on need kõik üles otsida. Mida kavalam, tähelepanelikum ja järjekindlam ta on, seda rohkem aardeid ta üles leiab. Tarkvara testimisel on aarded muidugi vead tarkvaras ehk bugid.

Kui kõik bugid on üles otsitud ja ära parandatud, siis jõuab tarkvara oma lõppkasutajateni, kes loodetavasti on õnnelikud :).

Aga ega koostöö alati ei suju ja suuremad ja väiksemad takistused on elu tavapärane osa... seega on veel üks oluline roll tarvis ära rääkida – projektijuht loomulikult. Projektijuht ise ei tee suurt midagi (ei kirjuta nõudeid ega koodi ja ka ei testi, kas tuli hea välja), aga ometigi on ta vajalik, et projekt püsiks ajakavas ja komplikatsioonide korral oleks kõigil selge, kuidas edasi toimida.

Kui sul on kunagi vaja 15-aastastele tarkvaraarenduse alustalasid selgitada, võid eeltoodut julgelt kasutada. Lähenemine on testitud ja töötas.

Kui aga tundub, et tahaks vastu vaielda või täiendada, kasuta siinsamas postituse all olevat kommenteerimiskasti. Me ei hammusta! :)

Maili Markvardt
ASA Quality Academy

Maili on Eesti Testijate Liidu asutajaliige ja kuulub ka ETLi juhatusse. Ühtlasi õpetab ta tarkvara kvaliteediteemasid Tallinna Tehnikaülikoolis ja Eesti Infotehnoloogia Kolledžis. "Testimine ei ole elukutse, testimine on elustiil!"

Mitmeastmeline enesetuvastus on abiks virtuaalidentiteedi varguse vältimisel

Virtuaalmaailmas enese tuvastamine on muutunud igapäevaelu lahutamatuks osaks. Nii elektronposti lugemiseks, sotsiaalmeedias piltide jagamiseks kui ka pangas ülekannete sooritamiseks on vaja eelnevalt kasutaja isiku identsust kontrollida. Kasutaja tuvastamiseks kõige levinum viis on küsida kasutajanime ja parooli. Internetipanka sisenemiseks on lisaks enda peas asuvale infole tarvis veel näiteks ID-kaarti. Viimasel juhul on tegu juba kaheastmelise kasutajatuvastusega. Kasutaja isiku kindlaks tegemiseks ehk autentimiseks rakendatavaid viise on erinevaid, aga laias laastus jagunevad need kolmeks: 

1.    miski, mida ma tean (salasõna, isikukood, sünniaasta jne),

2.    miski, mis mul füüsiliselt olemas on (mobiil, ID-kaart, PIN-kalkulaator),

3.    miski, mis ma olen (sõrmejälg, kõnemuster, DNA ja muud biomeetrilised andmed).

Kahe või rohkema salasõna või kontrollküsimuse esitamine süsteemi sisse logimiseks ei tähenda, et tegu on mitmetasemelise kasutajatuvastusega, sest kontrollitakse ainult kasutaja teadmisi. Sagenevate küberkuritegude tõkestamiseks on lisaks pankadele ka mitmed teised suurkorporatsioonid võtnud kasutusele kaheastmelise kasutajatuvastuse.

Mitmeastmelist kasutajatuvastust kasutavad nii Amazoni lendavad robotkullerid kui ka koolibussid, kus silmamustri järgi inimesi ära tuntakse, kuid mis tulu on sellest tavalisele arvutikasutajale? Eks peamine kasu on levinud küberrünnetega kaasnevate riskide vähendamine. Hoiatavaid näiteid kasutajakonto kaaperdamisest leidub meedias mitmeid (nt Ringvaates ja Postimehes). Oma virtuaalsest identiteedist ilma jäämine võib olla äärmiselt ebameeldiv. Kahju ennetamiseks on igati soovituslik kohe praegu kontrollida, et vähemalt sinu kõige olulisemad virtuaalkontod oleks mitmeastmeliselt kaitstud. 

Enamik tuntud veebigigandid (nt Google, Facebook, Microsoft, Apple, Twitter, Yahoo, Dropbox, Linkedin...) pakuvad võimalust mobiiltelefoni kasutades kasutajatuvastust turvalisemaks muuta. Nimelt saadetakse mobiilile (üldreeglina tasuta) sõnum numbrijadaga, mis süsteemi sisse logimisel tuleb sisestada. Häkkeril ei piisa seega enam õige kasutajanime ja parooli välja nuhkimisest, vaid tal on vaja ligi pääseda ka kontoga seotud mobiiltelefonile. Mobiiltelefoni hoitakse aga tavaliselt enda lähedal ning selle märkamatu kuritarvitamine kaheastmelise kasutajatuvastuse kasutamiseks on märksa ebatõenäolisem kui salamisi kasutajanime ja parooli välja nuhkimine.

Kuidas aga mitmeastmelist kasutajatuvastust kasutama hakata? Kõigepealt tuleb vastaval lehel harjumuspäraselt kasutajanime ja parooliga sisse logida ning seejärel seadetest või eelistustest õige koht üles otsida.

Google (Gmail, Blogger, YouTube...):  https://www.google.com/intl/et/landing/2step/

Microsoft (Outlook.com, Skype, Xbox): https://account.live.com/ProofsManage

Facebook: https://www.facebook.com/settings?tab=security

Erinevate õpetuste leidmiseks saab teha otsimootorist vastavasisuline päringu, näiteks “Dropbox 2-step verification”.

Alguses võib küll tunduda harjumatu ja pisut tülikas lisaks kasutajanime ja parooli sisestamisele iga kord mobiilist kinnituskoodi otsida, kuid parem karta kui kahetseda. Mugavusesõprade lohutuseks võib mainida, et Google’i ostetud  SlickLogin tehnoloogia annab lootust, et peatselt muutub mitmeastmeline kasutajatuvastus märksa käepärasemaks. Kuniks uudseid lahendusi veel (p)arendatakse ja testitakse, tasub võimaluse korral kindlasti oma virtuaalset identiteeti kaitsta juba praegu pakutavate kahetasemeliste kasutajatuvastusviiside abil.

Sten Mäses
ASA Quality Services



Silmaskännerit kujutava foto allikas: GYSGT MICHAEL Q. RETANA, http://en.wikipedia.org/wiki/File:USMC_Sergeant_identifies_Baghdaddi_city_council_member_with_iris_scanner.jpg