Testdokumentasjon Innholdsfortegnelse Brukertesting... 2 Hva er brukertesting?... 2 Formål med brukertesten... 2 Brukertest 1:... 3 Sjekkliste på testdagen:... 3 Kjøreplan... 3 Testteamet... 4 Hvordan skal vi utføre testen?... 4 Gjennomføring av brukertest 1... 5 Test 1:... 5 Test 2:... 5 Test 3:... 5 Test 4:... 5 Oppsummering og resultat av brukertest 1... 5 Brukertest 2:... 6 Sjekkliste på testdagen:... 6 Kjøreplan... 6 Testteamet... 7 Hvordan skal vi utføre testen?... 7 Gjennomføring av brukertest 2... 8 Test 1:... 8 Test 2:... 8 Test 3:... 8 Oppsummering og resultater av brukertest 2... 8 Kilder... 9
Brukertesting Vi har valgt å innhente informasjon fra boken praktisk brukertesting av Eli Toftøy-Andersen og Jan Gunnar Wold, og Universell utforming av ikt-systemer, brukergrensesnitt for alle av Frode Eika Sandnes. Vi har benyttet oss av disse fordi vi trengte en fordypning i fagfeltet, og i tillegg var det greit med en oppfriskning av emne. Hva er brukertesting? Målet med brukertesting er å få den innsikten du trenger for å gjøre produkter som it-systemer og nettsider enklere å bruke[1]. Hensikten med en brukertest er å få reell tilbakemelding fra brukere av tjenesten, og å bruke resultatene fra testen til å forbedre tjenesten. Hvis brukertesten avdekker problemområder med tjenesten eller nettstedet, som at testpersonene har vansker med å forstå instruksjoner, utføre oppgaver eller finne informasjon, anbefales det at utviklingsteamet forbedre designet, og deretter teste på nytt. Utviklerne av en tjeneste blir ofte blinde på svakheter ved tjenesten, og brukerne bringer inn et nytt perspektiv[2]. Den første brukertesten vi utførte var en såkalt lo-fi brukertest. Denne ble utført på en papplate formet som en mobil. Dette gjorde vi for å spare tid i starten av prosjektet, og for å underbygge at de konklusjonene vi hadde kommet frem til i den heuristiske evalueringen faktisk stemmte med de problemene synshemmede møter i applikasjonen. Andre brukertesting ble utført med en fungerende prototype av applikasjonen, kjørende på en Androidtelefon. Vi fant flere gode oppskrifter på testplanlegging i bøkene, og laget en testplan basert på disse. Formål med brukertesten Trafikanten har allerede en velfungerende applikasjon til Android. Problemet med Androidoperativsystem var at det ikke er tilrettelagt for brukere med synshemninger. Derfor skulle vi se på mulighetene for å lage en applikasjon for målgruppen Formålet med første brukertest var å undersøke om vår heuristiske evaluering av appliksjonen faktisk stemte med det denne brukergruppen ønsket og trengte for å benytte seg av en slik applikasjon. Vi ønsket å avdekke eventuelle svakheter ved den heuristiske evalueringen. Ting som vi ikke hadde tenkt på, som kanskje er en selvfølge for en synshemmet person. I den andre brukertesten ville vi teste den fungerende applikasjonen på en mobiltelefon og få en tilbakemelding på denne. Funksjonene som skulle testes var applikasjonen som en helhet. Vi hadde planer om å gi testerne flere forhåndsbestemte oppgaver i applikasjonen, som for eksempel å søke opp sanntidsdata på en bestemt stasjon etc. Mer om dette følger lenger ned. Vi var i kontakt med Norges blindeforbund som opprettet et testpanel.dette testpanelet hjalp oss gjennom hele brukertestingen. Panelet inneholdt både svaksynte og blinde, de fleste så på seg selv som over gjennomsnittelig interessert i smarttelefoner. Den eneste svakheten ved sammensettningen av testpanelet var at ingen av testpersonene var nybegynnere, og at alle kjente til smarttelefoner fra før. Testen ble utført i blindeforbundets lokaler.
Brukertest 1: Sjekkliste på testdagen: Utført Sjekkpunkt Tenk over hvor du skal plassere deg deg selv(testleder), testbrukeren og observatører. Plasser utstyr i forhold til dette. Sjekk at prototyper virker som de skal, dvs. rekkefølge på pappprototypene. Dobbeltsjekk at rommet faktisk er reservert deg og ikke er dobbeltbooket. Sjekk at rommet er ryddet og at det er stoler nok til alle. Notatblokk, samtykkeskjema, noe å skrive med og på må være tilgjengelig for testleder. Brukerne får i oppgave å manøvrere seg rundt i applikasjonen. Etter det hadde vi satt opp bestemte oppgaver som de måtte finne frem til, blant annet finne avgangene på buss 20 på Carl Berner, og avgangene på t-bane nummer 5 retning sør Planen var også til å utføre et avsluttende intervju med testbrukerne. Her kommer vi blant annet til å spørre om følgende: Testpersonen fortelle litt om sin egen mobilbruk, ferdighetsnivå ( hvordan type telefon, os, bruker apper(trafikanten, ruteplanlegger), generelt hva de bruker telefonen til) Bekjente svaksynte, benytter de seg av smartelefon. Subjektiv mening om trafikanten-app til blinde/svaksynte. Hva de syntes om vår heuristisk evaluering, dvs papprototypene våre. Etc. Kjøreplan Tid Innhold 2 min Møt brukeren og følg han/henne inn i rommet. 3 min Forklar brukeren hva som skal skje, og sørg for at samtykkeskjemaet er underskrevet. Ca. 15 min Gi brukeren testoppgave og be han/henne løse disse. 15 min Utfør avsluttende intervju. 3 min Gi brukeren gavekort, takk for innsatsen og følg han/henne ut. Hentet inspirasjon fra [1], men noen små justeringer
Testteamet En testperson Teste prototypen En testleder Har overordnet ansvar for planlegging og gjennomføring av testen. Tar imot brukerne og leder dem gjennom testen. En observatør Følger med på samtlige testbrukere Ansvarlig for tidtaking Sette score for gjennomføring på de ulike oppgavene. Observerer testbrukerne og gjør notater Maskinstyrer 1: Styrer prototypene 1. maskinstyrer skal holde styr på og legge frem riktig pappbrikke til tespersonen slik at prototypen alltid samsvarer med det testpersonen har trykket på prototypen. Makinstyrer 2: Styrer forhåndsinnspilt lyd. 2. maskinstyrer skal til en hver tid holde oversikt over hvor testpersonen er i prototypene og spille av riktig lyd i forhold til dette. Hvordan skal vi utføre testen? Testen skulle, som nevnt over, bli utført på prototyper laget av papp. Prototypen var basert på den grundige designfasen vi hadde vært gjennom. Hvert skjermbilde ble skrevet ut på en egen papplate. Vi ville da til enhver tid kunne følge med på testpersonen, se hva denne trykket på, og gi testpersonen riktig skjermbilde ut i fra hva personen trykket på. Vi skulle utføre denne brukertesten på en måte der testlederen skulle sitte ved siden av testpersonen under hele testen og følger aktivt med, dvs. stille spørsmål underveis for å klargjøre observasjoner og hjelpe brukeren å tenke høyt. Den største fordelen ville være at brukeren ofte ville kunne spørre testleder om hjelp underveis. Testlederen skal som hovedregel ikke svare eller hjelpe, men spørsmålene forteller deg hva som foregår i hodet til brukeren[1]. Vi vil også ha en observatør i det samme rommet, som oppholder seg i bakgrunnen hele tiden. Observatøren skal kun observere testpersonen.
Gjennomføring av brukertest 1 Gruppen tok utgangspunkt i dokumentet brukertesting over, der vi skrev om hvordan vi ville utføre testene på testpersonen på blindeforbundet. Vi hadde på forhånd avtalt om å få låne et rom på blindeforbundet, der vi gjennomførte alle testene. Her utførte vi testen, som nevnt i kapittelet brukertesting, på prototyper på papp. Vi fant tidlig ut at det med å gjennomføre forhåndsoppsatte oppgaver, ville bli vanskelig å få gjennomført på papprototyper. Dette fordi skrivingen av informasjon på papp ville bli vanskelig å få til, samt at vi kun hadde med 3-4 stasjoner i prototypene våre. Test 1: 3 testpersoner, alle over middels interessert i IT, jobber i IT-avdelingen på Blindeforbundet. Alle er svaksynte, og alle bruker android på mobil.dette pga som de aller fleste som bruker android, overføringer, tillatelser osv, bruker mye lydbøker. Men de påpeker også at de som er helt blinde må bruke Iphone pga skjermleser. Alle bruker trafikanten, men de holder seg til kategoriene favoritter og sanntid, ruteplanlegger blir ikke brukt. I en god applikasjon bør man på en enkel måte velge elementer i applikasjonen, og få lest opp dette på en ryddig måte. Deres forslag til forbedringer av applikasjonen. Bør kunne skifte kontraster og skriftstørrelse. Skal ikke forandre utseende innad i applikasjonen, og bør ikke ha for mange knapper og valg. Test 2: Testpersonen er helt blind. Benytter seg kun av sanntid i applikasjonen. Mener at applikasjonen må være klargjort for accessibility-funksjonen i operativsystemet, og den må være tilpasset skjermleseren. Ingen konfigurering av applikasjon, alt konfigurering styres gjennom accessibilityet til android. Dette for å unngå komplikasjoner mellom app og talkbackfunksjon etc. Han mener tilgjengelighetsfunksjonen er kraftig forbedret i Androidversjon 4.0. Vil ikke ha en egen applikasjon for blinde. Bruker ikke trafikanten for at det skal være morsomt, den skal være nyttig og effektivt. Derfor bør den være enkel og oversiktlig. Mener at det er 10-20 blinde som bruker android(anslagsvis). Test 3: Testpersonen er svaksynt. Hadde android, men byttet til IPhone pga grensesnittet.benytter seg av trafikanten, mest på Ipad pga skjermstørrelse. Problemer med mobilapplikasjonen; Blir ofte for smått, synet begrenser mulighetene. Liker våre idéer om valg av større skriftstørrelse, og bedre kontrastfarger, mener dette trekker ned androidapplikasjonen. Benytter seg av favoritter og i nærheten. I god applikasjon: Større skrift, heller mindre informasjon på skjermen. Test 4: Testpersonen er helt blind. Har trafikanten til iphone, mener denne fungerer veldig fint. Men mener denne mangler muligheten til å koble opp mot gps, dvs velge stasjoner i nærheten og hvordan man kom seg til denne stasjonen osv. Bruker kun sanntid, ikke ruteplanlegger. Bruker søkefunksjonen regelmessig. Oppsummering og resultat av brukertest 1 Helt blinde MÅ bruke Iphone pga skjermleseren til Apple. Kun sanntid og favoritter blir brukt, ikke reiseplanlegger. Bør være enkel og oversiktlig Vi fikk vite om tilgjengelighetsfunksjoner i Android 4.0 og at applikasjonen bør utnytte disse. Synshemmede ønsker ikke en egen blindeapp.
Brukertest 2: Sjekkliste på testdagen: Utført Sjekkpunkt Tenk over hvor du skal plassere deg deg selv(testleder), testbrukeren og observatører. Plasser utstyr i forhold til dette. Sjekk at prototyper virker som de skal, dvs. applikasjonen virker på android-enheten. Dobbeltsjekk at rommet faktisk er reservert deg og ikke er dobbeltbooket. Sjekk at rommet er ryddet og at det er stoler nok til alle. Notatblokk, samtykkeskjema, noe å skrive med og på må være tilgjengelig for testleder. Vi kommer til å be de utføre de samme oppgave som i brukertest 1.Brukerne får i oppgave å manøvrere seg rundt i applikasjonen. Etter det hadde vi satt opp bestemte oppgaver som de måtte finne frem til, blant annet finne avgangene på buss 20 på Carl Berner, og avgangene på t-bane nummer 5 retning sør Vi kommer også til å utføre et avsluttende intervju med testbrukerne. Her kommer vi blant annet til å spørre om følgende: Hva syntes brukerne om den ferdige android-prototypen vår? Er den forbedret i forhold til den opprinnelige applikasjonen? Hvis ja, hva er forbedret? Kjøreplan Tid Innhold 2 min Møt brukeren og følg han/henne inn i rommet. 3 min Forklar brukeren hva som skal skje, og sørg for at samtykkeskjemaet er underskrevet. Ca. 15 min Gi brukeren testoppgave og be han/henne løse disse. 15 min Utfør avsluttende intervju. 3 min Gi brukeren gavekort, takk for innsatsen og følg han/henne ut. Hentet inspirasjon fra Toftøy-Andersen, Wold, 2011 s. 69, men noen små justeringer
Testteamet En testperson Teste prototypen En testleder Har overordnet ansvar for planlegging og gjennomføring av testen. Tar imot brukerne og leder dem gjennom testen. To observatører Følger med på samtlige testbrukere Ansvarlig for tidtaking Sette score for gjennomføring på de ulike oppgavene. Observerer testbrukerne og gjør notater Maskinstyrer: Kontrollerer at prototypen fungerer som den skal. Ved feil eller feilmelding, hjelpe til å rette opp i denne. Hvordan skal vi utføre testen? Denne testen skulle utføres med endelig utgave av applikasjonen på en Androidtelefon. Planen var først å presentere hvordan resultatet var blitt. Deretter skulle testpersonene få i oppgave å løse forskjellige oppgaver vi ga dem. Til slutt ville vi høre hva testpersonene mente om applikasjonen. Testlederen skulle også her følge aktivt med, og prøve å få brukeren til å tenke høyt, for å få mest mulig informasjon ut av selve brukertesten. Vi har også utformet et samtykke- og taushetserklæringsskjema, dette har vi, med god hjelp fra pensum, dette ligger som vedlegg i prossessdokumentasjon.
Gjennomføring av brukertest 2 Gruppen tok igjen utgangspunkt i dokumentet brukertesting over, der vi skrev om hvordan vi ville utføre testene på testpersonen på blindeforbundet. Vi hadde på forhånd avtalt om å få låne et rom på blindeforbundet, der vi gjennomførte alle testene. Her utførte vi testen, som nevnt i kapittelet brukertesting, på en kjørende applikasjon på en android-telefon. Testpanelet er de samme som sist, og i samme rekkefølge slik at det er lett for lesere å få en oversikt over hvem som har deltatt i de forskjellige testene. En av testpersonene valgte å ikke møte opp. I motsetning til brukertest 1 gjennomførte vi hele opplegget slik vi hadde planlagt på forhånd, der vi gjennomførte konkrete oppgaver. Test 1: 3 testpersoner, alle over middels interessert i IT, jobber i IT-avdelingen på Blindeforbundet. Alle er svaksynte. Alle 3 mener vi har fått til det de påpekte i brukertest 1, der de gjerne ville ha større klikkbare elementer og bedre kontrastfarger. En av testbrukerne likte spesielt godt at fargene på avgangene og tidene var forskjellige, slik at det er lettere å se hva som var hva. Dette er veldig viktig for denne type brukergruppe, svaksynte, for det er lett at informasjon flyter sammen og blir uleselig på grunn av dette. De er generelt meget fornøyd med utformingen av den nye applikasjonen. Test 2: Testpersonen er helt blind. I forrige test fikk vi ganske krass tilbakemelding på ideéne våre, med å lage en applikasjon spesielt utviklet for blinde og svaksynte, med mange innstillingsmuligheter. Derfor var vi godt fornøyd da testpersonen uttrykte, etter å ha trykket seg rundt i applikasjonen, at dette var det beste vi kunne få til med den integrerte tekst-til-tale funksjonen i android, det som blir talegjengitt fra skjermen er mye mer logisk enn slik det var tidligere. Han sa han savnet funksjonen der han kan swype mellom elementene i applikasjonen, men mener selv at dette er en mangel ved android, og muligens også en vanesak fra IPhone. Han likte måten applikasjonen nå er bygget opp på, spesielt at det er mer rom mellom de forskjellige elementene, og at tekst-til-tale funksjonen er mer oversiktlig. Test 3: Testpersonen er svaksynt. Mente sist at applikasjonsidéene våre var gode, spesielt med større skrift og bedre kontrastfarger. Likte godt at skriften er blitt gul, og mente at dette, sammen med større skriftstørrelse, gjør at det er mye enklere å lese informasjonen på applikasjonen. En ting testpersonen mener vi kan ta med oss er at det blir litt vanskelig å tyde informasjonen under de forskjellige rutene, altså mellom det blå i applikasjonen. Men han påpeker også at dette er veldig individuelt, og at det er like mange meninger som det er personer om dette. Dette er altså stikk i strid med hva de tidligere testpersonene mente, men vi tar det med oss videre til en siste vurdering. Oppsummering og resultater av brukertest 2 Gjennomførte, gode kontrastfarger som er like gjennom hele applikasjonen. Godt fornøyd med hvordan vi har bygget opp appen til accessibility-funksjonen tilandroid. Mer brukbart ved større skriftstørrelse Bedre tekst-til-tale-funksjon.
Kilder Sandnes, Frode Eika, Universell utforming av ikt-systemer, 2011 [1]Toftøy-Andersen, Eli, Wold, Jon Gunnar, Praktisk Brukertesting, 2011 [2]http://no.wikipedia.org/wiki/Brukertesting