I dag snakker vi om : zLitt om 3. oblig ztesting zsluttdokumentasjon zProduktdokumentasjon

Om 3.oblig zTesting skal beskrives nøyaktig,presist og som et vitenskapelig forsøk. Hver del av testen må kunne kontrolleres zDel opp i følgende deler yBeskrivelse av testpersonene yHvordan testpersonene ble intervjuet og mottatt yHvilke oppgaver de fikk yHvordan testen forløp yHvilke konklusjoner dere trakk

Testing med papirprototyp. PAPIRPROTOTYP fordi zKan brukes tidlig i prosessen zLettere å rette opp feil tidlig zUhøytidelig, skremmer ikke bruker

Ulemper zMindre realistisk zVanskelig å se hvordan ting fungerer når det blir så lite fart i programmet

Det som kan testes tidlig, er yPrinsipiell vindusdesign yBegreper som brukes yRekkefølge og flyt yOm brukerens mentale modell stemmer noenlunde med utviklerens ide

Vanskelig å teste zArbeidet BAK skjermbildet zOm alle funksjoner er med zFarger, fonter

Viktig i all testing zHensikten er å finne feil i designet, ikke å bevise at gruppa er feilfri zMan må aldri bruke gruppa selv som prøvepersoner zDet er nødvendig med flere testpersoner fordi folk reagerer forskjellig zNå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 znødvendig zsjelden perfekt zkan ikke teste alt ztesting av programmer kan være en egen jobb zi Norge vanligvis en del av programmerers jobb zTidlig testing - billige endringer

Kan ikke teste alt zteste de riktige tingene zdokumentere hva som er testet zsikre overensstemmelse med kravspesifikasjonen

Testing i ulike faser. Formativ testing zGjennomgang av kyndige mennesker (systemeringsfasen) zTidlig testing av design(prototyp) zFunksjonell testing yblack box-testing yglassbox-testing zprestasjonstesting zbåde top down og bottom up-testing zTesting av brukergrensesnitt med prøvepersoner – kan brukes i alle faser

Summativ testing zfor ferdige produkter: sammenligninger

Hovedprosjekt-testing: zgjennomgang : sammen med oppdragsgiver/brukere zevt. tidlig testing med papirprototyp zFormative testinger - hele veien zTesting etter hvert zvanligvis bare funksjonell testing zkombinasjon av kontinuerlig bottom up og top down zViktig å klargjøre hva som er testet (dokumentering)

Testplan for funksjonell testing zFinn ut:hva skal testes zLag plan foran hver aktuell testbit, noter: yformålet med testen yhvilken del av systemet som testes ytid, sted og organisering av testen yhvilke inndata - hvilke resultater ventes-hvilke menyer/veier som skal testes yeventuelle testprosedyrer zTenk på at planen bør kunne delvis gjenbrukes som rapport!

Testing av enkeltbiter - beregninger. Sett inn zen del «vanlige» verdier, + grenseverdier: ysærlig store verdier y0 -1 ydel med 0 ynegative verdier (-1) yulovlige/ugyldige verdier yblank yprøv ulike funksjonstaster

Testing av enkeltbiter zSjekk begge sider av if-else-setninger zPrøv ugyldig input - bl.a. ulike funksjonstaster zPrøv å fylle ut et felt med for mange tegn zSjekk æøå zStore og små bokstaver

Testing av helhet zSjekk overensstemmelse med kravspesifikasjonen zGå gjennom alle eventuelle veier i menyen zSjekk eventuelle grenseverdier for hele systemet zSjekk hva som skjer med «gale» eller ugyldige tastetrykk for hele systemet zSjekk for virus

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

Vurder med prøvepersoner: zhvor lett å utføre oppgavene? yeffektivitet ybrukertilfredshet zFeilhåndteringen yblir det lett feil? ylett å rette opp feil? yhvor gode er feilmeldingene? zskjermhjelpen ysjekk stikkord yha helst både innholdsliste og stikkordliste (rokkert!)

Brukertesting kan inneholde zObservasjon av brukere zVideofilming zObservasjon mens bruker tenker høyt zSpørreskjemaer zTelling av feil zHurtighet

Test også brukerdokumentasjonen! zDen kan endres mye lengre ut i prosessen enn designet

Enhver retting medfører fare for nye feil zSjekk rettede deler etter rettingen

Testrapport= riktig oppsatt testplan med zresultater zdrøfting av resultater

Sluttdokumentasjonen består av zProsessdokumentasjon zKravspesifikasjon zProduktdokumentasjon zm. testdokumentasjon zBrukerdokumentasjon zKode – på diskett eller hjemmeside

Innbinding for papirversjon zFelles perm eller flere separate deler? zHvis felles perm: yfelles tittelside yfelles innholdsliste med hoveddeler ylett å finne de enkelte hoveddeler yegen innholdsliste, presentasjon og forord (evt. sammendrag) for hver hoveddel yNB! Innholdsliste, presentasjon og forord er forskjellige for hver del yNB! Pass på at hele utskriften er med

Produktdokumentasjon på papir zberegnet på 1) vedlikehold av program ymodifiseringer yutvidelser yfeilfinning og feilvurdering z2) faglærer og sensor yforståelse av programmet yvurdering av faglige kvaliteter

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

Produktdokumentasjon på papir består av: zBeskrivelse av programmet z( Selve koden, på diskett eller hjemmeside - avtale med veileder ) zTestrapport zHUSK AT PRODUKT-DOKUMENTASJONEN SKAL KUNNE LESES SEPARAT!

Hoveddeler av produktbeskrivelsen zInnledende del zBeskrivelse av programmet zVurdering-drøfting

Innledende del zInnholdsliste zHva er hensikten med programmet, og hvem er det beregnet på?Forkunnskaper? zHvordan fungerer det i hovedtrekk

Beskrivelse av programmet zProgrammets virkemåte og prinsipielle oppbygging zDatastruktur - begrunnelse for valg zViktige trekk ved brukergrensesnittet zForholdet hovedprogram/ underprogrammer (ofte skjermbilder) zhver hoveddel presenteres kort zEVENTUELLE PROBLEMER SOM ER OPPDAGET VED KONSTRUKSJONEN

Andre sider ved programmet zforholdet til maskiner, lagerplass, operativsystemer zspesielle forhold ved implementasjonen zhvis aktuelt: om sikkerhet

Vurdering/drøfting (finn egne overskrifter) zBegrensninger (hva som ikke er med ) zUtviklings- og utvidelsesmuligheter zHva 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)