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!"
Kommentaare ei ole:
Postita kommentaar