Akseptansetesten. Siste sjanse for godkjenning Etter Hans Schaefer

Transkript

1 Akseptansetesten Siste sjanse for godkjenning Etter Hans Schaefer

2 Akseptansetesting Formell testing med hensyn til brukerbehov, krav, og forretningsprosesser som utføres for å avklare om et system oppfyller akseptansekriteriene eller ikke og for å muliggjøre for brukeren, kunden eller en annen autorisert enhet å fastslå om systemet skal aksepteres eller ikke. [IEEE 610] Systemeierne/brukerne/kunden har med denne testen anledning til å godkjenne eller avvise systemet.

3 Akseptansekriterier Sluttkriteriene som en komponent eller et system må oppfylle for å bli akseptert av en kunde, bruker eller en annen autorisert enhet. [IEEE 610].

4 Akseptansetest Akseptansetesten utføres for å avgjøre om et produkt oppfyller kundens behov, og stemmer overens med spesifikasjonen og annen dokumentasjon. Akseptansetesten er siste mulighet for en kunde å avvise et utilstrekkelig produkt, før det settes i drift. En godt gjennomført akseptansetest kan beskytte kunden mot tap som skyldes dårlige produkter

5 Plass i V-modellen Kundespesifikasjon Akseptansetesting Kravspesifikasjon Systemtesting Design Integrasjonstesting Modul implementasjonmodultesting + MIT

6 Planlegging av testen Akseptansetesten består av fem faser: 1. Bestemme hvor kritisk systemet er (Analyser krav til testen) 2. Bestemme hvilke kvaliteter som skal testes eller evalueres (Spesifiser detaljerte krav til testen) 3. Designe testen 4. Utfør testen 5. Rapporter resultatene De første tre fasene tilhører planleggingen og er først og fremst kundens ansvar. De siste to fasene krever sterk deltakelse av leverandøren.

7 Hvor viktig er systemet? Grad av viktighet bestemmer hvor mye ressurser som skal brukes på testen. ISO standard beskriver 6 hovedkvaliteter: Funksjonalitet Pålitelighet Bruksegenskaper Effisiens (Ytelse) Vedlikeholdsegenskaper Portabilitet (Overføres til andre plattformer)

8 Rammer Beslutte hvilke funksjonskrav som skal testes. Bygger på: Analyse av spesifikasjon, datamodell og liknende dokumenter. Analyse av bruksanvisningen eller annen dokumentasjon Analysearbeidet kan kombineres med en evaluering av de dokumentene. Viktige opplysninger for analysen er: Hvem er de ulike brukerne eller interessentene i systemets funksjoner? Hva er objektene som systemet skal behandler (objektene i virkeligheten eller i datamodellen)? Hva er objektenes livssyklus, altså de tilstandene disse gjennomløper og hva slags overganger mellom tilstandene er mulige? Hvilke funksjoner eller operasjoner skal hver bruker (interessent) ha tilgjengelig?

9 Utarbeide testkrav Beskriv scenarier benytter og dokumenterer de enkelte funksjonene. Beskrivelsene skal vise hvordan en bruker utfører funksjonene. Ta med alle datafelter som gis inn eller listes ut. Om det dukker opp situasjoner som ikke lar seg teste i forbindelse med de tidligere beskrivelser så lag nye scenarier. Sjekk alt som er spesifisert Se etter situasjoner fra virkeligheten som ikke er spesifisert, men allikevel er viktige. Eksempler er: registrering av motstridende opplysninger slutt på papir midt i en jobb som krever utlisting duplisert registrering av opplysninger som ikke skal dupliseres generelle betjeningsfeil ikke kontakt med database, server etc.

10 Hva skal testes alt eller prioritet? Risiko for feil og viktighet i praktisk bruk. Vektlegger at testen skal finne maksimalt antall feil. Prioriterer komplekse systemdeler Deler hvor en vet at det har vært usikkerhet, der det har vært strid, endringer, og der det har vært mye feil i tidligere tester. Slike systemdeler kan (men må ikke) gi trøbbel senere. Finne feilene som er viktigst i drift Teste funksjoner som brukes oftest i praksis. Sjeldne situasjoner og sjeldent brukte funksjoner testes kuttes ut. Det finnes statistiske metoder til å evaluere testen beregne forventet pålitelighet i drift.

11 Valg av testdata For hvert scenario finnes fram til variasjonsbredden i input- og outputdata og det velges forskjellige data som dekker denne variasjonen. Valg av testdata medfører ekvivalensklasseinndeling, grenseverdianalyse, årsaks-virkningsanalyse og bruk av parvise kombinasjoner Hvert scenario bør utføres flere ganger med ulike testdatasett.

12 Klargjøring for test Lage testfiler og testdatabaser Programmere testen for automatisk kjøring Klargjøre testverktøy Alle tekniske oppgavene er et ansvar for leverandøren Utvikling av testsituasjonene og testdata er et kundeansvar.

13 Noen absolutte kvalitetskrav ISO DIS er en internasjonal standard som fastlegger kvalitets- og testkriterier for software pakker. Eksempler derifra er: En softwarepakke skal ha en produktbeskrivelse og en bruksanvisning Produktbeskrivelsen skal inneholde en viss minsteinformasjon, bl.a. funksjoner, konfigurasjon, grensesnitt, grenseverdier, sikkerhet, pålitelighet, krav til kunnskaper hos brukerne. Det skal ikke være avvik mellom spesifikasjon (produktbeskrivelse) og bruksanvisning Bruksanvisningen skal beskrive alle bruker-tilgjengelige funksjoner Bruksanvisningen skal kunne forstås av de brukerne som vanligvis utfører arbeidsoppgavene som produktet er tenkt til. Alle funksjoner som finnes i produktbeskrivelsen og bruksanvisningen skal fungere i den beskrevne form. Brukergrensesnittet skal være enhetlig. Brukeren skal ikke miste kontrollen over produktet. Datatap skal ikke forekomme, ikke en gang ved grensebelastninger. Testen skal inkludere input som uttrykkelig er forbudt. Eksemplene i dokumentasjonen skal inkluderes i testen. Standarden er et godt utgangspunkt for å planlegge en produktevaluering.

14 Gjennomføring av akseptansetesten Testen gjennomføres etter testplanene Kundens medarbeidere kjører testen og vurderer resultatene Det har læreeffekt for kundens medarbeidere Kundens medarbeidere er de beste til å vurdere om systemet oppfyller deres behov. Utføres nye tester underveis skal en senere fortsette der en forlot den planlagte testen. Det bør være mulig å logge hva slags input og output som forekommer under slike ekstra tester. Vanligvis er det ikke nødvendig med slike tester da de fleste situasjonene likevel vil være inkludert i en nøye planlagt test. Feil som oppstår registreres Feil som ikke påvirker det videre testforløpet registreres og testen fortsetter. Hvordan og når de skal rettes bestemmes senere Feil som stopper testen registreres og rettes umiddelbart Etter feilretting bør en kjøre testene på nytt. Best er det å kjøre hele akseptansetesten på nytt

15 Skal produktet aksepteres? Feiltyper Avvik mellom spesifikasjon og program (feil) Avvik mellom behov og program (endringsønsker). Hva sier kontrakten? Godta et maksimalt antall alvorlige og mindre alvorlige feil. Hvis det er flere feil, må testen kjøres om igjen, eventuelt i utøkt form. Hvis det er mange flere feil enn grensen bør produktet forkastes da testing bare finner en relativt konstant del av alle feil (så lenge en ikke øker testingens omfang vesentlig). Selv om de feil som ble funnet blir reparert, vil altså produktet inneholde et proporsjonalt antall flere feil, som da gjør seg gjeldende i drift. Akseptansetesten skal ikke finne feil, men vise at produktet er klar til å settes i drift. Et for høyt antall feil tyder på at leverandøren har gjort en for dårlig jobb. Et feiltall på over 2 feil pr programlinjer vil være alarmerende. Et høyt antall følgefeil etter feilretting vil også være alarmerende

16 Oppsummering Kunden bør forberede testscenarier samtidig med spesifikasjonen. Kundens testansvarlige skal arbeide med test på heltid (i spesifikasjons- og testfasen). Testen gjøres grundig, men skal ikke finne for mange feil. Testen inkluderer vurdering av brukerhåndbok og andre dokumenter. En må avtale tidlig hva som er feil og hva som er endringsønsker. Testen (eller deler av den) bør kjøres om igjen etter feilretting.