I dag snakker vi om :

1. I dag snakker vi om : • Litt om 3. oblig • testing • sluttdokumentasjon • Produktdokumentasjon

2. Om 3.oblig • Testing skal beskrives nøyaktig,presist og som et vitenskapelig forsøk. Hver del av testen må kunne kontrolleres • Del opp i følgende deler • Beskrivelse av testpersonene • Hvordan testpersonene ble intervjuet og mottatt • Hvilke oppgaver de fikk • Hvordan testen forløp • Hvilke konklusjoner dere trakk

3. Testing med papirprototyp. PAPIRPROTOTYP fordi • Kan brukes tidlig i prosessen • Lettere å rette opp feil tidlig • Uhøytidelig, skremmer ikke bruker

4. Ulemper • Mindre realistisk • Vanskelig å se hvordan ting fungerer når det blir så lite fart i programmet

5. Det som kan testes tidlig, er • Prinsipiell vindusdesign • Begreper som brukes • Rekkefølge og flyt • Om brukerens mentale modell stemmer noenlunde med utviklerens ide

6. Vanskelig å teste • Arbeidet BAK skjermbildet • Om alle funksjoner er med • Farger, fonter

7. Viktig i all testing • Hensikten er å finne feil i designet, ikke å bevise at gruppa er feilfri • Man må aldri bruke gruppa selv som prøvepersoner • Det er nødvendig med flere testpersoner fordi folk reagerer forskjellig • Når noen påpeker et problem, bør dere forklare hvordan dere har forholdt dere til det og hvorfor dere retter opp/ikke retter opp

8. TESTING • nødvendig • sjelden perfekt • kan ikke teste alt • testing av programmer kan være en egen jobb • i Norge vanligvis en del av programmerers jobb • Tidlig testing - billige endringer

9. Kan ikke teste alt • teste de riktige tingene • dokumentere hva som er testet • sikre overensstemmelse med kravspesifikasjonen

10. Testing i ulike faser. Formativ testing • Gjennomgang av kyndige mennesker (systemeringsfasen) • Tidlig testing av design(prototyp) • Funksjonell testing • black box-testing • glassbox-testing • prestasjonstesting • både top down og bottom up-testing • Testing av brukergrensesnitt med prøvepersoner – kan brukes i alle faser

11. Summativ testing • for ferdige produkter: sammenligninger

12. Hovedprosjekt-testing: • gjennomgang : sammen med oppdragsgiver/brukere • evt. tidlig testing med papirprototyp • Formative testinger - hele veien • Testing etter hvert • vanligvis bare funksjonell testing • kombinasjon av kontinuerlig bottom up og top down • Viktig å klargjøre hva som er testet (dokumentering)

13. Testplan for funksjonell testing • Finn ut:hva skal testes • Lag plan foran hver aktuell testbit, noter: • formålet med testen • hvilken del av systemet som testes • tid, sted og organisering av testen • hvilke inndata - hvilke resultater ventes-hvilke menyer/veier som skal testes • eventuelle testprosedyrer • Tenk på at planen bør kunne delvis gjenbrukes som rapport!

14. Testing av enkeltbiter - beregninger. Sett inn • en del «vanlige» verdier , + grenseverdier: • særlig store verdier • 0 -1 • del med 0 • negative verdier (-1) • ulovlige/ugyldige verdier • blank • prøv ulike funksjonstaster

15. Testing av enkeltbiter • Sjekk begge sider av if-else-setninger • Prøv ugyldig input - bl.a. ulike funksjonstaster • Prøv å fylle ut et felt med for mange tegn • Sjekk æøå • Store og små bokstaver

16. Testing av helhet • Sjekk overensstemmelse med kravspesifikasjonen • Gå gjennom alle eventuelle veier i menyen • Sjekk eventuelle grenseverdier for hele systemet • Sjekk hva som skjer med «gale» eller ugyldige tastetrykk for hele systemet • Sjekk for virus

17. I dag legges det stadig mer vekt på brukermedvirkning i tester

18. Vurder med prøvepersoner: • hvor lett å utføre oppgavene? • effektivitet • brukertilfredshet • Feilhåndteringen • blir det lett feil? • lett å rette opp feil? • hvor gode er feilmeldingene? • skjermhjelpen • sjekk stikkord • ha helst både innholdsliste og stikkordliste (rokkert!)

19. Brukertesting kan inneholde • Observasjon av brukere • Videofilming • Observasjon mens bruker tenker høyt • Spørreskjemaer • Telling av feil • Hurtighet

20. Test også brukerdokumentasjonen! • Den kan endres mye lengre ut i prosessen enn designet

21. Enhver retting medfører fare for nye feil • Sjekk rettede deler etter rettingen

22. Testrapport= riktig oppsatt testplan med • resultater • drøfting av resultater

23. Sluttdokumentasjonen består av • Prosessdokumentasjon • Kravspesifikasjon • Produktdokumentasjon • m. testdokumentasjon • Brukerdokumentasjon • Kode – på diskett eller hjemmeside

24. Innbinding for papirversjon • Felles perm eller flere separate deler? • Hvis felles perm: • felles tittelside • felles innholdsliste med hoveddeler • lett å finne de enkelte hoveddeler • egen innholdsliste, presentasjon og forord (evt. sammendrag) for hver hoveddel • NB! Innholdsliste, presentasjon og forord er forskjellige for hver del • NB! Pass på at hele utskriften er med

25. Produktdokumentasjon på papir • beregnet på 1) vedlikehold av program • modifiseringer • utvidelser • feilfinning og feilvurdering • 2) faglærer og sensor • forståelse av programmet • vurdering av faglige kvaliteter

26. Leser av produktdokumentasjonen er • datakyndig - men kjenner ikke alle detaljer i alle programmer – og slett ikke oppgaven • veileder har fått en del rapporter, men har neppe full oversikt • sensor kan møte problem og verktøy for første gang

27. Produktdokumentasjon på papir består av: • Beskrivelse av programmet • ( Selve koden, på diskett eller hjemmeside - avtale med veileder ) • Testrapport • HUSK AT PRODUKT-DOKUMENTASJONEN SKAL KUNNE LESES SEPARAT!

28. Hoveddeler av produktbeskrivelsen • Innledende del • Beskrivelse av programmet • Vurdering-drøfting

29. Innledende del • Innholdsliste • Hva er hensikten med programmet, og hvem er det beregnet på?Forkunnskaper? • Hvordan fungerer det i hovedtrekk

30. Beskrivelse av programmet • Programmets virkemåte og prinsipielle oppbygging • Datastruktur - begrunnelse for valg • Viktige trekk ved brukergrensesnittet • Forholdet hovedprogram/ underprogrammer (ofte skjermbilder) • hver hoveddel presenteres kort • EVENTUELLE PROBLEMER SOM ER OPPDAGET VED KONSTRUKSJONEN

31. Andre sider ved programmet • forholdet til maskiner, lagerplass, operativsystemer • spesielle forhold ved implementasjonen • hvis aktuelt: om sikkerhet

32. Vurdering/drøfting (finn egne overskrifter) • Begrensninger (hva som ikke er med ) • Utviklings- og utvidelsesmuligheter • Hva kunne vært gjort annerledes hvis - (NB! I prosessdokumentasjonen kan det også være aktuelt å si hva dere ville gjort annerledes, med den erfaring dere har. Hvis disse to punktene vil bli for like: vurder om stoffet hører hjemme i produktdokumentasjonen eller prosessdokumentasjonen)