7 Testimistulemuste esitlemine

Testimise tulemuste esitlemiseks on võimalik kasutada mitut erinevat lähenemist, mis sõltub sellest mida soovitakse täpselt esitleda:

• kui soovitakse raporteerida testimise tulemust ühe kitsa funktsionaalsuse testimise kohta, kasutatakse selleks testlugu sellisel kujul nagu käsitletud juba eelmistes peatükkides;
• kui testimise tulemusel on leitud viga, siis kasutatakse sellest bugi raporteerimist ja selle parandamise jälgimist;
• kui on vajalik anda ülevaade kogu süsteemi seisukorrast, kasutatakse testraporti kirjutamist.

Bugide jälgimine

Ehkki testimise ülimaks eesmärgiks on süsteemi kvaliteedi tagamine, ei paranda aga testimine iseenesest vigade leidmise puhul süsteemi kvaliteeti, vaid selleks tuleb testimise tulemustest raporteerida arendajatele leitud vigadest ehk bugidest, mille raporteerimist käsitlesime juba eelmises peatükis.

Lisaks bugi raporteerimisele, on aga testija kohustuseks jälgida, kas bugi on arendaja poolt käsile võetud ja korrektselt parandatud või mitte. Selle jaoks kasutatakse tarkvaraarenduses erinevaid board’e ehk tahvleid, mis on jaotatud tulpadesse, kus iga tulp tähistab erinevat arendusele püstitatud ülesande või bugi olekut. Antud tahvel sisaldab kõikide arendusülesannete ja bugide pealkirjadega kaarte, mida liigutatakse alates vasakust tulbast edasi paremale iga kord, kui sellega midagi tehakse. Ehkki selliste tahvlite struktuur võib erineda sõltuvalt valitud tarkvara arendamise lähenemisest, sisaldavad need reeglina alati vähemalt järgnevaid tulpasid alates vasakult:

• To do ehk alustamata;
  • • Siia paigutatakse testijate poolt kõik avastatud bugid, mis tuleb lahendada ja analüütiku poolt arendusülesanded, mis tuleb lahendada. See on alati esimene ehk vasakpoolseim tulp.
• Doing või In Progress ehk praegu käsil;
  • • Kui arendaja alustab bugi või arendusülesande lahendamist, liigutab ta vastava bugi või arendusülesande kaardi “Alustamata” tulbast “Praegu käsil” tulpa, et kogu meeskonnal oleks teada, mis parasjagu töös on.
• Test ehk testimisel;
  • • Peale arendusülesande lõpetamist või bugi lahendamist, liigutatakse vastav kaart edasi “Testimisel” tulpa. Sellega antakse märku anda testijale, et võib alustada selle testimist. Ka kõik raporteeritud bugid, mis arendaja on parandanud, peab testija üle vaatama.
• Done ehk tehtud;
  • Kui testija parandatud bugi või lahendatud arendusülesande puhul vigu ei leia, liigutab ta vastava kaardi “Tehtud” tulpa.

Lahendusi selliste tahvlite loomiseks on mitu. Kõige lihtsam lahendus on joonistada markeri või kriidiga sobivad tulbad füüsilise tahvli peale ja kasutada märkmepabereid, millele on võimalik kirjutada bugi või arendusülesande pealkiri. Valdavalt kasutatakse aga tarkvaraarenduses süsteeme, milles sisaldub ka sarnane tahvel digitaalsel kujul, näiteks Trello, JIRA või TFS.

Testraporti kirjutamine

Vahel on aga vajalik testimise tulemustest raporteerida ka näiteks rakenduse tellinud kliendile, et anda ülevaade ning kindlustada kliendile enne süsteemi üle andmist, et seda on põhjalikult testitud ning see vastab kliendi poolt nõutud vajadustele.

Selleks, et anda kogu süsteemi testimisest ja selle tulemustest lihtsasti loetav, kuid põhjalik ülevaade, koostavad testijad testraporteid. Testraport on dokument, kus kirjeldatakse testimisel tehtud tegevused, märgitakse ära testimisel leitud vigade hulk ja antakse hinnang, kas testitud süsteem on sobiv, et see anda kasutajatele edasi kasutamiseks. Kogu süsteemi testimist kokkuvõttev testraport koosneb tüüpiliselt järgnevatest peatükkidest:

• Süsteemi kirjeldus
• Testimise skoop ehk piirid
• Testimise tulemused numbrite kujul
• Kasutatud testimise liigid
• Testimisel kasutatud keskkond ja tööriistad
• Ettepanekud
• Hinnang ja kokkuvõte

Süsteemi kirjeldus

Selleks, et testraporti lugejale oleks selle lugemine lihtne ja mõistetav, tuleb testraportis anda lühikese kirjeldusega ülevaade süsteemist, mida testiti. See aitab paremini testimise sisu mõista ka neil, kellel on vaid vähene kokkupuude testitud süsteemiga.

Testimise skoop

Testimise skoobi peatükis kirjeldab testija süsteemi osad, mis kuulusid testimisele ja toob eriliselt välja ka süsteemi osad ja funktsionaalsused, millele testija testimise käigus ei keskendunud.

Näide eKooli põhjal:

Testimise skoop sisaldas järgnevaid õpetaja rollis kasutatavaid süsteemi osasid: 

• märkuste sisestamine ja vaatamine
• hinnete sisestamine ja vaatamine
• tunniplaani vaatamine
• kohalolijate märkimine
• salasõna, mobiil-ID, smart-ID, HarID abil sisselogimine

Testimise skoopi ei kuulunud:

• õpilase rollis kasutaja funktsionaalsused
• pangalingi ja ID-kaardi abil sisselogimine

Testimise tulemused

Testimise tulemuste peatükis annab testija ülevaate testimise protsessi tulemustest, tuues need välja tabelite või graafikute kujul, et lihtsustada testraporti lugeja jaoks nende andmete loetavust ja nende mõistmist. Andmed, mida välja tuuakse on järgnevad:

1. testlugude õnnestumsie osakaal ehk mitu testlugu õnnestus läbida ilma vigadeta ja mitme testloo puhul esines vigu;
2. vigade hulk, kriitilisus ja olek ehk mitu viga testimisel avastati, kui kriitilise tasemega olid leitud vead ja mis olekus (parandatud/parandamata) need vead testraporti kirjutamise hetkel on;
3. vigade osakaal süsteemi osade kaupa ehk kui palju vigu esines erinevates süsteemi osades/funktsionaalsustes.

1. Testlugude õnnestumise osakaal

Selleks, et anda ülevaade, kui suur hulk testlugusid õnnestub läbida vigadeta ja mitmes testloos esines viga, kasutatakse reeglina tabeleid ja graafikuid, kus tuuakse välja:

• vigadeta õnnestunud testlugude osakaal;
• vigadega õnnestunud testlugude osakaal, milles esines väike viga, mis ei takistanud testloo sammude lõppu jõudmist;
• ebaõnnestunud testlugude osakaal, milles esines selline viga, mis takistas testloo sammude lõppu jõudmist.

Näide:

2. Vigade hulk, kriitilisus ja olek

Kui testija leiab testimisel vigu ehk bugisid, määrab ta neile ka kriitilisuse taseme. Iga testija võib sõnastada endale sobivad kriitilisuse tasemed, ent sageli on need jaotatud neljaks:

• Kriitiline – sellele tasemele märgitakse leitud bugid, mis takistavad kas kogu süsteemi või suure hulga süsteemi funktsionaalsuste kasutamist. Kriitiliseks veaks saab pidada näiteks seda, kui veebileht või rakendus ei avane ja seda pole võimalik kasutada.
  • Lisaks võib eKooli puhul pidada kriitiliseks veaks ka seda, kui süsteemi ei õnnestu sisse logida, mis takistab valdava enamuse eKooli funktsionaalsuste kasutamist.
• Tõsine – antud tasemega märgitakse bugid, mis takistavad mõne kindla testloo läbimist või funktsionaalsuse kasutamist, aga suurem osa süsteemi funkstionaalsustest töötab.
  • Tuues taas näiteks eKooli, võib selle puhul tõsiseks veaks pidada olukorda, kui õpetajal ebaõnnestub hinnete lisamise funktsionaalsus.
• Väike – sellise tasemega tähistatakse bugid, mille puhul on testijal võimalik testloo viimase sammuni jõuda ning testlugu üldplaanis lõpetada, kuid ebaõnnestus mõne sammu lisamine, mis lõpptulemust oluliselt ei mõjutanud.
  • Kasutades näitena eKooli, võib väikese tasemega veaks pidada seda, kui süsteem ei lase õpetajal märkuse lisamisel kasutada numbreid. Kuna numbreid on võimalik kirjutada ka sõnadega, on võimalik märkuse lisamise testlugu lõpetada ka ilma numbreid kasutamata.
• Kosmeetiline – kosmeetilisteks vigadeks saab pidada selliseid vigu, mis ei mõjuta süsteemi funktsionaalsuste kasutamist, kuid mis võivad kasutajat häirida, nagu näiteks vead rakenduse disaini või kasutusmugavusega seoses.
  • eKooli näite puhul võib kosmeetiliseks veaks pidada seda, kui hinnete tabelis on numbrid kujutatud liiga väikese teksti suurusega, mistõttu on neid keeruline lugeda.

Näide:

Lisaks vigade kriitilisusele saab testraportis välja tuua ka kõikide erineva kriitilisuse tasemega vigade oleku, kui arendajad on jõudnud peale testimist ja enne testraporti koostamist juba mõned vead ära parandada. Sellisel juhul kasutatakse järgmise kujuga tabelit:

3. Vigade osakaal süsteemi osade kaupa

Viimasena on võimalik testimise tulemustena välja tuua ka andmed selle kohta, millistes süsteemi osades testimisel leitud vead esinesid. Neid andmeid on lihtne kujutada näiteks järgmise graafikuna, kasutades näitena väljamõeldud eKooli:

Testimise liigid

Antud peatükis kirjeldab testija rakendatud testimise liike koos põhjendustega, miks kasutati sellist lähenemist ja mida valitud testimise liiki kasutades on võimalik antud süsteemi puhul testida.

Näide:

Funktsionaalne testimine: testimisel kasutati funktsionaalset testimist, millega saab kontrollida süsteemis kasutajatele kättesaadavaid tegevusi kasutaja vaatenurgast läbi kasutajaliidese, et tagada kõikide kliendi poolt esitatud funktsionaalsete nõuete täitmine ja kasutajale ligipääsetavate funktsionaalsuste töötamine.

Jõudlustestimine: antud testimise liiki rakendati vormide salvestamisel, et kontrollida süsteemis andmete salvestamise kiirust ja selle vastavust kliendi poolt esitatud mittefunktsionaalsetele nõuetele.

Testimisel kasutatud keskkond ja tööriistad

Tarkvaraarenduses on reeglina testijatel võimalik kasutada mitut erinevat keskkonda, kus arendajate loodud süsteemi on võimalik testida enne, kui süsteemi uus versioon kasutajatele mõeldud ehk live keskkonnas kättesaadavaks tehakse. Selleks, et oleks teada, millises keskkonnas testimine läbi viidi, tuleb see kirjeldada ka testraportis. Nii testimisel kasutatud keskkond kui ka kasutatud tööriistad on võimalik kujutada näiteks järgneva tabelina:

Ettepanekud

Testijal on võimalus testraportisse märkida ka omapoolsed parandusettepanekud seoses testimisel silma jäänud kosmeetilise tasemega vigadega või teha märkuseid seoses süsteemi kasutusmugavusega.

Hinnang ja kokkuvõte

Viimasena märgib testija testraportisse koos kokkuvõttega oma hinnangu testimise tulemustele, tuues pikemalt välja kriitilised või tõsised vead, mis vajavad parandamist enne, kui süsteemi versiooni võib paigaldada kasutajatele kättesaadavasse keskkonda. Kui selliseid vigu ei esine, annab testija positiivse hinnangu ja oma kinnituse.

Rühmatöö

1. Koostage 3 kuni 5 testlugu erinevate YouTube’i funktsionaalsuste kasutamise kohta. Kasutage juhiseid peatükist “Tarkvara testimise alused”. NB! Kuna YouTube on live-keskkonnas ligipääsetav rakendus, siis võite kirjutada ka sihilikult ebaõnnestuvaid testlugusid.
2. Testige antud funktsionaalsuseid koostatud testlugude ja seal kirjeldatud sammude alusel.
3. Kirjutage üles kõik leitud bugid: kriitilised, tõsised, väikesed ja ka kosmeetilised.
4. Kasutades tekstiredaktorit (MS Word, Paper, Google Docs), koostage läbi viidud testimise kohta testraporti tulemuste peatükk koos graafikutega järgnevate andmete kohta:
   1. Vigadeta õnnestunud, vigadega õnnestunud ja ebaõnnestunud testlood
   2. Vigade hulk ja kriitilisuse tase