Gebruikersscenario leidraad bij app-testen

Tegenwoordig gebruikt iedereen apps. Je hebt dus direct eer van je werk als tester van de mobiele applicatie. Zeker als blijkt dat jouw collega’s, vrienden en familie jouw app massaal gaan gebruiken. Het nadeel is natuurlijk dat je het direct om je oren krijgt, als blijkt dat gebruikers niet tevreden zijn over de door jou ontwikkelde of geteste applicatie. Meer dan ooit is het dus zaak dat mobiele apps getest worden op functionaliteit, gebruikers-vriendelijkheid, snelheid, duidelijkheid en toegankelijkheid.

Dat klinkt logisch maar iedereen gebruikt apps natuurlijk op zijn of haar eigen manier. Hoe zou mijn oma de app gebruiken? Wat vindt de twintiger belangrijk bij het appen in de trein? Hoe gebruikt een manager de mobiele app?

Verschillende gebruikersscenario’s dus die ook van invloed zijn op de testaanpak. Uiteraard zijn er veel wegen die naar Rome leiden. Of anders gezegd, methoden en technieken te kust en te keur. Maar soms is er niet of nauwelijks tijd om te bepalen wat de beste methode is. Of stap je halverwege een project in. Dan word je gedwongen gewoon van start te gaan. In zo’n situatie is mijn ervaring dat de hieronder beschreven opstartstappen nuttig zijn

Als eerste loop ik één keer volledig door de app. Daarmee krijg ik een volledig overzicht van alle app schermen. Voor wie en wat is de app bedoeld en in welke functionaliteiten voorziet de app? En wellicht het belangrijkste, kan ik ook werkelijk doen waar de app voor bedoeld is? Tijdens dat proces schets ik op een leeg vel papier een minimalistisch diagram over hoe ik denk dat de app eruit ziet.

Vervolgens loop ik opnieuw van begin tot eind door de hele app. Dan controleer ik de allerkleinste details. Van spelfouten tot gestures/bewegingen over het scherm. Volgt de app bijvoorbeeld de platform richtlijnen? Zo kent Android een specifieke terugknop op de devices, terwijl je op het iOS platform een terugknop in de app maakt. Verder test ik bekende bedieningsfoutjes zoals met twee vingers op verschillende plekken tegelijkertijd drukken.

Ik kijk dan of verschillende schermen tegelijkertijd geladen kunnen worden. Of ik druk op een knop en sleep dan mijn vinger weg om te beoordelen of de knop een ‘pressed state’ heeft. Een ‘pressed state’ is een andere kleur van een knop, zodat je ziet wat je indrukt. Kortom, ik stop als het ware een temperatuurmeter in de app om een goed beeld te krijgen van de kwaliteit van de mobiele software.

Tenslotte doe ik alle handelingen twee keer sneller dan de gemiddelde gebruiker zal doen. Mijn ervaring is dat een app niet goed opgebouwd is als je vaak en snel tegen crashes aanloopt. Bij een slechte opbouw worden bijvoorbeeld oude schermen niet netjes opgeruimd. Of gegevens blijven in het geheugen staan. Het kan ook zo zijn dat de app niet goed omgaat met vervuilde data van een back-end applicatie. Des te sneller je dan door een app heen navigeert en verschillende gebruikershandelingen met elkaar combineert, des te minder tijd heeft het toestel nodig om acties te verwerken. Als dat niet netjes gebeurt, is de kans op crashes groot.

Deze opstartstappen zijn natuurlijk heel generiek. Ik zei al dat de de meest effectieve testaanpak helemaal afhangt van het doel en type gebruikers van de app.

Caleb Repkes, testing professional van Sogeti

TMap Dag

Meer weten over welke testaanpak het meest effectief is in welk scenario? Kom dan 28 oktober 2014 naar de TMap Dag in het Spant! in Bussum.