Eventhandler Teknologi, kunst og design Høgskolen i Oslo og Akershus, våren Testrapport

Transkript

1 Eventhandler Teknologi, kunst og design Høgskolen i Oslo og Akershus, våren 2013 Testrapport

2 1 INNHOLDSFORTEGNELSE 1 INNHOLDSFORTEGNELSE Innledning Formål med testing Funksjonalitet Responsivitet Brukertesting Testingen Enheter Verktøy Chrome DevTools Ripple Emulator SoapUI Testing i utviklingsfasen Testing i testfasen Brukertesting Resultater Respons- og funksjonalitetstester Brukertesting Konklusjon

3 2 Innledning Under planleggingen av prosjektet valgte vi å legge testingen til etter utviklingsprosessen. Vi hadde ingen erfaring med testdrevet utvikling og det å skrive programmatiske tester. I stedet fokuserte vi på å teste funksjoner manuelt etter hvert som vi skrev dem. Vi testet egenskrevet kode så vel som hverandres. I utviklingsprosessen har veilederne hos Accenture brukertestet applikasjonen og gitt oss tilbakemeldinger. Og i midten av april ga de oss tips til verktøy vi kunne ta i bruk i siste del av utviklingen og i testfasen. Denne rapporten tar for seg oppsett, utførelse og resultater av testingen. 2

4 3 Formål med testing Testing av programvareprodukter er viktig for: å sikre at et program er i stand til å gjøre det programmet er ment å gjøre. at programmet oppfyller kravene i kravspesifikasjonen. å oppdage feil før programmet tas i bruk. å avdekke svakheter i design og brukervennlighet. Vi valgte å utføre testene med fokus på funksjonalitet, responsivitet og brukertesting. 3.1 Funksjonalitet For å kunne levere et godt produkt er det en nødvendighet at applikasjonen oppfører seg som man forventer. Det betyr at alle knapper for navigasjon og funksjonalitet fører dit dem skal, gjør det dem skal og er intuitive. 3.2 Responsivitet Mennesker er utålmodige vesner. Det er derfor viktig at applikasjonen er responsiv, at animasjoner flyter fint og at det generelt er lite ventetid. 3.3 Brukertesting Brukertesting er kanskje den viktigste formen for testing. Det er fort gjort at en som har utviklet en applikasjon ser seg blind på design, navigasjon og hvordan bruke funksjonaliteten. Ved å la andre som ikke kjenner oppbyggingen eller har sett applikasjonen, kan man få verdifulle tilbakemeldinger om hva som fungerer og hva som gjøres annerledes. 3

5 4 Testingen I utviklingsprosessen ble testingen hovedsakelig utført lokalt på egne laptoper. Vi fikk ikke testet ut applikasjonen på telefon før halvveis ut i prosjektperioden. Årsaken til dette var at for å kunne installere applikasjoner på iphone-telefoner, noe vi begge har, krever Apple at man betaler 99 dollar for et utviklersertifikat. Arbeidsgiver hadde imidlertid et sertifikat til oss men det tok tid å få på plass. 14. mars ble det endelig i orden og vi kunne begynne å teste på telefon i tillegg. 4.1 Enheter Følgende enheter ble brukt til testing. Dell (laptop) CPU: Intel Core 2.5GHz Minne: 4 GB RAM OS: Windows 7 iphone 4 CPU: 1 GHz Cortex-A8 Minne: 512 MB RAM Skjerm: 3,5 tommer OS: ios iphone 5 CPU: Dual-core 1.2 GHz Minne: 1 GB RAM Skjerm: 4 tommer OS: ios Samsung Galaxy Tab 10.1 CPU: Dual-core 1 GHz Cortex-A9 Minne: 1 GB RAM Skjerm: 10,1 tommer OS: Android iphone-telefonene var våre og de var følgelig tilgjengelige gjennom hele prosjektperioden. Samsungtableten fikk vi låne fra skolen da testfasen tiltok. 4.2 Verktøy Vi har tatt i bruk verktøy for feilsøking og testing. Nedenfor er en oversikt over hvilke verktøy vi har brukt Chrome DevTools Chrome developer tools er et nyttig innebygget verktøy i Chrome. Her kan man blant annet inspisere DOM og CSS, bruke JavaScript-konsollen til å se innholdet av loggede variabler og objekter, feilsøke i JavaScriptkode og se på ressurser og headere som sendes/mottas. 4

6 Bilde: 4,1 Konsollen brukte vi hyppig for å undersøke innholdet av variabler og objekter. function geteventlist() { getdata.getarrangementer(function(arrangementer){ console.log(arrangementer); var template = $("#event-li-tpl").html(); var html = Mustache.to_html(template, arrangementer); $('#event-list').html(html); $('#event-list').listview('refresh'); }); } Linjen «console.log(arrangementer);» i kodeeksempelet ovenfor vil skrive ut innholdet av «arrangementer» i Console-fanen i DevTools. En annen funksjon vi brukte mye var å gå inn på en request for å se på headerne som ble sendt frem og tilbake, samt på data som ble returnert fra kallet. 5

7 4.2.2 Ripple Emulator Ripple Emulator er en utvidelse for Chrome og er en multiplattform mobil-emulator som er laget for applikasjoner skrevet i HTML5, CSS og JavaScript. Den gjør det mulig å teste applikasjoner på forskjellige plattformer i sanntid. Vanlige feilsøkingsverktøy, som Chrome DevTools, for nettlesere fungerer sammen med emulatoren. Dette verktøyet brukte vi hovedsakelig for å teste at designet ble slik vi hadde tenkt. Bilde: 4,2 6

8 4.2.3 SoapUI SoapUI er et webtjenertesteprogram for serviceorienterte arkitekturer (SOA). Programmet har mange muligheter for testing, bl.a. funksjonell testing, webtjener testing, REST testing mm. Bilde: 4,3 Her gjorde vi integrasjonstesting ved at vi opprettet tester for de forskjellige ressursene vi har i API et. Vi laget tester for alle GET-metoder (metoder som kun henter data, ikke modifiserer) og for en av POST-metodene (metoder som oppretter ny data). Testene for GET-metodene kjørte vi mot et testarrangement og la til «assertions» for å sikre at metodene returnerte hva som var forventet. «Assertions» er en måte å undersøke om en respons inneholder en spesifikk ting. 7

9 Så kjørte vi alle testene for å få tilbakemelding på de som ble godkjent og de som eventuelt feilet. Dette ga oss en trygghet ved at når vi gjorde endringer i koden, kunne vi enkelt kjøre testene for å forsikre at ressursene fungerte som de skulle. 8

10 4.3 Testing i utviklingsfasen Tidlig i utviklingsfasen var det fokus på å sette seg inn i domenet, ha dialog med arbeidsgiver for å kartlegge krav og behov, lære seg teknologier som skulle brukes og bli kjent med utviklingsverktøy. Derfor ble testingen begrenset til at vi selv kontrollerte at metoder og funksjoner fungerte slik vi ønsket. Omtrent midtveis i fasen ble det ordnet med iphone-lisens, og vi kunne begynne å teste applikasjonen på telefon. Mot slutten av utviklingsfasen tok vi i bruk SoapUI for integrasjonstesting av backend. I denne fasen testet vi applikasjonen med backend liggende lokalt på egen laptop og med databasen på ekstern server. 4.4 Testing i testfasen Etter utviklingsfasen har vi hatt kodefrys i forhold til å implementere ny funksjonalitet. Vi konsentrerte oss om å teste og utbedre feil i applikasjonen og på backend. Noen feil visste vi om men som vi prioriterte å vente med å utbedre til testfasen. Andre feil ble avdekket og feilrettinger ble gjort. Vi la til rette for brukertesting ved å legge backend på ekstern server og konfigurere applikasjonen til å bruke denne. Ved testing på telefonen frem til nå, var man avhengig av at laptop med backend og telefonen var koblet til samme nettverk. Men nå var det mulig å teste på telefon fra alle steder med internettilgang. 4.5 Brukertesting Gjennom utviklingsperioden har vi på veiledermøtene hos Accenture latt veilederne teste applikasjonen. Til å begynne med via emulatoren på laptop, og etterhvert, da vi fikk ordne med lisens, også på telefon. I testfasen fikk vi en medstudent og tre Accenture-ansatte til å gjøre brukertesting. Medstudenten fokuserte på bruk, utseende og brukervennlighet da han ikke hadde kjennskap til behovene og kravene til applikasjonen. Accenture kunne i tillegg teste i forhold til behov og krav. Brukerne testet slik de selv ville, uten noen spesielle instrukser fra oss. Grunnet liten tid og problemene med server, fikk vi bare tid til én uke testing. Men like fullt var tilbakemeldingene veldig verdifulle. 9

11 5 Resultater 5.1 Respons- og funksjonalitetstester Til disse testene valgte vi å bruke en iphone-telefon og en Samsung Galaxy Tab. På den måten fikk vi testet applikasjonen på to forskjellige plattformer og med forskjellig skjermstørrelse. På begge enhetene lugget animasjonene i overgangen mellom sider. Årsaken til dette er enhetenes ytelsesevne i forhold til å kjøre JavaScript. På iphone 5, som har en mye høyere ytelse, kjører animasjonene fint. [1] Bilde 5,1 Vi ser iphone 4 få 3545 mens Samsung Galaxy Tab får 2400 [2] i en tilsvarende test (lavere er bedre). Side Aktivitet Samsung iphone 4 Oppstart Oppstart av applikasjonen OK OK Startsiden Innlasting OK OK Bruke søkefeltet OK OK Trykke på et arrangement OK OK Trykke (+) OK OK Legge til arrangement Innlasting OK OK Fylle inn felter OK OK Trykke «Lagre» når ferdig utfylt OK OK Trykke «Lagre» når ikke ferdig utfylt OK OK Detaljert arrangement Innlasting OK OK Trykke på «Inviter via mail», «Sjekkliste» OK OK og «Påmeldte studenter» Trykke på «Endre» OK OK 10

12 Endre arrangement Innlasting OK OK Noe treg og dato blir ikke lastet inn Gjøre endringer i feltene OK OK Trykke «Ferdig» OK OK Trykke «Slett» OK OK Inviter til arrangement Innlasting OK OK Fylle inn feltene OK OK Trykke «Send» OK OK Sjekkliste Innlasting OK rødt OK kryss for «ikke utført» vises ikke Trykke på et sjekkpunkt OK OK Trykke (+) OK OK Legg til sjekkpunkt Innlasting OK OK Fylle inn feltene OK OK Trykke «Lagre» OK OK Detaljert sjekkpunkt Innlasting OK OK Gjøre endringer i feltene OK OK Trykke «Lagre» OK OK Trykke «Slett» OK OK Påmeldte studenter Innlasting OK OK Trykke på student OK OK Detaljert student Innlasting OK OK 5.2 Brukertesting Vi fikk følgende tilbakemeldinger fra Accenture sin brukertest. Positivt: Svært nyttig app som dekker akkurat de behovene vi har i dag Kommer til å spare oss for svært mye tid Blir svært bra når integrering med sharepoint kommer Bra og enkelt design Godt at den bygger på samme oppsett vi bruker nå Svært god app som kan bygges videre på Andre kommentarer: 11

13 Noen små bugs her og der, men kommer trolig av rammeverk og ikke implementasjon Litt trege sidebytter Litt vanskelig tilbakemelding til brukeren, og flere ting som kunne vært "automatisk" Medstudenten sin brukertest resulterte i følgende forbedringspotensialer. Datoformatet er ikke konsistent gjennom applikasjonen. Man får en alert når man lagrer og sletter sjekkpunkter, men ikke når man lagrer og sletter arrangementer. Postnummerfeltet kan med fordel endres til et nummerfelt, sånn at det numeriske tastaturet kommer opp når man fokuserer på feltet. Hvis det ikke er noen påmeldte studenter, så trenger man heller ikke å komme inn til en tom liste. Vurder å vise antall sjekkpunkter og antall fullførte på menyelementet (sånn som antall påmeldte studenter). Påkrevde felter kan med fordel markeres med en rød stjerne eller lignende. Validering bør kanskje skje ved endringer i tillegg til blur. Et par av feilmeldingene hang igjen etter å ha valgt element. Vurder å legge inn standardemne på e-post, da mange ikke fyller ut emnefelt i det hele tatt. På en del telefoner har man en menyknapp på telefonen. Vurder å implementere en enkel meny som inneholder standardfunksjoner for den siden man står på, som for eksempel "Nytt arrangement" når man titter på listen over arrangementer. 12

14 6 Konklusjon Testrapporten gir en oversikt på hva som har blitt testet, hvordan testingen ble gjennomført og hva som ble resultatene av dem. Integrasjonstestingen gjort med SoapUI sikret at backend server var stabil og ga konsistente svar. Respons- og funksjonalitetstestene ble gjort for å sikre at navigering, knapper og funksjonalitet i applikasjonen fungerte slik vi ønsket og avdekke eventuelle avvik. Brukertestingen var svært viktig for å sikre at applikasjonen oppfylte kravene og behovene til Accenture. De avdekket også svakheter og resulterte i forslag til løsninger for å gjøre applikasjonen bedre. Ved å dokumentere testingen står fremtidige utviklere bedre rustet til å utvide og forbedre systemet. Kilder: [1] [2] 13