Manual QA ametikohale kandideerimisel palutakse töövestluse käigus sageli lahendada väike testülesanne ehk take-home task. Tavaliselt ei oodata kandidaadilt sadu testjuhtumeid ega katset kõiki võimalikke vigu leida. Tööandja soovib näha, kuidas kandidaat analüüsib nõudeid, määrab kindlaks riskid, valib teststsenaariumid ja vormistab oma töö tulemuse.
Selles artiklis vaatleme tüüpilise Manual QA testülesande näidet alates ülesande esmakordsest lugemisest kuni lõpliku lahenduseni.
Selles artiklis vaatleme tüüpilise Manual QA testülesande näidet alates ülesande esmakordsest lugemisest kuni lõpliku lahenduseni.
Märkus: selles artiklis toodud ülesanne on täielikult väljamõeldud ja loodud ainult õppeotstarbel. See ei ole ühegi ettevõtte tegelik testülesanne ega põhine konkreetse tööandja sise- ega õppematerjalidel, tööprotsessidel või nõuetel.
1. Testülesande näide
Vaatleme tüüpilist käsitsi testimise testülesannet. Tavaliselt saadetakse see kandidaadile pärast üht töövestluse etappi, enamasti e-posti teel. Sõnumis kirjeldatakse ülesannet, antakse selle lahendamiseks eeldatav ajakulu ning tuuakse välja põhinõuded tulemusele: mida täpselt tuleb kontrollida, millises vormis vastus esitada ja millele tähelepanu pöörata.
Samas ei pruugi nõuded alati olla üksikasjalikud. Osa detaile võib olla tahtlikult kirjeldamata – muu hulgas selleks, et hinnata, millised küsimused kandidaadil tekivad ja kuidas ta puuduliku info korral töötab.
Allpool on üks näide sellisest testülesandest.
Testid mobiilirakendust, mille abil saab tellida taksot. Üks peamisi kasutusstsenaariume on sõidumarsruudi valimine. Enne sõidu tellimist peab kasutaja määrama:
- punkti A – koha, kust kasutajale järele tullakse;
- punkti B – sihtkoha.
Mõlemat punkti saab valida aadressiotsingu kaudu. Aadressi sisestamise ajal kuvab rakendus sobivad aadressi variandid, mille hulgast saab kasutaja valida soovitud aadressi. Pärast punkti A ja punkti B valimist kuvab rakendus marsruudi ning võimaldab liikuda sõidu tellimise järgmisse etappi.
Rakendust kasutatakse erinevates linnades ja riikides, mistõttu võivad aadresside vorming ja otsingutulemused piirkonniti erineda.
Rakendust kasutatakse erinevates linnades ja riikides, mistõttu võivad aadresside vorming ja otsingutulemused piirkonniti erineda.
1.1 User story (kasutajalugu)
Kasutajana soovin valida lähtekoha ja sihtkoha aadressi, et koostada oma sõidu marsruut.
Ülesande raames tuleb testida ainult punkti A ja punkti B otsimist ning valimist. Taksosõidu tellimise funktsionaalsust testida ei ole vaja.
Ühtse IT-terminoloogia ja loomuliku eesti keele stiilis:
Osa nõudeid on teadlikult jäetud täpsustamata: kandidaadi ülesanne ei ole ainult testide väljamõtlemine, vaid ka näidata, kuidas ta töötab ebamäärasuse, riskide ja piiratud ajaga.
1.2. Mida tuleb ülesande raames ette valmistada
A. Testimisviisi kirjeldus
Kirjeldage lühidalt:
- millest alustaksite testimist;
- mida otsustaksite kõigepealt kontrollida ja miks;
- millised peamised kontrollide rühmad välja tooksite;
- milliseid kontrolle peate kõige olulisemaks;
- milliseid küsimusi esitaksite nõuete kohta.
Kõiki võimalikke kontrolle ei ole vaja kirjeldada. Meie jaoks on olulisem mõista teie otsuste loogikat.
B. Peamised test stsenaariumid
Koostage lühike nimekiri kõige olulisematest test stsenaariumidest.
C. Tähelepanekud ja leitud vead
Võimaluse korral kirjeldage ka:
- leitud vigu;
- rakenduse ootamatut käitumist;
- vaieldavaid või ebaselgeid kohti;
- võimalikke kasutusmugavusega seotud probleeme;
- küsimusi, mis testimise käigus tekkisid.
Kui leidsite vea, vormistage see nii, nagu teeksite seda päris projektis. Vajaduse korral võib lisada ekraanipilte või ekraanisalvestise.
D. Täiendav uurimine
Kui kasutasite täiendavaid tööriistu, märkige lühidalt:
- millist tööriista kasutasite;
- mida täpselt kontrollisite;
- mida õnnestus välja selgitada.
2. Kuidas sellise ülesande lahendamisele läheneda
Pärast ülesande lugemist tekib sageli esimese asjana soov koostada tabel ja hakata sinna kontrolle kirja panema: korrektne aфdress, vale aadress, tühi väli jne.
Oluline on aga mõista, et hea testülesande puhul ei näita kandidaadi taset väljamõeldud kontrollide arv, vaid see, kui süsteemselt oskab ta uue funktsionaalsusega tutvuda ja ülesande nõuetest aru saada.
Meil on üsna lihtne kasutusstsenaarium:
kasutaja valib punkti A → valib punkti B → rakendus koostab marsruudi.
See on põhistsenaarium, mis peab alati toimima. Seetõttu on loogiline kontrollida seda ühe esimese asjana.
Väga oluline on meeles pidada, et nõudeid ei tohiks ise välja mõelda. Päris töös tuleb täpsustavad küsimused esitada meeskonnale. Testülesandes võib toimida samamoodi: märkige eraldi üles küsimused ja eeldused, millele edasine testimine tugineb.
2.1. Milline testimisdokument valida?
Enne konkreetsete kontrollide juurde asumist tasub otsustada, millises vormis on neid kõige otstarbekam dokumenteerida: testjuhtumitena (test case) või kontrollnimekirjana (checklist).
Sellise testülesande puhul on optimaalne valik kontrollnimekiri ehk checklist. See võimaldab kiiresti fikseerida peamised stsenaariumid, näidata funktsionaalsuse test katvust ja samal ajal mitte kulutada piiratud aega iga sammu üksikasjalikule kirjeldamisele.
Kontrollnimekiri (checklist) on kontrollide loend, kus iga kontrolli juures märgitakse tavaliselt ka selle olek, näiteks läbitud, ebaõnnestunud või kontrollimata.
Tõlge ühtse IT-terminoloogiaga:
Et töötamine oleks mugavam, võib kontrollid jagada eraldi gruppidesse (testikomplektidesse ehk test suite’idesse).
2.2. Testimise piiride määramine
Järgmise sammuna tuleb mõista, mis on otseselt meie ülesandega seotud.
Meid huvitab konkreetselt marsruudi valimine:
aadressi otsimine → punkti valimine → valitud aadressi kuvamine → marsruudi koostamine.
Ülesandes palutakse meil selgelt testida konkreetset funktsionaalsust, mitte teha kogu rakenduse täielikku regressioonitestimist. Seetõttu on oluline jääda ülesande piiridesse ja mitte kulutada piiratud aega maksete, juhi otsimise, sooduskoodide või rakenduse muude osade kontrollimisele.
Hea testija peab oskama mitte ainult leida, mida veel kontrollida saab, vaid ka mõista, mida praegu kontrollida ei ole vaja.
2.3. Suure ülesande jagamine väiksemateks osadeks
Nüüd saab funktsionaalsuse tinglikult jagada mitmeks valdkonnaks:
- punkti A otsimine aadressi järgi;
- punkti B otsimine aadressi järgi;
- valitud aadressi muutmine;
- punkti A ja punkti B asukohtade vahetamine;
- marsruudi koostamine;
- vead ja ebastandartsed olukorrad.
Iga selline valdkond võib edaspidi moodustada eraldi testikomplekti (test suite) ehk seotud kontrollide rühma. See muudab dokumendi struktuuri selgemaks ning aitab näha, millised funktsionaalsuse osad on juba testidega kaetud ja millised veel mitte.
Näiteks „Aadressi otsingu“ testikomplekti võib lisada järgmised kontrollid:
- täieliku aadressi järgi otsimine;
- aadressi osa järgi otsimine;
- vale või olematu aadressi otsimine;
- aadressi valimine kaardilt.
See on mugav, sest kontrollid ei moodusta üht pikka nimekirja, vaid on jaotatud loogilistesse rühmadesse.
2.4. Kõigepealt kontrollime kõige olulisemat
Levinud viga tekstülesande lahendamisel on alustada kohe negatiivsete ja ebaharilike stsenaariumidega: sisestada olematuid aadresse, katkestada internetiühendus, kasutada erimärke või proovida rakendust „katki teha“.
Kõigepealt tuleb aga veenduda, et töötab põhistsenaarium:
- Leida ja valida punkt A.
- Leida ja valida punkt B.
- Veenduda, et valitud on õiged aadressid.
- Kontrollida, et marsruut koostatakse.
- Muuta ühte punkti ja veenduda, et marsruut uuendatakse.
Pärast seda saab liikuda negatiivsete stsenaariumide ja piirsituatsioonide juurde.
Näiteks:
- aadressi ei leita;
- internetiühendus katkeb;
- punkti muutmine.
Kui põhistsenaarium ei tööta, on tegemist juba kriitilise probleemiga funktsionaalsuses. Alles pärast selle kontrollimist on mõistlik liikuda negatiivsete stsenaariumide ja rakenduse ebastandardse käitumise juurde.
Selline järjekord aitab piiratud aega õigesti jaotada ning kontrollida kõigepealt seda, mille jaoks see funktsionaalsus üldse loodud on.
2.5. Vead ja ebastandartsed olukorrad
Eraldi kontrollide rühma moodustavad olukorrad, kus tavapärane kasutusstsenaarium katkeb või kasutaja tegutseb ebastandardselt:
- internetiühendus puudub;
- ühendus katkeb otsingu ajal;
- rakendus viiakse taustale ja avatakse uuesti.
Oluline on kontrollida mitte ainult rakenduse stabiilsust, vaid ka seda, kas kasutaja saab tekkinud probleemi kohta arusaadavat infot.
2.6. Piirkondlikud eripärad
Kui rakendus töötab erinevates riikides ja linnades, tuleb arvestada aadresside ja keeltega seotud eripäradega.
Näiteks:
- eri keeltes aadressid;
- erinevad majanumbrite vormingud;
- aadressid ilma majanumbrita;
- linnaosade, jaamade, lennujaamade ja muude objektide otsimine tavapärase postiaadressi asemel.
Kõiki selliseid variante võib piiratud aja jooksul olla võimatu kontrollida, kuid selle valdkonna väljatoomine näitab, et mõistate reaalse toote eripärasid.
3. Testimise piirangud
Üheks piiranguks sellise ülesande täitmisel võib olla suutmatus rakenduse toimimist erinevates geograafilistes asukohtades täielikult kontrollida.
Näiteks kui testimine toimub tavalisel mobiilseadmel ilma spetsiaalsete tööriistadeta, ei pruugi olla võimalik simuleerida kasutaja viibimist teises linnas või riigis.
Seetõttu võivad mõned stsenaariumid jääda kontrollimata, näiteks:
- aadresside otsimine teistes piirkondades;
- rakenduse käitumine olukorras, kus kasutaja viibib teises riigis.
Sellised kontrollid tasub eraldi välja tuua kui valdkond, mida tuleks kontrollida juhul, kui oleks võimalik geolokatsiooni muuta või simuleerida.
4. Täiendav uurimine
Põhjalikumaks testimiseks võib kasutada täiendavaid tööriistu. Näiteks võimaldavad Androidi emulaator või iOS-i simulaator määrata kasutaja test geolokatsiooni ja kontrollida, kuidas aadressiotsing erinevates linnades ja riikides toimib.
Nende abil saab kontrollida:
- kas otsingutulemused muutuvad vastavalt kasutaja hetkeasukohale;
- kuidas rakendus käitub geolokatsiooni muutmisel.
See on eriti kasulik takso tellimise rakenduste puhul, kus otsingutulemused ja aadresside kättesaadavus sõltuvad otseselt kasutaja asukohast.
5. Ligipääsetavuse testimine
Veel üks valdkond, millega tasub arvestada, on rakenduse ligipääsetavus.
Ligipääsetavuse testimine tähendab kontrollimist, kui mugavalt saavad rakendust kasutada erinevate piirangutega inimesed, näiteks nägemispuudega kasutajad.
Sellise testimise puhul piisab mõnest põhikontrollist. Näiteks võib veenduda, et punkti A ja punkti B väljad on ekraanilugeja abil korrektselt loetavad, leitud aadresse saab probleemideta valida ning kasutajaliides jääb arusaadavaks ka teksti suurendamisel.
Mobiilirakendustes saab kasutada sisseehitatud tööriistu, näiteks iOS-i, VoiceOveri ja Android, TalkBacki.
Testülesande raames ei ole täielik ligipääsetavuse audit kindlasti vajalik, kuid sellele valdkonnale tähelepanu pööramine täiendab hästi üldist testimisviisi.
6. Levinud vead ja antipattern’id
Eraldi tasub käsitleda seda, mis kõige sagedamini testülesande üldmuljet halvendab – isegi siis, kui ülesanne on formaalselt täidetud.
Kõige levinum probleem on soov kirjutada võimalikult palju testjuhtumeid. Testjuhtumite arv ei võrdu testimise kvaliteediga. Sellega on seotud ka teine viga, mida eespool käsitlesime: alustada ebaharilike ja piirsituatsioonidega, kontrollimata kõigepealt, kas põhivoog üldse töötab.
Samasse probleemide rühma kuulub ka ülesande piiridest väljumine – näiteks maksete või juhi otsimise testimine olukorras, kus kasutajaloos on selgelt öeldud, et vaja on testida ainult punkti A ja punkti B. See ei ole küll tõsine viga, kuid näitab, et ülesande tingimusi ei loetud piisavalt tähelepanelikult.
Sageli esineb ka vastupidine olukord – kandidaat mõtleb nõude küsimise asemel ise välja. Näiteks otsustab, et „tõenäoliselt peaks otsing töötama ilma internetita vahemälu abil“, ning testib seda väljamõeldud käitumist selle asemel, et märkida see lahtiseks küsimuseks. Ka päris töös on see halb harjumus, mistõttu tasub juba selles etapis näidata, et oskate sellist lähenemist vältida.
Eraldi probleemide rühm puudutab tulemuste vormistamist. Vearaport stiilis „aadressiotsing ei tööta“, ilma taasesitamise sammude ning oodatava ja tegeliku tulemuse kirjelduseta, on sisuliselt kasutu – seda ei saa ei taasesitada ega hinnata.
Eraldi tasub rääkida ka piirangutest. Kui midagi ei õnnestunud kontrollida – näiteks rakenduse käitumist teises piirkonnas, kuna geolokatsiooni muutmine ei olnud võimalik –, tuleks seda otse välja tuua. Kandidaadid jätavad sellised lüngad sageli lihtsalt mainimata, mistõttu võib väljastpoolt tunduda, et selle valdkonnani lihtsalt ei jõutud.
Kui ülesande lahendamiseks on ette nähtud kaks päeva, kuid lahendus saadetakse nädal hiljem, on ka see ohumärk, isegi kui sisu ise on hea. Oskus hinnata töömahtu ja õigel ajal lõpetada on osa samast kompetentsist, mida testülesanne peaks näitama.
7. Kokkuvõte
Selles artiklis käsitlesime tüüpilist Manual QA testülesannet ja vaatasime, kuidas sellele praktiliselt läheneda: millest alustada, kuidas määrata testimise piirid, milline dokumentatsioon valida, kuidas jagada funktsionaalsus eraldi kontrollide rühmadeks ning kuidas määrata prioriteete.
Samuti käsitlesime seda, kuidas lisada ligipääsetavuse kontrolle ja kasutada täiendavaid tööriistu funktsionaalsuse põhjalikumaks uurimiseks.
Peamine mõte on see, et hea testülesanne ei ole võimalikult pikk kontrollide nimekiri. Palju olulisem on näidata selget ja järjepidevat lähenemist ülesandele: mida kontrollida, miks just seda ja millises järjekorras.
Meie kursusel käsitletakse selliseid ülesandeid praktiliste projektide käigus: õpilased koostavad stsenaariume ja kontrollnimekirju, jagavad funktsionaalsuse väiksemateks osadeks, koostavad testikomplekte, õpivad määrama prioriteete, leidma ja kirjeldama vigu ning kasutama reaalses testimises rakendatavaid tööriistu.