Teststrategi Brønnøysundregistrene IT, ASF og Altinn II

Transkript

1 eforvaltning Teststrategi Brønnøysundregistrene IT, ASF og Altinn II Brønnøysund, 31. mars 2008, HeA/ASF Underlag for utarbeiding av testplaner, også for mottak av Altinn II

2 Teststrategi Teststrategien for BR har tre hoveddeler: Del 1 setter rammebetingelsene for testmiljøet ved BR Del 2 definerer de forskjellige testnivåene som skal utføres og hvordan denne testingen innenfor disse nivåene skal gjennomføres for alle ITutviklingsoppgaver ved BR, gjennom testplanlegging Del 3 beskriver tilnærmingen til strategien Del 1 Del 2 Del 3 Presentasjonen inneholder videre en beskrivelse av nåsituasjonen, som ikke inngår i strategien, men som er utgangspunkt for tilnærmingen. Hvorfor en teststrategi? Nåsituasjonen 2

3 Del 1 Rammebetingelser Organisering og dimensjonering BR skal ha et testmiljø, som kan benyttes av hele organisasjonen, og som er forankret i BRIT og ASF. Testmiljøet skal være tilstrekkelig stort til å dekke parallelle testaktiviteter for interne systemer ved BR og de eksterne systemer BR har forvaltningsansvaret for. Testmiljøet skal være et stort og solid fagmiljø, som skal utvikles til å bli et sentralt tilbud innenfor offentlig forvaltning. Testledere / testansvarlige skal ha prosjektledererfaring og være sertifisert iht. ISTQB Foundation. Metoder, teknikker og verktøy skal tilnærmes et standardisert metodeverk basert på ISO eller IEEE standardene skal tilpasses BR s strategi for systemutvikling skal understøtte ITILtilnærmingen ved BR skal understøtte BR s prosjektstyrings, sikkerhets og kvalitetsstyringsfilosofier/strategier/systemer verktøy, bl.a. for automatisering, skal vurderes ut i fra hensiktsmessighet Standarder Terminologi, definisjoner og begrepsapparat skal tilnærmes norske standarder, basert på ISO/IEEE oversettelsene og DND s terminologiliste 3

4 Del 2 Testplanlegging Testplanlegginen er en overordnet beskrivelse av testarbeidet og ansvarsforhold i løpet av et prosjekt eller i løpet av en periode med flere utgivelser av nye releaser av testobjektet. Den skal som minimum beskrive hvilke testnivåer som skal gjennomføres og hvilke egenskaper som spesielt fokuseres på hvilket testnivå, dekningsgrad, testobjekter (omfang av testen), roller og ansvarsforhold, fremdriftsplan og begrepsapparat. Testplanene skal inkludere : Ev. avvik fra overordnet teststrategi Startkriterier for test Kontrakt Krav for avslutning av test Testobjekter for aktuell test Hvilke egenskaper som skal testes Overordnet teststrategi Angrepsmåte Godkjennings og underkjenningskriterier Avbrudds og gjenopptakelseskriterier Hvilken testdokumentasjon som produseres Testplan Aktiviteter som skal til for å gjennomføre testen Krav og forutsetninger til testmiljø Ansvarsforhold og roller Bemanning og opplæring Risikofaktorer Framdriftsplan (milepæler og aktiviteter) Oversikt over testscript/testcase (trekkes ev. ut i testsyklusbeskrivelse) Testsyklusbeskrivelse Eks, Altinn II Testbetingelse Testscript Testcase 4

5 Del 3 Handlingsplan Organisering og dimensjonering BRIT skal ha minimum tre testledere, serifisert iht. ISTQB Foundation i løpet av ASF skal ha minimum to testledere operative for mottak av Altinn II i perioden I tillegg skal opplæring av testere gjennomføres i samme periode, iht. definerte metoder, teknikker og verktøy. Testmiljøet skal bygges opp til et stort og solid fagmiljø, som også skal utvikles til å bli et sentralt tilbud for tjenesteeierne i Altinnsamarbeidet. Dette skal gjøres bl.a. gjennom samarbeid med andre fagmiljøer i Norge. Metoder, teknikker, verktøy og begrepsapparat. Gjennom Altinn II mottakene, skal et standardisert metodeverk basert på ISO eller IEEE standardene tilnærmes, og tilpasses ITILtilnærmingen i et samarbeid mellom ASF og BRIT. BRIT vil bruke erfaringen fra Altinn II mottakene, for å gjennomføre handlingsplan for BR. Altinn II mottakene vil være begrenset ift. BRIT s totale behov i en systemutviklingsprosess. Gjennom Altinn II mottakene, skal BR s plan for tilnærming til et standardisert begrepsapparat utarbeides. 5

6 Beskrivelse av nåsituasjonen ASF testing i dag Nåsit. ASF BRIT testing i dag ASF testbehov Altinn II ASF Fremdriftsplan 6

7 Hvorfor en teststrategi? ITutviklingsoppgavene utføres i hovedsak ved ITavdelingen (BR IT) og ved Altinn Sentralforvaltning (ASF). I begge miljøer er testplanlegging og gjennomføring resultater av lang utviklingserfaring, men er ikke basert på dokumenterte og standardiserte metoder og teknikker, og heller ikke på en standardisert terminologi. De forskjellige arbeidsprosessene, som inngår i testing er ikke entydig definert, og heller ikke ansvarsforholdet mellom disse. Miljøene har ikke et tilstrekkelig antall sertifiserte testere. Hva er en teststrategi? Krav til testing øker, både fordi utviklings og viderutviklingsbehovene øker, men også fordi kompleksiteten i systemene og antall brukere øker. Konsekvensene ved feil kan derfor bli virksomhetskritiske. Nasjonal og internasjonal utvikling innenfor testing har øket tilfanget på standiserte metoder og teknikker, og terminologien blir etter hvert oversatt til norsk. 7

8 Testing ASF i dag Metodikk Gjennomføring Planlegging av AT Oppfølging/gjennomføring av AT Rapportering 8

9 Testing ASF Metodikk Lite kompetanse på metodikk. Metodikken som benyttes av en er Vmodell. Testene planlegges ovenfra og ned parallelt med utvikling og gjennomføres nedenfra og opp. Kundens ansvar i Vmodellen er å gjennomføre Kundens Akseptansetest (AT). Kunden deltar i brukervennlighetstest og systemtest. Begge testene planlegges og gjennomføres av en. Testleder planlegger og koordinerer deltakelse i systemtest. Kunden bidrar i forbindelse med ytelsestesting, ved å gi input til ytelsestestmodeller. Dette er et punkt som Tjenesteeiere i ASF i større grad har bidratt med input til enn ASF. 9

10 Testing ASF Gjennomføring Organisering av AT I forkant av oppstart AT er det en rekke aktiviteter som gjennomføres av testleder ASF Workshop for å gjennomgå leverandørens testbetingelser (tjenesteeierne og ASF) Opprette Akseptansetestplan og fremdriftsplan som inkluderer både systemtest og akseptansetest. Fremdriftsplan kvalitetssikres også av leverandør. Avklaring av hvem som stiller som testleder fra aktuelle tjenesteeiere Møter og jevnlig dialog med testledere for å planlegge gjennomføring av systemtest og akseptansetest (ukentlig statusmøte, epost, tlfkontakt) Evt oppstartsmøte for å fordele ansvarsområde Følge opp at dokumenter på overordnet design og detaljert design er lest og forstått og avklaringer er gjort mellom ASF, Tjenesteeier og Planlegging, koordinering og gjennomføring av deltakelse i leverandørs systemtest (fortrinnsvis bruke personer hos tjenesteeiere og ASF som også skal delta i Akseptansetest) Testcase, testbetingelser og testskript fra leverandørens systemtest gjenbrukes til en viss grad i forberedelser til akseptansetest Avdekke deltakernes behov for testdata, tilganger osv Ved behov gi generell opplæring i gjennomføring av akseptansetest. Testperiode, rapportering og oppfølging av feil, kategorisering og prioritering av feil osv. 10

11 Testing ASF Gjennomføring Deltakere i ukentlig statusmøte er leverandør, ASF og deltakende tjenesteeiere. Innhold: Overordnet status Gjennomgang av milepælsplan Status for utvikling Status for test (systemtest, akseptansetest) Status ytelsestest Oppfølging kundens medvirkning Budsjettoppfølging Planlagt arbeid Risikomatrise Testleder ASF Testansvarlig Tjenesteeier Testansvarlig Tjenesteeier Testansvarlig Tjenesteeier Testressurser Tjenesteeiere Testressurser ASF ASF stiller med testleder og har hovedansvaret for at AT blir gjennomført. Dette innebærer også koordinering av de ulike testdeltakerne både internt i avdelingen, ulike tjenesteeiere og leverandør. ASF stiller med egne testressurser. Tjenesteeiere i Altinn stiller med egen testansvarlig som har som hovedansvar å organisere og følge opp testingen i egen etat. Testansvarlig hos tjenesteeier rapporterer til testansvarlig i ASF. Tjenesteeiere stiller med egne testressurser 11

12 Testing ASF Planlegging av AT I forbindelse med versjoner, settes det av i størrelsesorden 56 uke til AT. Pr. i dag er hovedaktivitetene til testleder i planleggingsfasen: Opprette og vedlikeholde akseptansetestplan med fremdriftsplan Verifisere rutiner som skal benyttes av Testansvarlig og testressurser Fordele arbeidsoppgaver til testansvarlig hos Tjenesteeiere i forberedelsesfasen Fordele områder Fordele ansvar i forbindelse med utarbeidelse av testskript Fordele ansvar i forbindelse med kjøring av testskript Sikre at feillister er på plass Kvalitetssikre at testskript blir utarbeidet Avdekke behov for bidrag mhp testdata Sikre at deltakerne har alle nødvendige tilganger Delta i ukentlig statusmøte for å gjennomgå status i Akseptansetest. en produserer ukentlig statusrapport med fast agenda som gjennomgås på møtet 12

13 Testing ASF Oppfølging/gjennomføring av AT Hovedoppgaver for Testleder i ASF i forbindelse med AT: Sikre at AT starter opp til fast satt tid Følge opp Testansvarlige hos Tjenesteeiere Rapportere status til i forhold til gjennomførte tester og dekningsgrad Følge opp feillister: Kategorisere feil Sende feil til Følge opp feil som enten er avvist av leverandør eller rettet Hovedoppgave til Testansvarlig hos Tjenesteeier: Koordinere etatens testressurser Følge opp at testing blir gjennomført hos Tjenesteeier Rapportere til Testleder ASF: Hva som er testet Status på testing 13

14 Testing ASF Rapportering produserer testrapport etter endt AT med evt oversikt over omforente feil Dersom alt er ok fra ASFs side, har det blitt praktisert stille aksept. Annet Behov for opplæring i Altinn funksjonalitet for den enkelte tester ikke vært stort fokus på dette til nå Anbefaler generelt deltakere i AT til å delta på leverandørens systemtest for å øke kunnskapsnivå og forståelsen av prosessen videre 14

15 Testbehov Altinn II Mottaksprosjekt Krav til tester Egenskaper som skal testes Metoder / modeller definisjoner Testdata Testplan Drift Applikasjons forvaltning Utvikling Oppsummert 15

16 Altinn II Kravene Drift Tester som inngår Test Forkort. Ansvarlig Bidragsytere Etableringsprosjekt Aksept. periode Godkj. periode Endringer (Ord.drift) *) Installasjonstest IN Kunden v/eksist. leverandør Kunden v/utvikl. og forv. lev. Ytelsestest YT Kunden v/eksist. leverandør Kunden v/utvikl. og forv. lev. Driftstest DT Kunden v/eksist. leverandør Kunden v/utvikl. og forv. lev. Verifikasjonstest VT Kunden Kunden v/utvikl. og forv. lev. Penetrasjonstest PT v/3.part Test av rutiner TR Kunden Kunden v/forv. lev. Test av komp. overføring TK Kunden Kunden v/eksist. leverandør Krise og beredskapsøvelse KB Kunden Akseptansetest AT Kunden ene Godkjenningstest GT Kunden *) en vil sammen med Kunden vurdere hvilke tester som skal gjennomføres ved hasteendringer. Det er ikke krav til Kundens godkjenning ved: hasteendringer som er nødvendige for å ivareta avtalt tjenestenivå eller krav til sikkerhet forhåndsgodkjente enkle standardendringer Kunden har rett til og mulighet til å delta i ens tester, ref. kapittel 3. Spesielt er Kundens rett til å delta i ytelsestest viktig. Koordineringsavtalens Bilag 2 gir en oversikt over de testene som skal gjennomføres ved omfattende og ordinære endringer, hvor også Videreutviklings/Forvaltningsleverandørens tester er inkludert. 16

17 Altinn II Kravene Drift Egenskaper som skal testes Egenskaper IN YT DT VT Tester PT TR TK KB AT GT Teknisk plattform Mottak og installasjon av migreringspakker og verifikasjon at installasjonen av løsningen er vellykket og korrekt. 1) Plattformens egnethet til å drifte løsningen 1) Funksjonalitet på ny driftsplattform fungerer identisk som på eksisterende driftsplattform Samspill med eksterne systemer 1) Samspill med annen programvare 1) Sikkerhet 1) Ytelse (herunder responstider, bruk av Maskinressurser, m.m.) 1) Rutiner, dokumentasjon og rapportering Hendelseshåndtering (kritiske, alvorlige og mindre alvorlige) Problemløsning Endringshåndtering hasteendringer Endringshåndtering enkle standardendringer Endringshåndtering ordinære endringer Produksjonssetting Verifisering av driftsspesifikasjonen (Jf. Bilag 1, pkt. 5.11) Verifisering av rapportering (Jf. Bilag 6, pkt 1.2) Håndtering av krisesituasjoner Kompetanse Evne til å analysere feilsituasjoner/hendelser Evne til å analysere problemer Evne til å implementere endringer (feilrettelser) 1) Testen vil danne grunnlag for Kundens akseptansetest og vil inngå som et akseptansekriterie for å avsjekke at: leverandørens test er gjennomført testrapport er utarbeidet og overlevert alle feil oppdaget i testen er utbedret (jf. Driftsavtalen punkt ) 17

18 Altinn II Kravene Drift Testplanen skal inneholde: Innledning Ev. avvik fra overordnet teststrategi Startkriterier for test (se kap ) Krav for avslutning av test (se kap ) Hvilke egenskaper som skal testes (se kap. 2.4) Godkjennings og underkjenningskriterier (se kap ) Aktiviteter som skal til for å gjennomføre testen Krav og forutsetninger til testmiljø Ansvarsforhold og roller Bemanning og opplæring Risikofaktorer Framdriftsplan (milepæler og aktiviteter) 18

19 Altinn II Kravene Drift Testdata Testdata i ens testmiljø er kundens ansvar. Kunden plikter å produsere anonymiserte testdata for opplærings og testmiljøene og oversende dette til en innen rimelig tid før dataene skal benyttes. Tidspunkt avklares i forbindelse med planleggingen av Etableringsprosjektet. I den grad en har behov for å få tilgang til og behandle personopplysninger fra Kundens systemer i forbindelse med testing av programvaren, skal partene inngå en databehandleravtale, jf. personopplysningsloven 15 og 13. Kunden vil være behjelpelig med å fremskaffe data fra Kundens egne systemer til testformål. 19

20 Altinn II Kravene Drift Fiktive testdata Testdatasett ett til hver tjenesteeier 10 fødselsnummer uten tilknytning til noen enheter 3 fødselsnummer uten tilknytning til noen enheter, men i familie 3 daglig ledere med utenlandsk adresse i ett selskap med utenlands adresse 50 daglig ledere med tilknytning en juridisk enhet 50 styreledere med tilknytning til de samme enhetene som i punktet over 50 nestledere med tilknytning til de samme enhetene som i punktet over 50 styremedlemmer med tilknytning til de samme enhetene som i punktet over 10 daglig ledere i et organisasjonsledd 10 regnskapsførere med 5 klienter eller færre (herunder også de klientene og deres daglige ledere og evt. styreledere) 5 regnskapsførere med mer enn 100 klienter (herunder også de klientene og deres daglige ledere og evt. styreledere) 10 revisorer med 5 klienter eller færre (herunder også de klientene og deres daglige ledere og evt. styreledere) 5 revisorer med mer enn 100 klienter (herunder også de klientene og deres daglige ledere og evt. styreledere) 3 kontaktpersoner i norskregistrert utenlandsk foretak 3 forretningsfører for en enhet 3 kontaktpersoner i kommune 3 sameiere 5 innehavere av enkeltpersonsforetak 5 innehavere av ansvarlige selskaper 5 innehavere av selskaper med delt ansvar 3 representanter for utenlandsk selskap 3 bestyrende redere 3 bobestyrere 3 deltakere med proratarisk ansvar 3 deltakere med solidarisk ansvar 2 komplementar Krav fra riksrevisjonen om å begrense bruken av skarpe testdata Forutsetning for Altinn II anskaffelsen av fiktive testdata er på plass innen overtakelse Generell oppfatning av bruken av skarpe data er for utbredt i Altinn i dag jfr. oppmerksomhet i media de siste månedene om misbruk av fødselsnummer / identitet, m.m. 20

21 Altinn II Kravene Applikasjonsforvaltning Tester som inngår Test Forkor t. Ansvarlig Bidragsytere Spesifiseri ngs fase Utviklings fase Akseptanse periode Leveringsfase Godkjennings periode Brukervennlighetstest BT Kunde og Modultest MT Integrasjonstest IT Systemtest ST med bistand fra Kunde Sikkerhetstest SIT med bistand fra Kunde Ytelsestest YT, Kunden v/ Driftsleverandør, Kunden v/ Driftsleverandør [1] [2] () Installasjonstest IN, Kunde v/driftsleverandør, Kunde v/driftsleverandør [3] [4] Akseptansetest AT Kunde Kunde med bistand fra Driftstest DT Kunden v/ Driftsleverandør Kunden v/ Driftsleverandør Godkjenningstest GT Kunde Kunde med bistand fra [1] en har ansvaret for ytelsestesting av Leveransen i utviklingsfasen (gjøres i Kundens ytelsestestmiljø). [2] Kunden v/driftleverandør har ansvaret for ytelsestest som en del av akseptansetesten og får bistand fra en til evt. feilsøking. [3] en må gjennomføre installasjonstest som en del av utviklingsfasen. [4] Kunden v/driftsleverandør har ansvaret for installasjonstest i hhv. akseptansetestmiljø og produksjonsmiljø. 21

22 Altinn II Kravene Applikasjonsforvaltning Egenskaper som skal testes Tester Egenskaper BT MT IT ST YT IN DT Funksjonalitet Funksjonalitet som beskrevet i kravspesifikasjoner Manuelle rutiner Korrekthet Forskriftsmessighet Sporbarhet for revisjon Sikkerhet Samspill med annen programvare Samspill med eksterne systemer Pålitelighet Modenhet for drift Robusthet Gjenopprettelse etter systemstopp Stresstoleranse Samtidighet Tilgjengelighet Brukskvalitet Opplæringsterskel Forståelighet Effektivitet i bruk Feiltoleranse Universelt utformet Sluttbrukertilfredshet Ytelse Responstider Tid for batcher Bruk av maskinressurser Ressursbruk Vedlikeholdbarhet Analyserbarhet Forutsigelighet Endringsbarhet Testbarhet Flyttbarhet Tilpasningsevne Installerbarhet Standardisering AT GT 22

23 Altinn II Kravene Applikasjonsforvaltning Lav Høyt An alyse og de sign Godkjenningstest Detaljeringsgrad Te stin g Akseptansetest Systemtest Integrasjonstest Brukervennlighetstest Sikkerhetstest Testnivå Høy Brukervennlighets test Utvikling Modultest Lavt Testene utføres på forskjellige testnivå og i henhold til Vmodellen. Testing planlegges ovenfra og ned, og gjennomføres nedenfra og opp. Testarbeidet foregår parallelt med utvikling av Løsningen. Testplanlegging skal starte straks det foreligger krav og løsningsspesifikasjoner og testgjennomføring skal starte med test av små moduler. Enkelte tester kan utføres på flere forskjellige testnivå, noe som kun delvis er illustrert i figur 1. Dette gjelder brukervennlighetstest, sikkerhetstest, ytelsestest, installasjonstest og driftstest. De to sistnevnte skal alltid utføres i forbindelse med migrering av Løsningen til produksjonsmiljø. 23

24 Altinn II Kravene Applikasjonsutvikling Testplanen skal inneholde: Innledning Ev. avvik fra overordnet teststrategi Startkriterier for test (se kap ) Krav for avslutning av test (se kap ) Testobjekter for aktuell test Hvilke egenskaper som skal testes (se kap. 2.4) Angrepsmåte (se kap ) Godkjennings og underkjenningskriterier (se kap ) Avbrudds og gjenopptakelseskriterier (se kap ) Hvilken testdokumentasjon som produseres se kap. 2.6) Aktiviteter som skal til for å gjennomføre testen Krav og forutsetninger til testmiljø Ansvarsforhold og roller Bemanning og opplæring Risikofaktorer Framdriftsplan (milepæler og aktiviteter) Oversikt over testscript/testcase (trekkes ev. ut i testsyklusbeskrivelse) 24

25 Altinn II Kravene Applikasjonsutvikling Testdata Testdata i ens utviklingsmiljø Testdata i ens utviklingsmiljø er ens ansvar. Testdata i ens testmiljø Testdata i ens testmiljø er ens ansvar. I den grad en har behov for å få tilgang til og behandle personopplysninger fra Kundens systemer i forbindelse med testing av programvaren, skal partene inngå en databehandleravtale, jf. personopplysningsloven 15 og 13. Kunden vil være behjelpelig med å fremskaffe data fra Kundens egne systemer til testformål. 25

26 Altinn II Kravene Utvikling Tester som inngår Test Forkortelse Ansvarlig Bidragsytere Spesifiserings fase Utviklings fase Akseptanse periode Leveringsfase Godkjennings periode Brukervennlighetstest BT Kunde og Modultest MT Integrasjonstest IT Systemtest ST med bistand fra Kunde Sikkerhetstest SIT med bistand fra Kunde Ytelsestest YT, Kunden v/ Driftsleverandør, Kunden v/ Driftsleverandør [1] [2] () Installasjonstest IN, Kunde v/driftsleverandør, Kunde v/driftsleverandør [3] [4] Akseptansetest AT Kunde Kunde med bistand fra Driftstest DT Kunden v/ Driftsleverandør Kunden v/ Driftsleverandør Godkjenningstest GT Kunde Kunde med bistand fra [1] en har ansvaret for ytelsestesting av Leveransen i utviklingsfasen (gjøres i Kundens ytelsestestmiljø). [2] Kunden v/driftleverandør har ansvaret for ytelsestest som en del av akseptansetesten og får bistand fra en til evt. feilsøking. [3] en må gjennomføre installasjonstest som en del av utviklingsfasen. [4] Kunden v/driftsleverandør har ansvaret for installasjonstest i hhv. akseptansetestmiljø og produksjonsmiljø. 26

27 Altinn II Kravene Utvikling Egenskaper som skal testes Tester Egenskaper BT MT IT ST YT Funksjonalitet Funksjonalitet som beskrevet i kravspesifikasjoner Manuelle rutiner Korrekthet Forskriftsmessighet Sporbarhet for revisjon Sikkerhet Samspill med annen programvare Samspill med eksterne systemer Pålitelighet Modenhet for drift Robusthet Gjenopprettelse etter systemstopp Stresstoleranse Samtidighet Tilgjengelighet Brukskvalitet Opplæringsterskel Forståelighet Effektivitet i bruk Feiltoleranse Universelt utformet Sluttbrukertilfredshet Ytelse Responstider Tid for batcher Bruk av maskinressurser Ressursbruk Vedlikeholdbarhet Analyserbarhet Forutsigelighet Endringsbarhet Testbarhet Flyttbarhet Tilpasningsevne Installerbarhet Standardisering IN DT AT GT 27

28 Altinn II Kravene Utvikling Lav Høyt An alyse og de sign Godkjenningstest Detaljeringsgrad Te stin g Akseptansetest Systemtest Integrasjonstest Brukervennlighetstest Sikkerhetstest Testnivå Høy Brukervennlighets test Utvikling Modultest Lavt Testene utføres på forskjellige testnivå og i henhold til Vmodellen. Testing planlegges ovenfra og ned, og gjennomføres nedenfra og opp. Testarbeidet foregår parallelt med utvikling av Løsningen. Testplanlegging skal starte straks det foreligger krav og løsningsspesifikasjoner og testgjennomføring skal starte med test av små moduler. Enkelte tester kan utføres på flere forskjellige testnivå, noe som kun delvis er illustrert i figur 1. Dette gjelder brukervennlighetstest, sikkerhetstest, ytelsestest, installasjonstest og driftstest. De to sistnevnte skal alltid utføres i forbindelse med migrering av Løsningen til produksjonsmiljø. 28

29 Altinn II Kravene Utvikling Testplanen skal inneholde: Innledning Ev. avvik fra overordnet teststrategi Startkriterier for test (se kap ) Krav for avslutning av test (se kap ) Testobjekter for aktuell test Hvilke egenskaper som skal testes (se kap. 2.4) Angrepsmåte (se kap ) Godkjennings og underkjenningskriterier (se kap ) Avbrudds og gjenopptakelseskriterier (se kap ) Hvilken testdokumentasjon som produseres se kap. 2.6) Aktiviteter som skal til for å gjennomføre testen Krav og forutsetninger til testmiljø Ansvarsforhold og roller Bemanning og opplæring Risikofaktorer Framdriftsplan (milepæler og aktiviteter) Oversikt over testscript/testcase (trekkes ev. ut i testsyklusbeskrivelse) 29

30 Altinn II Kravene Utvikling Testdata Testdata i ens utviklingsmiljø Testdata i ens utviklingsmiljø er ens ansvar. Testdata i ens testmiljø Testdata i ens testmiljø er ens ansvar. I den grad en har behov for å få tilgang til og behandle personopplysninger fra Kundens systemer i forbindelse med testing av programvaren, skal partene inngå en databehandleravtale, jf. personopplysningsloven 15 og 13. Kunden vil være behjelpelig med å fremskaffe data fra Kundens egne systemer til testformål. 30

31 Testregime Altinn II Plan IT / ASF Gapanalyse Utarbeide teststrategi IT og ASF Opplæring > sertifisering (inkl. terminologi) Ressursallokering / avtaler ASF ASF / Altinn II Utarbeide testplan v09 Foreløpig testregime Foreløpig allokering av ressurser ASF og ALF Gjennomgang av tilbudene mht testing Avklaringer overfor tilbydere Evaluering Forberedelse til mottaksprosjektene Kontraktsetablering Harmonisering evnt. testforbehold ift avklaringer Mottaksprosjektene D & AF (før etableringsprosjektene) Utarbeide testplan med valgt leverandør Etablere testregime sammen med IT / ALF Mottaksprosjekt Utvikling (før etableringsprosjektet) Utarbeide testplan med valgt leverandør Etablere testregime sammen med IT / ALF Mottaksprosjektene / Etableringsprosjektene D & AF Gjennomføre testplan Mottaksprosjekt / Etableringsprosjekt Utvikling AII V1 Gjennomføre testplan Periode Uke Periode xx Akt. Komp.tilf. 31

32 Følgende standarder kan være aktuelle: Standarder BS 79252:1998. Software Component Testing. DO178B: Software Considerations in Airborne Systems and Equipment Certification, Requirements and Technical Concepts for Aviation (RTCA SC167). IEEE :1990. Standard Glossary of Software Engineering Terminology. IEEE 829:1998. Standard for Software Test Documentation. IEEE 1008:1993. Standard for Software Unit Testing. IEEE 1012:2004. Standard for Verification and Validation Plans IEEE 1028:1997. Standard for Software Reviews. IEEE 1044:1993. Standard Classification for Software Anomalies. IEEE 1219:1998. Software Maintenance. ISO/IEC 91261:2001. Software Engineering Software Product Quality Part 1: Quality characteristics and subcharacteristics. ISO/IEC 12207:1995. Information Technology Software Life Cycle Processes. ISO/IEC :1996. Information Technology Software Product Evaluation Part 1: General Overview. Standarder for terminologi, som kan være aktuelle: ISO/IEC 23821:1993. Data processing Vocabulary Part 1: Fundamental terms. ISO 9000:2005. Quality Management Systems Fundamentals and Vocabulary. Oversettelse fra IEEE/ISO og DND s terminologiliste til norsk (HS) 32

33 Definisjoner Det er bygget opp en oversikt over alle brukte definisjoner, med norsk tekst, og med henvisning til den engelske standarden. 33

34 Def. teststrategi Definisjonsliste under utarbeidelse for samtlige begreper innenfor testplanleggingen. 1. versjon til Definisjoner Teststrategien : Et høynivådokument som definerer testnivåene som skal utføres og testingen innenfor disse nivåene for et eller flere prosjekter. Se også hovedtestplan. Overordnet beskrivelse av testarbeidet og ansvarsforhold i løpet av et prosjekt eller i løpet av en periode med flere utgivelser av nye releaser av testobjektet. Den skal som minimum beskrive hvilke testnivåer som skal gjennomføres og hvilke egenskaper som spesielt fokuseres på hvilket testnivå, dekningsgrad, testobjekter (omfang av testen), roller og ansvarsforhold, fremdriftsplan og begrepsapparat. (tidl. DND terminologiliste). Også overordnet testplan. testnivå: (1) En gruppe med testaktiviteter som er organisert og ledet sammen. Et testnivå hører vanligvis til et abstraksjonsnivå i prosjektet (utviklingsmodellen). Eksempler er enhetstest eller modultest, integrasjonstest, systemtest og akseptansetest. Nivåene som skal brukes, tilpasset det gjeldende system, spesifiseres i teststrategien (hovedtestplan). (2) De nivåer eller avgrensede tester som et system eller endringer bør testes gjennom etter gjeldende utviklingsmodell. Nivåene som skal brukes, tilpasset gjeldende testobjekt, spesifiseres i teststrategien. Innenfor hvert enkelt testnivå er det et sett med anbefalte testtyper. (tidl. DND terminologiliste) Eksempel testledelse: Planlegging, estimering, oppfølging og styring av testaktiviteter, typisk utført av en testleder. testplan: Et dokument som beskriver omfang (hva som skal testes), ansvarsforhold, krav til infrastruktur for testingen, framgangsmåte, kriterier, organisering, ressurser og tidsplan for testarbeidet for en test. Planen identifiserer testobjekter, hva som skal testes, testoppgavene og hvem som skal utføre disse, testernes grad av uavhengighet, testmiljøet, testdesignteknikker og testmåleteknikker som skal brukes og begrunnelsen for deres valg, og beskriver risikoene og planene for deres inntreden. Testplanen er en dokumentasjon av testplanleggingen. [etter IEEE 829] 34