I dag snakker vi om :

Litt om 3. obligtestingsluttdokumentasjonProduktdokumentasjon

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

Testing med papirprototyp. PAPIRPROTOTYP fordiKan brukes tidlig i prosessenLettere å rette opp feil tidligUhøytidelig, skremmer ikke bruker

Ulemper

Mindre realistiskVanskelig å se hvordan ting fungerer

når det blir så lite fart i programmet

Det som kan testes tidlig, er

Prinsipiell vindusdesign Begreper som brukes Rekkefølge og flyt Om brukerens mentale modell stemmer

noenlunde med utviklerens ide

Vanskelig å teste

Arbeidet BAK skjermbildetOm alle funksjoner er med Farger, fonter

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

TESTING

nødvendigsjelden perfektkan ikke teste alttesting av programmer kan være

en egen jobbi Norge vanligvis en del av

programmerers jobbTidlig testing - billige endringer

Kan ikke teste alt

teste de riktige tingenedokumentere hva som er testet sikre overensstemmelse med

kravspesifikasjonen

Testing i ulike faser. Formativ testing

Gjennomgang av kyndige mennesker (systemeringsfasen)

Tidlig testing av design(prototyp)Funksjonell testing

black box-testing glassbox-testing

prestasjonstestingbåde top down og bottom up-testing Testing av brukergrensesnitt med

prøvepersoner – kan brukes i alle faser

Summativ testing

for ferdige produkter: sammenligninger

Hovedprosjekt-testing:

gjennomgang : sammen med oppdragsgiver/brukere

evt. tidlig testing med papirprototypFormative testinger - hele veienTesting etter hvertvanligvis bare funksjonell testingkombinasjon av kontinuerlig bottom up og

top downViktig å klargjøre hva som er testet

(dokumentering)

Testplan for funksjonell testing

Finn ut:hva skal testesLag 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!

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

Testing av enkeltbiter

Sjekk begge sider av if-else-setningerPrøv ugyldig input - bl.a. ulike

funksjonstasterPrøv å fylle ut et felt med for mange

tegnSjekk æøå Store og små bokstaver

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

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

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!)

Brukertesting kan inneholde

Observasjon av brukereVideofilmingObservasjon mens bruker tenker

høytSpørreskjemaerTelling av feil Hurtighet

Test også brukerdokumentasjonen!

Den kan endres mye lengre ut i prosessen enn designet

Enhver retting medfører fare for nye feil

Sjekk rettede deler etter rettingen

Testrapport= riktig oppsatt testplan med

resultaterdrøfting av resultater

Sluttdokumentasjonen består av

ProsessdokumentasjonKravspesifikasjonProduktdokumentasjonm. testdokumentasjonBrukerdokumentasjonKode – på diskett eller hjemmeside

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

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

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

Produktdokumentasjon på papir består av:

Beskrivelse av programmet( Selve koden, på diskett eller

hjemmeside - avtale med veileder )TestrapportHUSK AT PRODUKT-

DOKUMENTASJONEN SKAL KUNNE LESES SEPARAT!

Hoveddeler av produktbeskrivelsen

Innledende delBeskrivelse av programmetVurdering-drøfting

Innledende del

InnholdslisteHva er hensikten med programmet,

og hvem er det beregnet på?Forkunnskaper?

Hvordan fungerer det i hovedtrekk

Beskrivelse av programmet

Programmets virkemåte og prinsipielle oppbygging

Datastruktur - begrunnelse for valgViktige trekk ved brukergrensesnittet Forholdet hovedprogram/

underprogrammer (ofte skjermbilder)hver hoveddel presenteres kortEVENTUELLE PROBLEMER SOM ER

OPPDAGET VED KONSTRUKSJONEN

Andre sider ved programmet

forholdet til maskiner, lagerplass, operativsystemer

spesielle forhold ved implementasjonen

hvis aktuelt: om sikkerhet

Vurdering/drøfting (finn egne overskrifter)

Begrensninger (hva som ikke er med ) Utviklings- og utvidelsesmuligheterHva 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)