Retningslinjer for akseptansetest 1 Akseptansetest i DGI Akseptansetest (AT) er kundens egen test for å verifisere at leveransen er i henhold til bestillingen. Ifølge V-modellen som knytter testnivå til stadier i design og utvikling, skal AT ta utgangspunkt i kravspesifikasjonen med akseptansekrav. Dette blir kundens siste mulighet til å hindre at systemet går i produksjon med feil og mangler. Det er viktig å påpeke at inspeksjon og gjennomgang i samarbeid med leverandør bør skje gjennom hele prosjektperioden for å forebygge problemer så tidlig som mulig. Figur 1: Skisse over ulike test scenarier For å sikre en forsvarlig gjennomføring, skal det utarbeides strategi- og testplaner som behandler risikofaktorer, prioriteringer, rutiner og rapporteringsformer overfor leverandør. Videre må roller og ansvar for testmiljø, testdata, eventuelt testverktøy, testscript og utføring av selve testingen fordeles. Her bør brukerne være sterkt involvert. I utgangspunktet har AT følgende feilnivåer, såfremt ikke annet er avtalt: Nivå Kategori Beskrivelse A Kritisk feil Showstopper, Systemer stopper B Alvorlig feil Enkelt funksjoner ikke som beskrevet. Tidkrevende og ressurskrevende å omgå. Dokumentasjon er misvisende, ufullstendig og kan ikke benytte funksjoner. C Mindre alvorlig Enkelt funksjoner ikke som beskrevet. Tidkrevende og ressurskrevende å omgå. Dokumentasjon er misvisende, ufullstendig og kan lett misforstås D Kosmetiske feil Stavefeil, skriftstørrelse, feil farge etc.
Kriterier som må være oppfylt før AT kan starte: AT planen er godkjent Lavere testnivå fullført ingen utestående kritiske feil (ref figur 1) All dokumentasjon er ferdig Leverandøren må fremvise en testrapport fra egen systemtest Forvaltnings-, drifts-, bruker- og installasjonsdokumentasjon skal foreligge, gjerne 2 uker, før AT starter. Nødvendige programvare lisenser er dokumentert og fremskaffet Alle testdata er fremskaffet Oversikt over hvem som skal bidra i testen og hvilke roller 2 Beskrivelse av nødvendig dokumentasjon Ved overlevering av et IT-system til DGI må det samtidig leveres tilstrekkelig permanent dokumentasjonen til IT-systemet. Det er viktig at denne dokumentasjonen inneholder nødvendig informasjon for å bruke, vedlikeholde og drifte IT-systemet til daglig. Samtidig er det en nødvendighet at informasjonen presenteres på en slik måte at målgruppene forstår innholdet. Denne type dokumentasjon kan deles opp i 4 typer: Forvaltningsdokumentasjonen (også kalt systemdokumentasjon), beregnet på å gi støtte til forvaltning av systemet, dvs. feilretting og annet vedlikeholdsarbeid med systemet. Driftsdokumentasjon, beregnet på å støtte til drift av systemet, dvs. backup, overvåking, initiering av spesielle kjøringer etc. Installasjonsdokumentasjon, er påkrevd for å installere IT-systemet når installasjonen er så kompleks at det trengs en dokumentert plan. Brukerdokumentasjon, beregnet på å gi brukene veiledning i bruk av systemet. 2.1 Installasjonsdokumentasjon Det skal leveres en installasjonsveiledning med figurer, og dokumentasjon av versjoner og avhengigheter til underliggende operativsystemer/api-er. Forslag til hovedkapitler: 2 Installasjonsplan 3 Systemkrav 4 Installasjon av systemet 5 Feilhåndtering 2.2 Forvaltningsdokumentasjon Forvaltningsdokumentasjonen er primært beregnet på systemutviklere og de som skal vedlikeholde IT-systemet. IT-systemet skal beskrives tilstrekkelig detaljert til at forsvarlig systemforvaltning (vedlikehold og videreutvikling) muliggjøres. Forvaltningsdokumentasjonen skal gi innsikt i og forståelse av systemet. Side 2
En tilfredsstillende forvaltningsdokumentasjon er en forutsetning for å sikre de verdier som er lagt ned i utviklingen av systemet. Kvalitetsmessig, effektivt og risikofritt vedlikehold er avhengig av denne dokumentasjonen. Forslag til hovedkapitler 1 : 2 Oppstilling over aktuelle lover, forskrifter, regler, og retningslinjer for det området systemet omfatter 3 Systembeskrivelse: grensesnitt mot andre systemer som angir hvilke data som mottas/leveres og på hvilket format, systemarkitektur, databasebeskrivelse, logisk og fysisk, datafeltbeskrivelse, referanse til data-ordliste, system funksjoner med angivelse av hensikt/bruksområde, inndata, behandlingsregler etc., adgangskontroller og autorisasjon. 4 Sikkerhetskrav 5 Driftsmessige krav og ressurser 6 Systembenyttede standarder 7 Rutiner for systemforvaltning: rutiner for forvaltning, plan for testing, testdata, forventede testresultater, rutiner for oppdatering av dokumentasjon, rutiner for å informere, bibliotekrutiner 8 Begrep 9 Programdokumentasjon 10 Ordliste 2.3 Driftsdokumentasjon Driftsdokumentasjonen er primært beregnet på driftspersonalet. Den er en beskrivelse av systemets oppbygging og driftsmønster for å sikre korrekt drift av IT-systemet, driftsmessig vedlikehold og stabilitet. Driftsdokumentasjonen er grunnlag for korrekt, kontinuerlig og tidsriktig drift av systemet. Operatørene får gjennom denne dokumentasjonen den nødvendige veiledning i å handle riktig ved meldinger fra systemet. Videre skal hensyn i forbindelse med sikkerhetskopiering ivaretas. Handlinger som bør utføres i forbindelse med katastrofer for å redusere skadevirkningene bør beskrives separat. Forslag til hovedkapitler 2 : 2 Ressurser, maskinvare, programvare, utstyr, kommunikasjon 3 Driftsrettet beskrivelser av systemet: avhengigheter til andre systemer, oversikt over driftsoppdrag med tilhørende rapporter og avhengigheter mellom oppdrag, beskrivelse av driftsoppdrag med rapporter og parametere, bestillingsrutiner for oppdrag, beskrivelse av driftsplanleggingssystem 4 Driftsrutiner: kjøreplan, prioritet ved driftsforstyrrelser, ressursforbruk, manuelle kontroller, konsollmeldinger og hvordan disse skal behandles, oversikt over driftsmeldinger, rutiner i forbindelse med feilmeldinger, loggføringer og behandling 1 Tisip Innføring av system av Greta Hjertø 2 Tisip: Innføring av system av Greta Hjertø Side 3
av logger, rutiner for sikkerhetskopieringer, restart og recoveryrutiner, avbruddsrutiner 5 Rapporter 6 Oppfølging og driftsvedlikehold av systemet 7 Rutiner for forvaltning, behandling av endringsønsker, feilmeldinger og reklamasjoner 8 Begreper 9 Retningslinjer vedrørende sikkerhet 10 Ordliste 2.4 Brukerdokumentasjon Brukerdokumentasjonen er primært beregnet på brukerne av systemet. Den skal på en oversiktlig og lettfattelig måte beskrive systemet med tilhørende manuelle rutiner slik det arter seg for brukeren. Hensikten er å sikre korrekt bruk av IT-systemet, og den skal kunne benyttes som oppslagsbok for brukerne. Brukerdokumentasjonen bidrar til korrekt og konsistent bruk av systemet og sikrer den nødvendige datadisiplin. Dette krever at brukeren, i tillegg til å få veiledning i bruken, også kan forstå systemet virkemåte. Brukerdokumentasjonen må derfor inneholde en beskrivelse av systemet, behandlingsregler og sammenhengen med andre systemer. Forslag til hovedkapitler 3 : 2 Oppstilling over aktuelle lover, forskrifter, regler og retningslinjer for det området systemet omfatter 3 Overordnet beskrivelse av systemet, herunder hensikten med systemet, dialogstrukturen, skjermbilde og rapportstruktur, på og avloggingsprosedyrer. 4 Brukerrettet beskrivelse av systemet, eksempelvis: bruksområde, grensesnitt til andre systemer, skjermbilder med forklaring av datafelter og regler for utfylling, menyer og kommandoer, funksjoner og behandlingsregler, regler for retting av feilregistrerte data, feilmeldinger, manuelle kontroller og avstemmingsrutiner, manuelle rutiner, driftsmessige forhold av betydning for brukeren. 5 Lagringsprosedyrer. 6 Rutiner for forvaltning (behandling av endringsønsker, feilrapporter, reklamasjoner) 7 Retningslinjer vedrørende sikkerhet 8 Ordliste 3 Tisip: Innføring av system av Greta Hjertø Side 4
3 Typiske tester i akseptanseperioden Typiske tester som vil være naturlig å legge inn som en del av AT: Tester som skal gjennomføres Installasjonstest Funksjonstest Test av driftsprosedyrer, herunder sikkerhetskopiering Tester som kan gjennomføres etter behov. Dette bestemmes under planlegging av AT. Robusthetstest Integrasjonstest Volum-, kapasitets- og svartidstest Sikkerhetstest Gjennomgang av all dokumentasjon 3.1 Installasjonstest Denne testen skal kjøres med installasjonsdokumentasjon i hånden for sikre at dokumentasjonen som er levert kan brukes ved installasjon av DGI. 3.2 Funksjonstest Testing av It-systemet basert på de funksjonelle krav til løsningen (kravspesifikasjonen). Være sikker på at IT-systemet fysisk fungerer slik det var meningen og alle menyer er tilgjengelig. IT-systemet støtter den generelle industristandarden i det miljøet det skal operere. Eksempelvis i et Windows miljø skal F1 hente opp hjelp, CTRL+C kopierer, etc. 3.3 Robusthetstest Robusthetstesting er definert i hvilken grad IT-systemet fungerer korrekt (som forventet) ved uventet data inn og stress testing. Målet med robusttestingen er å komme frem til test caser og testmiljøer hvor IT-systemet robusthet kan bedømmes. 3.4 Integrasjonstest Integrasjonstest skal finne de feil som ligger i samarbeid mellom systemet og andre eksterne systemer. Moduler på ulike maskiner, i ulike prosesser eller delsystemer etc., hovedsakelig grensesnitt- og kommunikasjonsfil. Integrasjonstest krever en del arbeid med testmiljø. Derfor er det en fordel å ha klare ansvarsforhold for tilretteleggingen. 3.5 Volum-, kapasitets- og svartidstest Test av om systemet kan håndtere maksimalt antall brukere med akseptabel responstid samt systemets oppførsel ved prosessering av store datamengder. 3.6 Sikkerhetstest Test om det lar seg gjøre å komme rundt sikkerhetsmekanismene i systemet og de integrasjoner som er definert. Side 5