Prosjekt nr. 2011 22 Testrapport Hovedprosjektets tittel Implementering av plugin og utvikling av wizard for Det Norske Veritas Prosjektdeltakere Magnus Strand Nekstad s156159 Jørgen Rønbeck s135779 Dato 15. Mai 2011 Antall sider 9 Intern veileder Steinar Johannesen Oppdragsgiver Det Norske Veritas DNV Software (www.dnvsoftware.com) Kontaktperson Ole Jan Nekstad 1
1. Testdokumentasjon 1.1 Forord Denne testrapporten har som formål å beskrive all testing som er utført på Sesam Showroom, både under utvikling og etter at produktet er ferdigstilt. Dette dokumentet vil gi en oversikt over feil vi har kommet over og om det ble løst eller ikke. Testing av selve systemet er blitt gjort under utvikling, dette er fordi vi ville bli ferdig med en del om gangen slik at vi slipper å ta alle løsninger på slutten. Alle feil som er blitt funnet under testing fra våre brukere er blitt løst og forbedret. Testingen vil hovedsakelig gå på kodingen vi har gjort, testing av alle funksjonene og diverse design/layout. 2
2. Innholdsliste 1. Testdokumentasjon... 2 1.1 Forord... 2 2. Innholdsliste... 3 3. Innledning... 4 4. Funksjonalitetstest... 5 4.1 Hvem har testet... 5 4.2 Litt om testpersonene... 5 4.2.1 Testperson 1:... 5 4.2.2 Testperson 2:... 5 4.2.3 Testperson 3:... 5 5. Hva vi ønsket å teste... 6 6. Hvordan ble testingen utført?... 6 6.1 Følgende oppgaver ble gitt testpersonene... 6 6.2 Tilbakemelding og endringer fra testing... 6 6.3 Oppståtte problemer underveis... 7 6.4 Eksempler på feil/problemer... 7 7. Testrapporter... 8 7.1 Testrapport fra 3D Gallery... 8 7.2 Testrapport fra Predefined Models... 8 7.3 Testrapport fra Selfdefined Models... 9 3
3. Innledning Å levere en feilfri oppgave til en oppdragsgiver er veldig vanskelig å oppnå, det kommer alltid til å være et eller annet som oppstår, om det skal være ved ytelsestesting eller stresstesting. Derfor er det viktig å dokumentere hvordan og hva vi har testes i Sesam Showroom, slik at det senere kan være enklere å teste på andre saker enn det som allerede er testet på for oppdragsgiver. Slik at vedlikehold skal være lett og i tilfelle de finner eventuelle feil ved siden vår. Gruppen vår har valgt å bruke en løs type iterativ utvikling av Sesam Showroom, at vi blir ferdig med del for del og ikke jobber med alle deler på en gang. Vi vil si at valget vårt er ganske løst basert ut ifra at de forskjellige delene ikke er avhengige av hverandre og derfor kan vi også jobbe med en annen del mens vi venter på tilbakemelding på den første delen for eksempel. I de fleste prosjekter er det høyt fokus på testing på funksjonalitet, dette var selvfølgelig intet unntak for oss heller. I starten var det testing innad i gruppen som gjaldt, vi som har kjennskap til kode og programmeringsspråket som er brukt. Etter hvert åpnet vi også for testing utenfra for å få et friskt syn på oppgaven vår, dette er veldig lurt siden ikke alle har samme kompetanse og kjennskap til det vi utvikler. Etter hvert som funksjonaliteten ble testet, ble det også åpnet for testing av brukervennlighet og design. Kom vi til å oppnå de ønsker som oppdragsgiver hadde satt til oss? Derfor sendte vi testoppgaver til 3 testpersoner utenfra, for å se hva slags tilbakemelding vi ville få tidlig i prosjektfasen. Vi fikk mange positive tilbakemeldinger, men også tilbakemeldinger om ting som ikke var som de skulle. Med andre ord, takket være testpersonene våre og den testingen som er blitt gjort, er designet basert på deres tilbakemeldinger. 4
4. Funksjonalitetstest Under funksjonalitetstestingen vil vi teste på brukervennlighet, funksjonalitet og tilgjengelighet. Testingen vil foregå i tre deler, en for 3D gallery, en for Predefined Models og en for Selfdefined Models. Under hver av de tre delene er det igjen underdeler, der den ene delen vil gå på funksjonalitet og brukervennlighet, og den andre delen vil være på kodingen bak sidene. All testing av kode har blitt gjort ved å sjekke om hver enkelt funksjon gjør det den skal, eks: det har blitt testet om de riktige filene har blitt vist ved valg av input eller om den riktige filen er tilgjengelig for nedlastning eller lesing. 4.1 Hvem har testet Vi har valgt oss 3 personer med helt ulik bakgrunnskunnskap innen data. De personene som har testet systemet er: 1. Ole Jan Nekstad, kontaktperson fra DNV 2. Kristina Eckholdt, husøkonomistudent ved HiAk 3. Mathias Rasmussen, datastudent ved HiST 4.2 Litt om testpersonene 4.2.1 Testperson 1: Den første vi ga ut betaversjoner til var kontaktperson fra DNV, Ole Jan Nekstad. Det er han som er ansvarlig for å gi oss den informasjon vi trenger for å vite hva DNV vil oppnå med oppgaven. Ut i fra hva vi vet om at DNV er et firma som krever middels til høy kompetanse og hvor Ole Jan bruker PC mer enn 7 timer daglig i arbeid og har meget god erfaring bruken av PC medfører. Ut ifra dette har vi kommet frem til at Ole Jan er over en gjennomsnittlig databruker. 4.2.2 Testperson 2: Den andre personen vi ga ut testversjoner til, er Husøkonomistudent ved Høgskolen i Akershus, nå Høgskolen i Oslo og Akershus, Kristina Eckholdt. Hun benytter PC daglig, har erfaring med bruk av Word, Excel, Internet Explorer og lignende programmer tilgjengelig på PC. Ut ifra samtaler med Kristina har vi kommet frem til at hun bruker PC mellom 6 og 8 timer hver dag, dette gjelder da for skole og arbeid. Vi har kommet frem til at hun er en gjennomsnittlig databruker. 4.2.3 Testperson 3: Den tredje personen vi ga ut testversjoner til, er datastudent ved Høgskolen i Sør-Trøndelag, Mathias Rasmussen. Han jobber med data daglig i sitt skolearbeid og på fritiden. Ut ifra samtaler med han har vi kommet frem til at han bruker PC hver dag opp til 8 timer daglig, dette gjelder skole og arbeid. Han har faglig kompetanse med programmering og koding, samt gode kunnskaper innen bruken av PC generelt. Vi har med dette konkludert at han er over gjennomsnittlig databruker. 5
5. Hva vi ønsket å teste Vi ønsket å teste funksjonaliteten og brukervennlighet til sidene for å se om testpersonene klarte å navigere og bruke de enkelte funksjonene uten problemer. Det var ønskelig å se om det oppsto feil som vi som har programmert siden har oversett. Vi hadde fokus på at brukeren klarte å navigere seg frem, alle menyer og lignende fungerte og at det ble gitt riktige feilmeldinger når brukeren gjorde en feil. 6. Hvordan ble testingen utført? Testingen gikk hovedsakelig ut på at personene skulle finne frem til forskjellige deler av sidene og så finne frem til en utvalgt visning/fil. Dette var hovedsakelig fra 3D gallery, predefined og selfdefined. Testpersonene fikk full tilgang til sidene underveis som de ble utviklet, dette var for at de skulle ha muligheten til å teste alle mulige funksjoner som var å finne. Grunnen til at vi lot de få full tilgang var for at de skulle få teste alt samtidig som vi utviklet del for del, slik at vi kunne reparere problemer som oppsto underveis, istedenfor å ta alt på en gang til slutt. 6.1 Følgende oppgaver ble gitt testpersonene 1. Finn frem til 3d gallery, predefined og selfdefined sidene. 2. Sjekke at alle linker stemmer overens for alle sider. 3. Naviger og velg vilkårlige filer for visning i 3d plugin. 4. I predefined skal det velges 2 forskjellige case filer og alle verdiene skal testes på layout og om det er korrekt fil som vises. 5. I selfdefined skal det velges to forskjellige cases og her skal det skrives inn 2 selvvalgte verdier. Skal også testet på om verdier som ikke er mulige blir avvist av siden. I tillegg skal det sjekkes at riktige filer blir vist og at alle filene er tilgjengelig for nedlastning. 6. I About siden, sjekk at alle linker fungerer som de skal. 6.2 Tilbakemelding og endringer fra testing Alle testpersoner fikk tilsendt link til siden og de testet hver for seg. Tilbakemeldingene ble notert ned og alle sammen bekreftet at de fleste funksjoner på sidene fungerte som de skal, men også noe som ikke fungerte som de skulle. Dette var for eksempel filer som ikke var tilgjengelig for nedlastning og validering på inputfelter som var gal. Dette har blitt rettet på og det har blitt sendt ny versjon for testing til samtlige testbrukere. Alle 3 hadde gitt tilbakemelding på at det mer luft mellom linjene var noe som var nødvendig for at det skulle være enklere å lese på siden. Det måtte også komme frem en beskjed på de sidene som hadde 3D plugin, at det krevdes å kjøre Internet Explorer. Dette kom ikke klart frem i starten av utviklingen. Det er også blitt rapportert om skrivefeil i teksten, under testingen er det også blitt brukt norske ord og beskrivelser, da siden skal være på engelsk er dette også gitt tilbakemelding på. Det er også blitt rapportert om tekst som ligger over andre tekstfelter, dette har ikke vi lagt merke til, men Ole Jan bruker en eldre versjon av Internet Explorer som tolker dette annerledes. Dette er viktig siden DNV sine brukere har mye kompetanse og ofte bruker denne versjonen av IE, dette er blitt rettet opp i. 6
6.3 Oppståtte problemer underveis Underveis mens vi har kodet har vi testet og debugget koden vår for å sjekke at alt fungerer som det skal. Feil som har oppstått underveis har hvert av både enkle feil som en skrivefeil i koden til ting som at koden rett og slett ikke fungerer og vi har måttet velge en annen løsning. 6.4 Eksempler på feil/problemer Feil i if-setninger Under kodingen så har det hendt at vi har skrevet feil tegn. Det har som regel hvert < og > som har blitt skrevet feil vei slik at det vises flere filer en det som skal vises. Det har også vært feil verdier som er blitt brukt i validering av input, for eksempel at vi bruker fra 30 til 50 istedenfor 30 til 60. Menyer som ikke fungerer, feil link så man havnet på andre sider enn planlagt, eller at de rett og slett ikke var kodet med adresse. Bilder som ikke er riktig, verken om de dukket opp, om det var feil bilde eller størrelse. Ved koding av layout støtte vi på flere problemer, et av de største problemene vi kom over var når vi hadde planer om å bruke dotnet server, da hele designet ble et stort rot og ingen ting stemte overens lenger. Det verste problemet som oppsto var ved bruken av dotnet, hadde vi ikke lenger administratortilgang på server siden dette var en skoleserver. Siden 3D pluginen trenger administratorrettigheter for å få tilgang til riktig filbane for filer var dette et stort problem. 7
7. Testrapporter Legg merke til at det står OK på alle tester som er gjort nedenfor, dette er på grunn av at det er de siste testene som ble kjørt. Som vi da ser, fungerer alle funksjonene som er testet på slik de skal og da er vi fornøyde med det som er utført. 7.1 Testrapport fra 3D Gallery Funksjon Test Kommentar Menyer Sjekk at alle menyer fungerer Ok og at man bli henvist til korrekt sted Filer Sjekk at korrekte filer blir vist Ok i hver meny Fil nedlastning Test at alle filene er Ok tilgjengelig for visning Plugin i nettleser Sjekk at nettleseren automatisk sier i fra om pluginen er installert Ok 7.2 Testrapport fra Predefined Models Funksjon Test Kommentar If-setninger Sjekk at riktige filer blir åpnet Ok ved forskjellige input. Åpning av plugin Sjekk at pluginen åpner seg Ok når man velger verdier. Menyer Se til at alle menyene Ok fungerer og vises på korrekt måte. Knapper/valg Se til at alle knapper som Ok ligger under hver enkelt meny fungere. Filer Sjekk at når verdier blir valgt Ok vises riktig fil. Plugin i nettleser Sjekk at nettleseren sier i fra Ok om plugin er installert Feilmeldinger Det skal vises riktige og forklarende feilmeldinger Ok 8
7.3 Testrapport fra Selfdefined Models Funksjon Test Kommentar If-setninger Sjekk at if-setningene åpner Ok de riktige displayene. Åpning av plugin Sjekk at pluginen åpner seg Ok når man velger verdiger. Menyer Se til at alle menyene Ok fungerer og vises på korrekt måte. Inputbokser Sjekk at man kan skrive i alle Ok inputbokser Valg knapp Sjekk at submit-knappene Ok gjør det de skal. Filer Se til at riktige filer blir vist Ok og at de kan lastes ned. Validering Sjekk at validering av input Ok er korrekt og fungerer Plugin i nettleser Sjekk at nettleseren sier i fra Ok om plugin er installert Feilmeldinger Det skal vises korrekte og svargivende feilmeldinger Ok 9