5 Tarkvara testimise alused

Oleme nüüdseks tuvastanud, millega testija üldiselt tegeleb ja miks testimine on oluline nii tarkvaraarenduses kui ka kõikide teiste toodete arendamise puhul – et saavutada kõikidele ootustele ja nõuetele vastav süsteem või toode. Järgnevalt tutvume aga lähemalt sellega, milliseid erinevaid meetodeid on võimalik tarkvara testimisel kasutada ning millistel erinevatel tasemetel on tarkvara testimist võimalik teha. Eelmises peatükis tutvusime juba lühidalt funktsionaalse ja mittefunktsionaalse testimisega. Testimist on aga võimalik liigitada väga mitmel erineval viisil:

• testija vaatenurga alusel;
• testitava objekti või sihtmärgi alusel;
• testitava osa taseme alusel;
• selle alusel, kas testimist viib läbi inimene või programm.

“Musta kasti” testimine vs “Valge kasti” testimine

Testimise liike on võimalik nn musta ja valgesse kasti jagada selle alusel, millist vaatenurka omab testija. Kui testitakse kasutaja vaatenurgast ehk teadmata programmi koodi sisu ja struktuuri, on tegemist musta kasti testimisega. Kui aga testija tegeleb ka programmi koodi lugemisega, et esmalt tuvastada koodi abil kõik lubatud ja võimalikud tegevused süsteemis, on tegemist valge kasti testimisega ehk klaaskasti testimisega.

Musta kasti testimiseks ei ole testijal vaja programmeerimise ega koodi lugemise oskust ja seda tehakse valdavalt kasutades programmi kasutajaliidest ehk kasutajale nähtavat süsteemi osa. Testija avab süsteemi nii nagu ka kasutaja seda teeks ning katsetab erinevaid süsteemi tegevusi ning omadusi. Kasutajaliides on näiteks kõikidel veebilehtedel – nagu näiteks Facebook, Google ja ka e-õpikul, mida praegu loed. Käesolevas kursuses keskendumegi peamiselt musta kasti testimisele.

Valge kasti ehk klaaskasti testimise puhul on vaatenurgaks süsteemi looja vaatenurk ja on vajalik ka programmeerimise või vähemalt koodi lugemise oskus, et aru saada, millised reeglid, piirangud ja tegevused on koodi sisse kirjutatud. Valge kasti testimise eeliseks on see, et testijal ei ole vaja kasutada kasutajaliidest, mistõttu saab testimist alustada arendusprotsessis ajaliselt varem, enne kui disainerid ja arendajad on süsteemile loonud kasutajaliidese. Testija saab otse koodi lisada sisendeid ehk näiteks teksti, mida kasutajaliideses saab sisestada tekstiväljale, ning jälgida tulemust samuti otse koodis.

Testimise liigid sihtmärkide alusel

Lisaks on võimalik testimist liigitada ka testitavate sihtmärkide alusel. Eelmises peatükis käsitletud funktsionaalne ja mittefunktsionaalne testimine kuuluvad selle liigituse alla – esimese puhul on sihtmärgiks funktsionaalsed nõuded ehk süsteemis võimalikud tegevused (funktsionaalsused) ja teise puhul on sihtmärgiks mittefunktsionaalsed nõuded ehk süsteemi omadused.

Testimise sihtmärgiks võib lisaks olla ka üks järgnevatest:

• Süsteemi turvalisus (turvatestimine) ehk kas süsteem peab vastu küberrünnakutele ja pahatahtlikele kasutajatele
• Süsteemi jõudlus (jõudlustest) ehk kas süsteemi ja selles toimetamise kiirus vastab ootustele
• Süsteemi toimimine suure koormuse all (koormustest) ehk kas süsteem töötab ootustele vastavalt ka suure kasutajate arvu või andmemahu puhul

Kasutatavuse testimine

Üheks testimise sihtmärgiks võib lisaks olla ka kasutatavuse testimine, millega veendutakse, kas kõik süsteemi tegevused on kergelt leitavad ja kasutatavad ning kas süsteemi kasutamine on üleüldiselt mugav. Kasutatavuse testimist on võimalik läbi viia mitmel erineval moel. Näiteks on üheks eelistatuimaks lahenduseks luua stsenaariumid, mille alusel antakse süsteem inimestele kasutamiseks ning jälgitakse, kuidas nad stsenaariumis kirjeldatud tegevustega hakkama saavad. Sageli aga ei ole võimalik selliseks testimiseks kasutajaid leida, mistõttu kasutatakse ka kasutatavuse heuristikute ehk üldtuntud reeglite järgi kasutatavuse kontrollimist. Antud reegleid on 10 ja need on kujutatud järgnevatel kaartidel, kus iga kaardi pöördel on kirjeldatud nende tähendus.

Testimise tasemed

Lisaks sellele, et testijatel on võimalik testida erinevaid sihtmärke, nagu funktsionaalsused, turvalisus ja kasutatavus, saab jaotada testimist ka selle alusel, millist süsteemi taset parajasti testitakse. Kõige madalamal tasemel testimiseks peetakse ühiktestimist (ehk unit testing), kus tehakse testid süsteemi väikseimatele osadele – näiteks ühele kindlale funktsioonile, mis mõne e-poe puhul võiks olla näiteks sisselogimine. Järgmine testimise tase on integratsioonitestimine, millega testitakse erinevate süsteemi osade vahelisi seoseid ja kuidas need osad teineteist mõjutavad. Kasutades taas e-poe näidet, kus üheks osaks on sisselogimine ja teiseks võib olla ostukorv, siis integratsioonitestimise abil on võimalik tuvastada näiteks seda, kas sisselogimides jäid enne sisselogimist ostukorvi lisatud asjad alles või mitte. Nii ühikteste kui ka integratsiooniteste tehakse tavaliselt automaattestidena. Kõrgeimal testimise tasemel ehk süsteemitestimisel keskendutakse kogu süsteemi testimisele, et tagada kõikide süsteemi nõuete täitmine.

Automaattestimine

Arendusprojektides loodavad süsteemid võivad kujuneda väga suureks, mistõttu võtab nende testimine palju aega. Lisaks on oht, et üks väike muudatus suures süsteemis võib tekitada vigu, mis mõjutavad kogu süsteemi toimimist. Selleks, et iga muudatuse järel testija kogu süsteemi käsitsi üle vaatama ei peaks, kasutatakse automaattestimist. Automaattestimise puhul kirjutavad kas arendajad või testijad automaattestimiseks mõeldud rakendust kasutades väikseid programme, mis testivad süsteemis võimalikke tegevusi ja reegleid.

Näiteks on võimalik kirjutada automaattest e-kooli kasutajanime abil sisselogimise kohta. Selleks peab esmalt testija või arendaja märkima automaattesti loomisel ära funktsiooni, mida automaattest kontrollib. Seejärel saab ta ära märkida, mis kasutajanime ja parooli test kasutama peab. Lõpetuseks saab ta ka ära märkida, mis vaate süsteem testis sisselogimise järel peab olema avatud ning kontrollida, kas süsteem tuvastab sisseloginud kasutaja.

Testlood

Selleks, et testija töö oleks sihipärane ja organiseeritud, loovad testijad enne testimist testlood, mida testimisel järgida. Testlugu koosneb reeglina järgnevatest osadest, mis kujutatakse tabeli kujul:

1. Pealkiri ehk mida testitakse;
2. Kirjeldus, kus võimalik märkida, millist keskkonda kasutatakse testimisel ja milliseid vahendeid testimisel kasutatakse;
3. Eeltingimused ehk mis tingimused peavad olema täidetud enne testloo alustamist (näiteks Kasutaja peab olema sisselogitud);
4. Sammud ehk punkthaaval kirjeldatud kasutaja nupuvajutused ja tekstid, mida sisestatakse tekstiväljadele;
5. Oodatud tulemus ehk kirjeldus sellest, mida süsteem antud testloo tulemusel tegema peab (näiteks e-poes kauba lisamisel ostukorvi Kasutaja valitud toode lisati edukalt ostukorvi ja ostukorvi ikoonil kuvatud number suurenes ühe võrra);
6. Tegelik tulemus ehk kuidas süsteem tegelikult käitus testloo läbimise tulemusel (täidetakse peale testloo läbimist testimisel).

Rühmatöö (kasutatavuse testimine ja testlugude kasutamine testimisel)

1. Valige üks järgnevatest süsteemidest: YouTube, Twitter, Facebook. Olge testimisel hoolikad, et mitte teha tegevusi, mida te oma kontoga ei soovi teha. Tavapäraselt tehakse testimist selleks eraldi seadistatud keskkondades, kuid antud juhul kasutate reaalseid infosüsteeme.
2. Valige välja 3 funktsionaalsust või osa süsteemis, mida testida (näiteks sisselogimine, kasutajanime muutmine, unustatud parooli taastamine). Mõned näited iga mainitud süsteemi kohta:
   1. Sisselogimine (kõikides süsteemides)
   2. Video lisamine (YouTube)
   3. Pildi lisamine (Twitter, Facebook)
   4. Kommentaari lisamine või kustutamine (YouTube, Facebook)
   5. Säutsu lisamine (Twitter)
3. Kirjutage nende funktsionaalsuste testimise kohta testlood. Ärge piirduge iga asja testimise juures vaid ühe testlooga – kirjutage ka testlugusid selle kohta, kuidas süsteem peaks toimima, kui funktsionaalsust sihilikult valesti kasutada (nt jätke kohustuslikud vormiväljad tühjaks).
4. Viige läbi testimine, kasutades kirja pandud testlugusid.
5. Pange kirja testimise tulemused.
6. Nüüd viige läbi antud süsteemi kasutatavuse testimine, kasutades selleks peatükis kaartidena kujutatud kümmet kasutatavuse heuristikut ehk reeglit. Pange kirja tulemused.

Kasutatud allikad:

Nielsen Norman Group. (24. aprill, 1994). 10 Usability Heuristics for User Interface Design. https://www.nngroup.com/articles/ten-usability-heuristics/