Tegelikult ei ole suurt vahet, kas tõrgub infosüsteem su arvutis, mobiilne veebileht, äpp telefonis või tahvlis - ühevõrra ebamugav on see nii või teisiti. Kasutajana sa läksid sinna mõnda vajalikku tegevust tegema, kuid tarkvara takistab sind eesmärgi saavutamisel.
Niisiis kehtivad mobiilitestimisel kõik "tavalise" testimise reeglid, aga on veel palju muudki, millega arvestada.
Lisakeerukus tuleneb näiteks nii seadme füüsilistest parameetritest, andmeühenduse olemasolust, tüübist ja kvaliteedist kui ka erinevate platvormide rohkusest ja fragmenteerumisest. Kui ei usu, tee oma kontoris või sõpruskonnas küsitlus ja loe kokku, mitu erinevat seadet mitmelt erinevalt tootjalt mitme erineva operatsioonisüsteemi versiooniga, ekraani suuruse ja resolutsiooniga said.Rääkimata sellest, et tavaarvutis toimetavat infosüsteemi üldjuhul ei patsutata ega raputata (gestures) ja samuti ei ole ohtu, et kasutaja nuppudele pihta ei saa (sest need on liiga väikesed või päikese käes liiga kehvasti nähtavad), samal ajal kui ta diivanil lesib või hoopis bussi peale jookseb. Arvutihiir on teatavasti suhteliselt täpne tööriist, erinevalt potentsiaalselt tömbist sõrmest.
Samuti tekib testimisele mõeldes põhjendatud küsimus, kas mul peavad kõikvõimalikud seadmed olemas olema, või kuidas ma muidu kontrollida saan, et ikka kõigi kasutajate telefonidel kõik õigesti toimib. Ja kui mu äpp on mõeldud kasutamiseks enam-vähem üle maailma, siis kuidas ma tean, et see Jaapanis ka töötab. Ja Uus-Meremaal.
Luban, et mobiilsete rakenduste testimisel (ja analüüsimisel, ja arendamisel) tekib hulk uus võimalusi ja kohustusi, mis tulenevad sellest, et testitav tarkvara .... käib kasutajaga kõikjal kaasas.
Erinevaid nüansse, soovitusi ja lahendusi on palju, kuid minu jaoks kõige olulisemad on järgmised:
1. Tunne oma kasutajat. Missugust seadet ta tõenäoliselt kasutab (pigem high- või low-end, platvorm) ja missuguses keskkonnas ta rakendust kasutab (kodus-tööl-puhkehetkel-elukriitilisel hetkel) ning loomulikult - mida kurja võivad võimalikud satikad talle põhjustada. Selle infoga saab juba üksjagu pihta hakata, et testimisele mõistlikud piirid seada nii testitavate stsenaariumide kui ka reaalsete seadmete vs emuleerimise taskaalu mõttes.2. Ära unusta mobiilivaldkonna tüüpilisi nõudeid püstitada ja kontrollida. Mobiilses seadmes on võimalik kasutada asukoha, güroskoobi, kiirendusanduri jm füüsilise keskkonna anduritest saadavat infot. Samuti ei tasu unustada, et telefoni võiks lisaks äppimisele olla võimalik kasutada ka helistamiseks ja sõnumite saatmiseks. Ja et kasutajad üldjuhul solvuvad, kui äpp nende seadme aku 20 minutiga tühjaks imeb (loe: soojuseks muundab, nii et seadmel võib soovi korral liha grillida).
3. Arvesta, et nii seadmed kui ka nende baastarkvara uuenevad kiiresti. See loob täiendava võimaluse ootamatute tõrgete tekkeks. Siinkohal võivad abiks olla mõistlikult automatiseeritud testid, mis aitavad kiirelt ja suhteliselt vähese vaevaga teada saada, kas tarkvara uuenenud platvormil ka ikka veel töötab. Kuna ka üle päeva veaparanduste saatmine kasutaja telefoni on nii kasutaja kui arendaja jaoks tüütu, siis on kõigile mugavam olulisi vigu mitte toodangusse lasta. Pea aga meeles, et automatiseerimine on vaid osa heast testistrateegiast - mobiilimaailmas on oi-kui-palju nüansse, mille headust saab hinnata vaid inimene (vt punkt 1).
