Jasmine Garry (s135600) Line Sørensen (s135590) Fredrik Hoem Grelland (s135595) Tor Anders Gustavsen (s127668) 1
1. Forord Dette dokumentet inneholder informasjon og redegjøring av tester foretatt i forbindelse med prosjektet. Testprosessen var en del av implementasjonsprosessen og en kontinuerlig del av utviklingen. Denne rapporten bør leses sammen med tilhørende produktdokumentasjon og eventuelt prosessdokumentasjonen og kravspesifikasjonen. 2
Innholdsfortegnelse 1. Forord... 2 2. Innledning... 4 3. Tester... 4 3.1. Funksjonstesting... 4 3.1.1. Om testmetoden... 4 3.1.2. Tester og resultater... 5 3.1.2.1. Sikkerhet... 5 3.1.2.2. Verktøylinjen... 5 3.1.2.3. Project-view... 6 3.1.2.4. Personal-view... 7 3.1.2.5. Recycle bin... 7 3.1.2.6. Tab pane... 7 3.1.3. Forhold oppdaget under testing... 8 3.1.4. Oppsummering... 8 3.2. Brukertesting... 9 3.2.1. Utførelse... 9 3.2.1.1. Scenario... 9 3.2.1.2. Test-personer... 10 3.2.1.3. Resultater... 10 3.2.2. Konklusjon... 10 3
2. Innledning Brukergrensesnittet har blitt testet nøye, da brukervennlighet var en essensiell del av applikasjonen. Det var viktig for oppdragsgiver at systemet var ryddig og lettfattelig, så vel som at det hadde et solid og innovativt brukergrensesnitt. Vi har hatt papirprototypetest, html-prototypetest og sluttprodukttest. Dette hjalp oss å produsere et intuitivt oppgavestyringsverktøy. En hovedtest av funksjonalitet og stabilitet ble gjort etter at applikasjonen var ferdig. Alle feil som ble funnet under testing er forbedret. Det er viktig å dokumentere testingen man har gjort for å lette arbeidet for de som skal videreutvikle og vedlikeholde applikasjonen, slik at det er lettere å finne eventuelle feil. I denne rapporten har vi hatt fokus på brukertesting og funksjonstesting av sluttproduktet. 3. Tester Dette kapitlet inneholder informasjon om testene som har blitt gjennomført. Hvert underkapittel omhandler forskjellige typer tester, og hver kategori har flere gjennomførte tester. 3.1. Funksjonstesting Det ble testet om funksjonaliteten til Sir Jerky Leap fungerte slik som forventet. Det ble testet underveis i programmeringen, men det er også viktig å teste når applikasjonen fremstår som ferdig. Dette fordi enkelte funksjoner kan ha blitt påvirket av andre endringer i koden. Formålet med testingen har vært å finne svakheter i systemet, og rette på disse, slik at vi kan levere så og si feilfritt system til oppdragsgiver. 3.1.1. Om testmetoden Før vi testet funksjonaliteten til Sir Jerky Leap, lagde vi en tabell med oversikt over hva programmet kunne gjøre. Til dette var kravspesifikasjonen og Use-case-beskrivelsene til stor hjelp, samt dokumenter som har blitt skrevet underveis om funksjonaliteten til Sir Jerky Leap. 4
3.1.2. Tester og resultater 3.1.2.1. Sikkerhet Logge inn Logge inn med feil passord At det fungerte opp mot SirAccess At det blir foretatt en sjekk opp mot databasen. (får opp feilmelding om at enten brukernavn eller passord er feil) 3.1.2.2. Verktøylinjen Se «Personal» Se «Projects» Se «Inbox» Se «Recycle bin» Søke Vise en oversikt over brukers prosjekter og oppgaver Vise en oversikt over eksisterende prosjekter og oppgaver. Vise hvilke elementer som ligger i innboksen At man får se hvilke prosjekter og oppgaver som har blitt slettet. Mulighet for å søke etter prosjekt og oppgave. Skal videreutvikles Skal videreutvikles Skal videreutvikles 5
3.1.2.3. Project-view Oppgave: Add project Legge til prosjekt Edit Title Endre tittelen Add Task Opprette oppgave Add Admin Sette bruker som administrator Sort tasks Sortere oppgaver Save sort tasks Lagre sorterte oppgaver Delete tasks Slette oppgave Move to tab At prosjektet/oppgaven åpner seg i tab TOC (nederste nivå): Delete TOC Slette oppgave m/toc Add text Opprette tekstfil i TOC Save text Lagre tekstfil Edit text Editere tekstfil Delete text Slette tekstfil Open/Close TOC Åpne/lukke alle tekst- og bildeelementer Add image Legge til et bilde i TOC Sort text Endre rekkefølgen på tekstfiler Save sort text Lagre sorterte tekstfiler Assign user Tildele en oppgave til bruker 6
3.1.2.4. Personal-view Tasks with admistrative privileges Tasks I am assigned to Move to tab Vise en liste over hvilke oppgaver man er admin på Vise hvilke oppgaver bruker har blitt tildelt At oppgaven du velger åpner seg i tab Finished/remove Slette prosjekt Ikke implementert 3.1.2.5. Recycle bin Se slettet oppgaver Gjenopprette At man får se en liste over hvilke oppgaver som er slettet At oppgaven legger seg tilbake der den ble opprettet Ikke implementert Ikke implementert 3.1.2.6. Tab pane Oppgave åpnet i tab: Utseendet følger med Fremdeles en fungerende administratorlinjen Sortere på alle nivåer 7
3.1.3. Forhold oppdaget under testing Til tross for at vi testet kontinuerlig under utviklingsperioden, dukket det opp feil i funksjonaliteten. Oversikten over disse viser under: Funksjon/Handling Feil som oppstod Feilmelding Sortere en tom oppgave Opprette TOC «Edit title» på oppgave i tab «Add task» på oppgave i tab «Open in tab» Det gikk å flytte den tomme oppgaven en gang, deretter låste listen seg. Funksjonen «Add task» var tilgjengelig etter å ha opprettet en TOC,og trykket brukeren på «Add task» ble TOC'en slettet Navnet på oppgaven ble ikke endret i «Project-view» eller i tab-tittelen Det ble ikke opprettet en oppgave. Utseendet ble ikke det samme i ny tab som i visningen brukeren var når «move to tab» ble trykket $(element) has no properties [Break on this error] return $(element).recursivelycollect('nexts ibling'); Feilene har blitt utbedret og testene ble utført på nytt for å forsikre at det var vellykket. 3.1.4. Oppsummering Testing har vært utført kontinuerlig under utviklingen i tillegg til rett før innlevering av prosjektet. Vi har utbedret alle feil som testene har avdekket. Til tross for dette er det viktig å merke seg at det ikke nødvendigvis betyr at applikasjonen er feilfri, men vi har ikke funnet noen feil og mangler som ikke er forbedret. 8
3.2. Brukertesting Det ble testet om applikasjonen oppførte seg slik som brukerene forventet. Vi begynte med en papirprototype som senere ble utviklet til en HTML-prototype, men det er som nevnt tidligere sluttproduktet vi har testet i denne rapporten. Vi har testet om applikasjonen var lettfattelig, slik at brukerne forstod hvordan man skulle gå frem for å utføre spesifiserte handlinger. Vi har dokumentert hva brukerene brukte unormalt lang tid på, hva brukeren ikke forstod og hva de forstod med en gang. 3.2.1. Utførelse Vi har testet for alle funksjonene som er mulig å utføre. Det viktigste er hvordan systemet oppleves som helhet, og at funksjonene er lettfattelige. 3.2.1.1. Scenario En bruker ønsker å utvide et prosjekt ved å legge til underoppgaver og deretter jobbe på prosjektet. Vi har testet for disse funksjonene, da de var ferdig implementert når vi utførte testen; Logg inn som fredrik med passord jalla Åpne project-visningen. Opprett tre underoppgaver, med tittelene «en», «to» og «tre» under prosjektet «arbeidsplanlegging». Opprett en underoppgave til oppgave «en». Legg til tekst i oppgave «to» og kall den «tester». Legg til en setning i tekstelementet «tester» og lagre det. Legg til nok en tekst i oppgave «to», og kall den «tester igjen». Åpne og lukke begge tekstene samtidig. Legg til bildet «note» som ligger på skrivebordet, gi bildet tittelen «bilde». Assign Line til oppgave «to». Sorter oppgave «en», «to» og «tre», slik at «en» er i midten. Endre tittelen til oppgave «tre» til «fire». Slett oppgave «fire». Åpne oppgave «en» i tab. 9
Gå tilbake til prosjekt-visningen. Åpne personal-visningen. Åpne en oppgave du er administrator på i tab. 3.2.1.2. Test-personer Testperson 1: Alder: 23 år Bakgrunnskunnskap: Ansatt hos Aptoma AS, og mulig sluttbruker. Bruker de produktene firmaet bruker i dag. Har ikke sett prototyper, hørt ideene eller sett sluttproduktet til Sir Jerky Leap før testen. Testperson 2: Alder: 34 år Bakgrunnskunnskap: Ansatt hos Aptoma AS, og mulig sluttbruker. Bruker de produktene firmaet bruker i dag. Har ikke sett prototyper, hørt ideene eller sett sluttproduktet til Sir Jerky Leap før testen. 3.2.1.3. Resultater Testpersonene ble forklart testens formål og ble bedt om å utføre et og et punkt i scenarioet. Begge kom seg i gjennom det greit, uten store problemer. De synes begge at det var et bra og behagelig brukergrensesnitt, men noen småkommentarer hadde de. Kritikken som ble gitt var: Fonten er for liten Ikonene er lite intuitive og det må være tilhørende tekst til alle ikonene Det er et rødt kryss for både slett og lukk. Flytte admin-nøkkel foran tittel, istedetfor at den står mellom to knapper. Accept-box, håndsom musepeker over hele. Vi var helt enig i det som ble sagt og prøvde så godt vi kunne å forbedre dette. 3.2.2. Konklusjon Det var på forhånd blitt testet med papirprototyper og HTML-prototypen da vi satt i gang med å implementere designet av brukergrensesnittet. Disse testene har hjulpet oss å utvikle et godt system med gode funksjonaliteter som er selvforklarende og dermed enkle å forstå for brukerne. Under 10
sluttprodukttestingen ble vi gjort oppmerksomme på ting testpersonene mente vi burde forbedre. Etter disse endringene ser vi på Sir Jerky Leap som et ennå bedre produkt. 11