Bilag 6 Vedlegg 6 7 Vedlegg - Kundens teststrategi 7 - Kundens teststrategi Saksnummer 13/00203 1 / 29
Versjonshåndtering Versjon Dato Initiert av Endringsårsak 1.0 16.05.2013 Difi Dokument distribuert til tilbydere 2.0 20.08.2013 Difi Endret til ny versjon uten endringer i innholdet Saksnummer 13/00203 2 / 29
Innhold 1 INNLEDNING... 5 1.1 Mål med test... 5 1.2 Referanser... 5 2 TESTMODELL... 5 2.1 Overordnet om metoden... 5 2.2 Produktrisikoanalyse (PRA)... 7 2.3 Risiko og uforutsette hendelser, prosjektrisiko... 8 2.4 Gjennomføringsmodell... 8 2.4.1 Planlegging... 9 2.4.2 Forberedelse...10 2.4.3 Spesifisering...10 2.4.4 Gjennomføring...10 2.4.5 Avslutning...11 2.4.6 Regresjonstesting...11 2.5 Testnivåer/Testfaser...11 2.5.1 Enhets- og integrasjonstest...13 2.5.2 Systemtest...14 2.5.3 Systemintegrasjonstest...15 2.5.4 Akseptansetest...16 3 TESTOBJEKTER...17 4 KRAV OG FORUTSETNINGER TIL TESTMILJØ...17 4.1 Testmiljø...17 5 TESTDEKNING...19 5.1 Testteknikker og testtyper...19 5.2 Testsykluser med testprosedyre...21 6 TESTBASIS...22 7 INNGANGS- OG UTGANGSKRITERIER...22 7.1 Inngangskriterier...22 7.2 Utgangskriterier...22 7.3 Avbrudds- og gjenopptagelseskriterier...22 7.4 Godkjenningskriterier...23 8 TESTDOKUMENTASJON...23 8.1 Testdata...24 9 ORGANISERING OG BEMANNING...24 Saksnummer 13/00203 3 / 29
9.1 Enhets- og integrasjonstest...24 9.2 System og Systemintegrasjonstest...25 9.3 Akseptansetest...26 9.4 Driftsleverandørens Installasjonstest...27 9.5 Feilhåndtering...28 10 STØTTEVERKTØY...28 10.1 Atlassian JIRA...28 10.2 Jenkins...29 10.3 Atlassian Confluence...29 Figurliste FIGUR 1 GRUNNELEMENTER I TMAP 6 FIGUR 2 TMAP S GJENNOMFØRINGSTABELL 9 FIGUR 3 V-MODELLEN 12 FIGUR 4 SMIDIG UTVIKLINGS- OG TESTMODELL 13 FIGUR 5 ID-PORTEN OVERORDNET RELEASEPROSESS 18 Tabeller TABELL 1 REFERANSER 5 TABELL 2 GRUNNELEMENTER I TMAP 6 TABELL 3 BESTEMME RISIKOKLASSE 7 TABELL 4 RISIKO I PROSJEKTET 8 TABELL 5 BESKRIVELSE AV ENHETS- OG INTEGRASJONSTEST 14 TABELL 6 BESKRIVELSE AV SYSTEMTEST 15 TABELL 7 BESKRIVELSE AV SYSTEMINTEGRASJONSTEST 16 TABELL 8 BESKRIVELSE AV AKSEPTANSETEST 17 TABELL 10 LISTE OVER TESTOBJEKTER 17 TABELL 12 TESTTEKNIKKER 21 Saksnummer 13/00203 4 / 29
1 INNLEDNING Dette dokumentet beskriver hvordan test og godkjenning av endringer i forbindelse med driftsavtalen og senere alle endringer skal foregå. Det være seg både ved endring av programvare og eventuelt miljø. Dokumentets struktur er basert på IEEE Standard for Software Test Documentation og TMap i forhold til organiseringen. Målgruppen er prosjektdeltagere i utviklingsprosjekter, systemeiere, tjenesteleverandør, samt andre berørte/involverte i testene. 1.1 Mål med test Hensikten med test er å skaffe opplysninger om og verifisere kvaliteten på driftsløsningen, og kunne vurdere risiko tilknyttet endringer i miljø eller programvare for å gi beslutningsgrunnlag før produksjonssetting i henhold til definerte akseptansekriterier. 1.2 Referanser Dokumentnavn Beskrivelse TMap Next (Bok) IEEE 829-1998 Tabell 1 Referanser Beskriver testmetodikken og tilhørende teknikker og verktøy http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=4578383 Standard som beskriver hvordan testdokumentasjon kan gjøres 2 TESTMODELL 2.1 Overordnet om metoden Testmodellen og strategien baserer seg på testmetoden TMap. TMap er en strukturert testmetode for testing av IT-systemer. Metoden er fleksibel og legger vekt på gjenbruk. TMap består av en generell del, og har i tillegg flere testfaglige områder som er beskrevet spesielt. For enhver leveranse eller endring i driftsmiljø for systemet, vil de mest relevante delene bli tatt i bruk. Dette er beskrevet i de sendere kapitlene i dette dokumentet. TMap metoden likner overordnet på mange andre testmetoder som benyttes. I tillegg gir TMap mange detaljer som er viktige for hele testprosessen. Prosedyrer og planverk understøtter de delene av TMap som tas i bruk samt at de også er basert på IEEE829- testdokumentasjon. De fire essensielle grunnelementene i TMap er formet til denne modellen: Saksnummer 13/00203 5 / 29
Figur 1 Grunnelementer i TMap Grunnelementene kan oppsummeres på følgende måte: TMap er basert på en forretningsdrevet testledelse (BDTM - business driven test management) tilnærming. Dette gir kunden mulighet til å kontrollere testprosessen basert på rasjonelle og økonomiske vurderinger. På denne måten får kunden grepet på testprosessen kommunisert på hans eller hennes "språk". Ved å oversette forretningsmål til testmål oppnår vi riktig testdekning på de rette områdene. TMap gir en full beskrivelse av den totale testprosessen. Ved å splitte testprosessen opp i faser, aktiviteter og leveranser blir det transparent og håndterbart. Tilnærmingen passer derfor for alle tester, både gjennom utviklings- og vedlikeholdsfasen. Koordineringen mellom de forskjellige testnivåene sørger for at testene gjennomføres til rett tid. Sammenhengen mellom oppgaver og ansvarsfordeling mellom leveranseprosjekt og kunde, mellom tester og testleder og mellom testnivåene spiller en vesentlig rolle. TMap inneholder et komplett «verktøysett». Verktøysettet omfatter teknikker (hvordan teste), råd angående infrastruktur (hvor og hva blir testet) og organisasjon (hvem tester). Dette gir en ensartet gjennomføring av de forskjellige testaktivitetene på tvers av prosjektorganisasjonen. TMap er en fleksibel metode og er derfor passende for alle testsituasjoner i de fleste miljøer, som nyutvikling, vedlikehold, fossefalls-, iterativ-, agil-, skreddersydd utvikling eller pakkeprogrammer. Tabell 2 Grunnelementer i TMap For test vil vi benytte testprosessen slik den er beskrevet i TMap. Testprosessen vil normalt være tilpasset en smidig utviklingsmodell med 3-ukers sprinter. Ved endring av driftsmiljø vil det ikke nødvendigvis være slik, og testing vil bli tilpasset dette. Saksnummer 13/00203 6 / 29
For å være sikker på at en test som gjennomføres faktisk har en verdi, må testen designes slik at den tester de egenskaper og deler av testobjektet som representerer en risiko hvis de ikke fungerer tilfredsstillende i produksjon. TMap legger stor vekt på risikovurderinger og testplanen vil være risikobasert. I praksis vil en risikobasert teststrategi bety at det gjennomføres en produktrisikoanalyse (PRA) i planleggingsfasen for å avdekke hvilke testobjekter det knytter seg størst produktrisiko til, og som derfor bør prioriteres under testen. Metodikken legger også stor vekt på at testbasis danner grunnlaget for spesifikasjonsfasen. Testbasis er definert som all dokumentasjon som kan og skal benyttes til utarbeidelse av testspesifikasjoner. Det vil si arkitekturskisser, sekvensdiagram, usecase-modeller og brukerhistorier. En testspesifikasjon kan inneholde sjekklister, testprosedyrer, automatisert tester eller lignende. 2.2 Produktrisikoanalyse (PRA) Formålet med en produktrisikoanalyse er å identifisere hvilken deler av løsningen som bør testes mer enn andre deler. En PRA er et verktøy for å synliggjøre risikoer knyttet til produktet slik at det er mulig å prioritere, planlegge og gjennomføre testen på en effektiv måte. En kvalitativ PRA gjennomføres på følgende måte: 1. Identifisere egenskaper og objekter som skal inngå i produktrisikoanalysen 2. Bestemme konsekvens og sannsynlighet 3. Bestemme risikoklasse 4. Prioritere tester i henhold til risikoklassen Egenskaper og objekter defineres i henhold til egenskapstabellen i kapittel Feil! Fant ikke referansekilden. og liste over testobjekter slik de dokumenteres i de detaljerte testplanene. Deretter gjennomføres det en workshop med representanter fra test, krav og utvikling hvor konsekvens og sannsynlighet bestemmes per egenskap og objekt. Argumentasjonen for fastsatte verdier dokumenteres. Det er dermed prosjektdeltagerne selv som avgjør risikoene og risikoklassene. Risikoklassen defineres så i henhold til følgende tabell basert på identifisering av konsekvens og sannsynlighet: Sannsynlighet Høy Medium Lav Høy A B B Konsekvens Medium B B C Lav C C C Tabell 3 Bestemme risikoklasse Saksnummer 13/00203 7 / 29
Når risikoklassene er bestemt, prioriteres omfang og testdekning i henhold til disse. Skjema for produktrisiko fylles ut på møtet av testleder. Tester Nr Komponent Modul Beskrivelse Endringer i systemet i versjon X Begrunnelse for risikovurdering 1 2 3 4 5 6 7 8 Risikokl.* Tabell 4: mal for produkt risikomatrise 1) Løpenummer 2) Hvilken komponent av løsningen er det 3) Modul 4) Beskriver hva som er risikoen 5) Hva slags endringer har blitt foretatt i eller rundt nevnte modul i denne versjonen (software/hardware) 6) Vurdert risikoklasse ut fra tabell 3 7) Begrunnelse for risikovurdering 8) Hvilke tester skal utføres for å kvalitetssikre 2.3 Risiko og uforutsette hendelser, prosjektrisiko De risikoer som er listet opp her, vil bli observert og vurdert kontinuerlig under testingen. Risikoene rører ved selve gjennomføringen av testen og ikke produktrisiko. Nr Risiko Sannsynlighet (1-5) Konsekvens (1-5) Risikoklasse 1 Utvikling blir ikke ferdig slik at systemtest kan starte til planlagt dato 4 4 16 2 Testmiljø er ustabile og/eller ikke tilgjengelig for systemtest 2 4 8 4 Ressurser kan ikke delta i testing som planlagt på grunn av hastesaker i produksjon/forvaltningen av eksisterende systemer. Tabell 4 Risiko i prosjektet 2 3 6 Ved større endringer i oppsett av løsningen, skal det foretas egen prosjektrisikovurdering også. 2.4 Gjennomføringsmodell TMap sin gjennomføringsmodell består av følgende faser: Saksnummer 13/00203 8 / 29
Figur 2 TMap s gjennomføringstabell Fasene er nærmere beskrevet i de etterfølgende kapitlene. Det er viktig å merke seg at en eller flere faser kan slås sammen avhengig av hvilket testnivå man er på. Dette gjelder spesielt ved testplanlegging og gjennomføring i, under og etter sprintene i konstruksjonsfasen. 2.4.1 Planlegging I planleggingsfasen skal testplanen utarbeides og godkjennes. Testplanen må være ferdigstilt og godkjent før testen starter. Følgende aktiviteter må minimum utføres under utarbeidelse av testplanen: 1. Gjennomføre produktrisikoanalyse 2. Bestemme detaljert teststrategi 3. Overordnet estimering av testarbeidet 4. Definere testobjekter 5. Definere krav til testmiljø 6. Definere krav til testdata 7. Bemanne, organisere og planlegge eventuelt opplæring 8. Analysere risiko for testgjennomføringen Ved ny versjon av tjenesten eller endring i driftsmiljøet vil det utarbeides en kortfattet testplan per iterasjon under konstruksjonsfasen. I tillegg vil det bli utarbeidet lengre testplaner for systemtest, systemintegrasjonstest og akseptansetesten. Disse testplanene vil være basert på oppbygning og struktur i fra denne teststrategien. Leveranse fra planleggingsfasen: 1. Godkjent testplan med resultatet fra produktrisikoanalysen 2. Tilpassede maler 3. Testverktøyet er oppdatert og klargjort Saksnummer 13/00203 9 / 29
2.4.2 Forberedelse I forberedelsesfasen skal testbasis samles, organiseres og analyseres. Testere må gjøres kjent med master testplan, testbasis og testobjekter. Testere blir tildelt testobjekter som de skal jobbe videre med i spesifiseringsfasen. I denne fasen må testmiljøet forberedes og settes opp. I tillegg må testdata hentes fram og eventuelt prepareres. For sprintene under utviklingsfasen vil planlegging, forberedelse og spesifisering utføres som en fase. Hovedleveranse fra denne fasen er: 1. Oversikt over testbasis 2. Testmiljø satt opp og klar for verifisering 3. Testdata klare for innlasting i testdatabaser 2.4.3 Spesifisering I denne fasen skal testbasis benyttes til å utarbeide testspesifikasjoner. En testspesifikasjon skal bestå av en testbetingelse og en testprosedyre. Testbetingelsen utdyper hva som skal testes fra testbasis. I de fleste tilfeller vil de funksjonelle kravene kunne benyttes som testbetingelser. Hver testbetingelse skal være knyttet til minst en testprosedyre. Testprosedyren beskriver hva som skal testes, stegvis, med forventet resultat. Testdata må gjøres ferdig og lastes inn i testdatabasene. I denne fasen skal det også avgjøres hvilke eksisterende tester som skal benyttes som regresjonstester. Under spesifikasjonsfasen skal testverktøyet settes opp slik at det kan benyttes som feillogg. Testloggen benyttes til å dokumentere fremdriften og alle avvik under testgjennomføringen. Testloggen gir et godt grunnlag for å skrive testrapporter og kan også benyttes til å dokumentere og forklare avvik fra tidsplaner under gjennomføringen. Hovedleveranser fra denne fasen er: 1. Testbetingelser og testprosedyrer er utarbeidet og godkjent 2. Testdata ferdig innlastet i testdatabasene 3. Testlogg 2.4.4 Gjennomføring Gjennomføringsfasen for et testnivå starter med et oppstartsmøte. I dette møtet gjennomgås følgende punkter: Saksnummer 13/00203 10 / 29
Oppfyllelse av inngangskriterier Detaljert gjennomføringsplan Ansvarsfordeling Rutiner for melding av observasjoner Spesielle forhold ved dette testnivået Under gjennomføringen av testene er testansvarlig sentral i forhold til oppfølging av planlagte tester. Testere får ansvar for et sett med testobjekter og/eller testprosedyrer og rapporterer daglig til testansvarlig. Det er viktig at testansvarlig dokumenterer alle avvik i forhold til plan i avviksloggen. Testansvarlig skal også rapportere ukentlig til prosjektleder. Rapporten vil bestå av en kort oversikt over gjennomførte tester, feilsituasjonen og en risikovurdering. Denne ukesrapporten vil bli benyttet fra og med systemtestnivå til og med akseptansetesten. I tillegg vil testansvarlig avgi en kort, muntlig rapport i morgenmøtene til utviklingsprosjektet. Analyse av observasjoner er en sentral aktivitet i denne fasen. Testansvarlig er ansvarlig for at dette gjennomføres men det vil i hovedsak være teknisk tester og utviklere som gjennomfører denne analysen i fellesskap. Hovedleveranser fra denne fasen er: 1. Ukentlige statusrapporter 2. Avvikslogg 3. Feillogg 2.4.5 Avslutning Testnivået avsluttes med at testansvarlig utarbeider en testrapport. Testrapporten skal godkjennes av prosjektleder for utviklingsprosjektet og skal distribueres til Systemeier, prosjekteier og andre interessenter. Når alle testnivåer er gjennomført og løsningen er produksjonssatt skal det gjennomføres et møte der de som har deltatt i testingen evaluerer planlegging og gjennomføring av testene. I tillegg skal det skrive en erfaringsrapport med fokus på forbedringspunkter. Til sist skal testprosedyrene gjennomgås og et sett med regresjonstester velges ut for bruk i videre i forbindelse med forvaltning av løsningen. 2.4.6 Regresjonstesting Systemet bygges inkrementelt gjennom en serie av sprinter. Det er derfor viktig å ha automatiserte tester for løpende/periodevis regresjonstest av eksisterende funksjonalitet. Til dette bygges det et sett med Cucumber-tester, som løpende oppdateres og suppleres med nye tester etter hvert som det utvikles ny funksjonalitet eller endres i eksisterende funksjonalitet. 2.5 Testnivåer/Testfaser Testen oppdeles i følgende nivåer: 1. Enhets- og integrasjonstest Saksnummer 13/00203 11 / 29
2. System- og systemintegrasjonstest 3. Akseptansetest med DIFIs egne tester og Leverandørens driftstest Disse testnivåenes plassering i utviklingsforløpet er skissert i nedenstående V-modell: Figur 3 V-modellen Selv om denne V-modellen har sitt utspring i en klassisk fossefallstankegang, er den fullt anvendelig også ved smidig utvikling. Det avgjørende punkt her er at ikke alle elementer trenger å være på samme sted i V'en på samme tid. Deler av systemet kan være under test, mens andre deler er under utvikling, og atter andre er i kravspesifiseringsfasen. Følgende figur forsøker å illustrere dette: Saksnummer 13/00203 12 / 29
Figur 4 Smidig utviklings- og testmodell De enkelte testnivåene er nærmere beskrevet i de følgende kapitlene. 2.5.1 Enhets- og integrasjonstest Enhetstest er en formell test for å avklare om hver enhet (dvs. test av den minste testbare enhet; skjermbilder, batcher, rapporter, brev, komponenter) fungerer uavhengig av andre enheter. Integrasjonstest er en test for å avklare om flere enheter fungerer sammen. Det er ikke alltid hensiktsmessig å gjennomføre integrasjonstesten isolert og den er derfor i denne teststrategien beskrevet sammen med enhetstesten. I dette prosjektet vil enhetstesten i stor grad være automatisert ved hjelp av JUnit (programmerers test) samt at integrasjonstestene i hovedsak vil bli utført av utviklerne. Formål Omfang Formålet med enhets- og integrasjonstestene er å sikre at utviklet kode er i overensstemmelse med detaljert design og oppfyller de kravene som ligger til grunn for detaljerte design. All nyutviklet eller tilpasset kode skal testes, og testdekningen skal være på minst: 80 % for områder med høy risiko 70 % for områder med middels risiko 60 % for områder med lav risiko Som mål for testdekning benyttes kodedekning som angitt ifra Cobertura Dekningsrapporter generert fra Jenkins (nærmere beskrevet i kapittel 10.2). Det er dekning av Conditionals som for å beskrive dekningsgraden. Beskrivelse Utvikler setter opp testcases ut ifra detaljert design. Testcasene kvalitetssikres mot de kravene som designet er ment å skulle dekke. Denne Saksnummer 13/00203 13 / 29
kvalitetssikring gjennomføres av Test. Utvikler gjennomfører enhetstestene og rapporterer resultater, herunder testdekning, til testleder. Det rapporteres ikke defects fra enhetstest. Testmiljø Roller og ansvar Testplan Utviklingsmiljøet og testautomatiseringsmiljøet Utvikler setter opp testcases, gjennomfører test og rapporterer resultater. Test kvalitetssikrer testcasene. For mer detaljer rundt roller og ansvar, se matrise i kapittel9 Enhets- og integrasjonstest gjennomføres etter retningslinjene i dette dokumentet. Det lages ikke egne testplaner for dette testnivået. Rapportering Utvikler rapporterer testresultater til testleder til nærmere avtalte tidspunkter. F.eks. mot slutten av hver sprint. Tabell 5 Beskrivelse av enhets- og integrasjonstest 2.5.2 Systemtest Systemtest er en formell test for å avklare om et system virker som beskrevet i kravspesifikasjon/ løsningsbeskrivelser. Testen vil normalt innbefatte ikke-funksjonelle tester som volumtest, stresstest, ytelsestest, applikasjonssikkerhet, installasjonstest, 'online hjelp'/brukermanual test etc. Formål Omfang Formålet med systemtesten er å verifisere at systemet tilfredsstiller de krav som er stilt i kravspesifikasjonen/løsningsbeskrivelsene. På dette testnivået er det ikke fokus på hver enkelt enhet eller hvert enkelt integrasjonspunkt men på hele løsningen. Testdekning bestemmes av risikovurderingen som gjøres av løsningen. Følgende tester kan kjøres: Brukbarhet/brukervennlighet o Brukergrensesnitt o Forståelig, enkel å lære, effektiv i bruk o Språkvalg Nettleserkompatibilitet Funksjonell test o Riktig Funksjonalitet o Applikasjonssikkerhet o Transaksjonslogging o Støttefunksjoner o Brukeradministrasjon Ytelsestester o Lasttest o Stresstest o Stabiliteststest Flyttbarhet/installasjon o Installasjonstest Saksnummer 13/00203 14 / 29
o Koeksistens/migreringstest Vedlikeholdbarhet o Forvaltbarhet Pålitelighet o Robusthet o Stresstoleranse o Samtidighet o Tilgjengelighet o Feiltoleranse Beskrivelse Testmiljø Roller og ansvar Testplan Det lages testplaner samt testprosedyrer for de områdene som skal testes. Testprosedyrene utarbeides med bakgrunn i testbasis. Systemtestmiljø og testautomatiseringsmiljø hos Difi, ytelsestestmiljø og funksjonelt testmiljø hos driftsleverandør Teknisk tester og testleder er ansvarlig for å planlegge og spesifisere testene. Testen gjennomføres av teknisk tester samt representanter fra brukerstøtte For mer detaljer rundt roller og ansvar, se matrise i kapittel9 Det lages en kortfattet men detaljert testplan Rapportering Tabell 6 Beskrivelse av systemtest Ukentlig rapportering på gjennomførte tester, feilsituasjon og risikovurdering Avsluttende testrapport 2.5.3 Systemintegrasjonstest Systemintegrasjonstest er en test for å avklare om hele løsningen virker både med hensyn på interne og eksterne grensesnitt. Testen vil fokusere på å finne feil i samspillet mellom systemer. Denne testen vil vanligvis bli kjørt i sammenheng med systemtest, og ha felles rapport med denne. Formål Formålet med systemintegrasjonstesten er å sikre at samspillet mellom systemer fungerer som spesifisert. Omfang Beskrivelse Testmiljø Roller og ansvar Integrasjonstest mot 3-part slik som andre offentlige virksomheter Hele verdikjeden skal testes i systemintegrasjonstesten. Testansvarlig planlegger testen sammen med tjenesteeiere, driftsleverandør og evt andre samarbeidspartnere. Det vil være større fokus på ikke-funksjonelle tester som applikasjonssikkerhet, ytelse og stabilitet Systemtestmiljø og testautomatiseringsmiljø hos Difi, ytelsestestmiljø og funksjonelt testmiljø hos driftsleverandør Testansvarlig planlegger og gjennomfører testen i samarbeid med tjenesteeiere og andre samarbeidspartnere Teknisk tester utfører testene Saksnummer 13/00203 15 / 29
For mer detaljer rundt roller og ansvar, se matrise i kapittel9 Testplan Det lages en kortfattet men detaljert testplan som sendes ut til tjenesteeiere og andre samarbeidspartnere. Rapportering Ukentlig rapportering på gjennomførte tester, feilsituasjon og risikovurdering Avsluttende testrapport som sendes ut til tjenesteeiere og andre samarbeidspartnere Tabell 7 Beskrivelse av systemintegrasjonstest 2.5.4 Akseptansetest Akseptansetest er en test for å verifisere at løsningen etterlever kravene som er stilt for leveransen. Det første underkapittelet beskriver testene som også kan omtales som «kundens tester» og er den delen av akseptansetestene som Difi selv utfører. Under står det beskrevet hvordan leverandørens tester ventes utført. Hvilke roller som er involvert og hvilket ansvar disse har vil være forskjellig i de to tilfellene, og det er derfor delt i to separate kapitler. Formål Omfang Beskrivelse Testmiljø Roller og ansvar Testplan Rapportering Formålet med akseptansetesten er å sikre at kunden får verifisert at de krav som er stilt er oppfylt. Kunden er ansvarlig for å velge hvilke tester som skal gjennomføres for å være sikker på at krav som er stilt er oppfylt i leveransen. Testansvarlig kan støtte Kunden i å velge ut tester. Hele verdikjeden skal testes i akseptansetesten. Dette vil involvere tjenesteeiere, driftsleverandør og eventuelt andre samarbeidspartnere. Kunden planlegger akseptansetesten, gjerne sammen med testansvarlig, men ideelt gjennomfører Kunden akseptansetesten selv, men bruk av en egen testansvarlig for akseptansetesten. Akseptansekriteriene vil være sentrale i planleggingen av akseptansetesten. Et utvalg av testprosedyrer benyttet i system- og systemintegrasjonstesten plukkes ut og settes sammen slik at de til sammen dekker akseptansekriteriene. I tillegg bør kunden utarbeide ett sett med nye testprosedyrer for å sikre en bredere og dypere testdekning. Akseptansetestmiljø og verifiseringstestmiljø hos driftsleverandør Kunden har ansvar for å utarbeide testplan og setter opp forslag til hvilke tester som skal gjennomføres. Testen gjennomføres enten av kunden selv og/eller av tester/teknisk tester. For mer detaljer rundt roller og ansvar, se matrise i kapittel 9 Det lages en kortfattet testplan som godkjennes av systemeier. Ukentlig status på gjennomførte tester samt feilsituasjon og risikovurdering testrapporter med konklusjon og anbefaling om godkjenning/underkjenning Saksnummer 13/00203 16 / 29
av testen Tabell 8 Beskrivelse av akseptansetest 3 TESTOBJEKTER Testobjekter skal defineres i de detaljerte testplanene. Testobjektene listes opp i en tabell der risikoklassen også er angitt: Testobjekt Beskrivelse Risikoklas se Tabell 9 Liste over testobjekter Denne tabellen skal alltid fylles ut i de detaljerte testplanene. 4 KRAV OG FORUTSETNINGER TIL TESTMILJØ Alle testmiljø som skal benyttes i denne leveransen skal være hensiktsmessig satt opp for den testen som skal gjennomføres. Jo høyere i V-modellen vi kommer, jo mer produksjonslikt må testmiljøet være for å sikre at testene blir så reelle som mulige. 4.1 Testmiljø Følgende diagram beskriver testmiljø og releaseprosess utarbeidet for ID-porten, og brukt for både MinID og Digitalt kontaktregister i tillegg: Saksnummer 13/00203 17 / 29
Figur 5 ID-porten overordnet releaseprosess Testmiljø Lokasjon Tester som skal kjøres AutoTest Difi Automatiske tester Regresjonstest SyStest, Attest og Difi Funksjonell test IntTest Kontinuerlig testing Verifisering av feilretting før overlevering til installasjon hos tjenesteleverandør Regresjonstest Test 1 Driftsleverandør Systemtest Akseptansetest Regresjonstest Ver2 Driftsleverandør Akseptansetest Systemintegrasjonstest Ytelsestestmiljø1 og Ytelsestestmiljø2 Kommentar Benyttes til automatiske testar med Cucumber. Benyttes i hovedsak til kontinuerlig manuell testing på nye versjonar. Benyttes for gjennomføring av systemtest og akseptansetest. Første miljø der løsningen installeres av driftsleverandør. Verifikasjon av installasjonsdokumentasjon. Brukes for å verifisere endringer opp mot tjenesteeiere. Det finnes to verifikasjonsmiljø hos Driftsleverandør der tjenesteeiere er føderert inn. Ver2 benyttes for test av leveranser. Driftsleverandør Ytelsestest En kopi av produksjonsmiljø (uten failover) som brukes til ytelsestesting av nye versjoner og eksisterende Saksnummer 13/00203 18 / 29
Stage Driftsleverandør Installasjonstest Driftstest Stabilitetstest Produksjonsmiljø Driftsleverandør Installasjonstest produksjonsversjon. Dette miljøet benyttes i all hovedsak av Driftsleverandør til å kjøre de driftstestene de må kjøre i samsvar med driftsavtalen. Produksjonsmiljø for ID-Porten. Driftstest Ver1 Driftsleverandør Verifikasjonstest Miljøet har samme versjon av applikasjonene som i produksjon. Miljø brukt for å verifisere feil som avdekkes i produksjon. Brukes for å verifisere funksjonalitet opp mot tjenesteeiere. 5 TESTDEKNING Testdekning defineres som forholdet mellom det som kan testes og det som er testet i en testfase. Testene skal verifisere at utviklingsprosjektet har nådd målet for leveransen og at akseptansekriteriene er oppfylt. De områdene som er identifisert med høyest risikoklasse vil bli prioritert. Det er kun de testobjektene som blir identifisert i kapittel 3 i de detaljerte testplanene som vil være gjenstand for test. Ved behov, kan integrasjonstest mot andre systemer/prosjekter vurderes. Krav til testdekning for denne leveransen er delvis beskrevet i kapittel 2.5.1 til Feil! Fant ikke referansekilden.. Disse kravene er minimumskrav og det vil være tilfeller der testdekning må være høyere. 5.1 Testteknikker og testtyper Dette kapitlet beskriver hvilke testteknikker som må/kan benyttes for å få konstruert en test hensiktsmessig med riktig testdekning. Testteknikk Beskrivelse Testnivå Whitebox Blackbox Positiv test (konstruktiv test) Negativ test (destruktiv test) Strukturell test. Validering av systemet hvor man tar hensyn til programmodulenes interne struktur, logikk og behandlingsregler. Funksjonell test. Validering av et systems funksjoner ved kun å fokusere på den output som genereres som et resultat av input til systemet, uten hensyn til programmodulenes interne struktur, logikk og behandlingsregler. Tester det som er nytt/skal ha rettet, riktige verdier i feltene, riktig bruk av skjermbilder, dvs. det som forventes skal gå bra. Tester også grenseverdier, gale verdier, gal bruk av skjermbilder, dvs. test av det som ikke bør være mulig å få til. Kodegjennomgang, programmerers test, enhetstest. Systemtest, akseptansetest Alle testnivåer Alle testnivåer Saksnummer 13/00203 19 / 29
Testteknikk Beskrivelse Testnivå Partesting Exploratory testing GUI/Universell utforming Kan utføres som et supplement til strukturert testing med testprosedyrer. En testtype som er mer en tilnærmingsmåte enn en teknikk. Cem Kaner Testing Computer Software (1993), Cem Kaner, Jack Falk, Hung Quoc Nguyen beskriver dette som en test hvor man lærer hvordan testobjektet fungerer, designer testen og tester, på en gang. Test av brukergrensesnittet der man har fokus på leservennlighet og en utforming av sidene med fonter, tekststørrelse og fargevalg som harmonerer med hverandre og følger en definert standard. Kontroll av rettskriving og test av tilgjengelige språk. Alle Alle Systemtest Stresstest Volumtest Ytelsetest Installasjonstest Avbruddstest Test som utføres for å evaluere et testobjekt ved eller utenfor grensene av de spesifiserte belastningskrav (IEEE 610). En av testens mål er å finne det såkalte "knekkpunktet": Når stopper driftsløsningen å fungere? Utføres i samarbeid med driftsleverandør. Test av systemets oppførsel ved prosessering av store datamengder. Utføres i samarbeid med driftsleverandør. Ytelsestesting er et samlebegrep for forskjellige typer tester hvis hensikt er å verifisere ytelsen til et system gjennom blant annet overvåke ressursbruk og responstid. Utføres i samarbeid med driftsleverandør. Det finnes egen strategi for test av ytelse i Difi. For ID-porten har vi valgt følgende typer Lasttesting Stresstesting Stabilitetstesting Test som har til hensikt å teste at installasjon av programvare fungerer i henhold til dokumentasjon. Utføres av driftsleverandør. Programvarens evne til å gjenopprette sitt ytelsesnivå og berørte data etter en feil, og tid og innsats som trengs i den forbindelse. Systemtest Systemtest Systemtest Systemtest, leverandørens installasjons og driftstest Systemtest, Akseptansetest Saksnummer 13/00203 20 / 29
Testteknikk Beskrivelse Testnivå Eksempel på feil: hardwarefeil, driftsteknikerfeil, strømbrudd, mekaniske feil på lagringsenheter, havari i filsystemet/ diskkrasj. Utføres i samarbeid med driftsleverandør. Funksjonell test Livsløpstest Brukervennlighets test Driftstest Sikkerhetstest Lasttest Funksjonell test fokuserer på at systemet har den funksjonalitet som er spesifisert. Test om løsning som er utviklet understøtter arbeidsprosessene som forventet. En test som prøver ut hvor enkelt det er for brukere å forstå og bruke systemet. Med driftstest menes de tester som utføres for å godkjenne at driftsrutinene er gode nok. Testene utformes med henblikk på å prøve ut både maskinelle og manuelle driftsrutiner, samt driftsdokumentasjon. Utføres av driftsleverandør. Test som har til hensikt å avdekke svakheter i sikkerheten til systemet. Utføres som regel av en tredjepart.. Måler oppførselen av en komponent eller et system med økende belastning, for eksempel antall parallelle prosesser og/eller antall transaksjoner for å bestemme hva slags belastning testobjektet kan håndtere. Systemtest, Akseptansetest Systemtest, Akseptansetest Systemtest, Akseptansetest Leverandørens driftstest Systemtest Systemtest, Akseptansetest Stabilitetstest Tabell 10 Testteknikker Måler systemets oppførsel ved belastning over et lengre tidsrom blant annet ved å teste systemets evne til å frigjøre ressurser over tid. 5.2 Testsykluser med testprosedyre Testsykluser med tilhørende testprosedyrer er dokumentert i Jira; http://jira.difi.local/secure/dashboard.jspa. Alle tester som skal lages og kjøres, registreres i Jira som sakstype "Testoppgave". I tillegg merkes sakene med relevant sprint, release og eventuelt komponent hvis aktuelt. Det vil da være mulig å hente ut rapporter fra Jira på status for testplanlegging og gjennomføring. For hver testgjennomkjøring vil det bli satt opp et eget dashboard for testgjennomføring som er tilgjengelig for alle brukere av Jira. Saksnummer 13/00203 21 / 29
6 TESTBASIS Testbasis er all dokumentasjon som benyttes i spesifiseringsarbeidet. I dette prosjektet vil det si arkitekturskisser, sekvensdiagram, usecasemodeller og brukerhistorier. I tillegg er krav slik de er dokumentert i Jira sentrale i utvikling av testdokumentasjonen. 7 INNGANGS- OG UTGANGSKRITERIER 7.1 Inngangskriterier Generelt vil disse inngangskriteriene gjelde for testnivåene system- og systemintegrasjonstest og akseptansetest: Testplan er godkjent Testprosedyrer er kvalitetssikret og klare for gjennomføring Testdata er klargjort Testmiljø klart med deployet kode/ferdig konfigurert Opplæring gjennomført Testere er bestilt Det foreligger en konklusjon på forrige testfase som tilsier at det er mulig å fortsette til neste fase I hver detaljerte testplan vil eventuelle avvik og/eller tillegg til disse generelle kriteriene bli spesifisert. 7.2 Utgangskriterier Generelt vil disse utgangskriteriene gjelde for testnivåene system- og systemintegrasjonstest og akseptansetest: Testdekning er godkjent Alle planlagte tester er gjennomført Avvik fra plan er dokumentert og risikovurdert Statusrapport er ferdigstilt I hver detaljerte testplan vil eventuelle avvik og/eller tillegg til disse generelle kriteriene bli spesifisert. 7.3 Avbrudds- og gjenopptagelseskriterier En test skal stoppes, helt eller delvis dersom: Det avdekkes et vesentlig antall feil som burde vært funnet i tidligere testfase. Tidligere testfase analyseres og kompletterende tester gjennomføres. Det oppdages manglende kontroll med testmiljø eller testdata Det oppdages manglende kontroll med konfigurasjonsstyring Det oppdages feil som umuliggjør gjennomføring av testen. Det avdekkes så mange feil at kravet åpenbart ikke vil bli akseptert Etterslep i feilretting medfører at det ikke er mulig å teste mot siste versjon. Saksnummer 13/00203 22 / 29
Det avdekkes alvorlige mangler eller feil i testbasis og/eller testdokumentasjon Testen kan fortsette (gjenopptas) når årsaken til avbruddet er avdekket og utbedret. 7.4 Godkjenningskriterier For testene i denne leveransen gjelder følgende godkjenningskriterier: Det skal ikke finnes kritiske feil som hindrer videre bruk av systemet, dvs store funksjonelle avvik i produksjon (kategori A). Det skal være maksimum 2 to alvorlige feil som ikke hindrer avtalt arbeidsprosess, men som krever avvik i arbeidsprosesser (kategori B). Det skal totalt ikke gjenstå mer enn 25 --tjuefem- rapporterte feil av kategori C. Testleder vil utarbeide en testrapport og gi sin samlede vurdering og anbefaling vedrørende start produksjon. Akseptansekriterier for hele leveransen er angitt i Jira som overordnede krav. 8 TESTDOKUMENTASJON Hensikten med testdokumentasjonen er: Den skal støtte en effektiv testprosess Den skal videreformidle den informasjon man får ut av testing Det skal dokumenteres hvilke tester som er gjennomført Følgende dokumentasjon skal utarbeides i forbindelse med testene: Detaljerte testplaner for: Systemtest Systemintegrasjonstest mot tjenesteeiere Akseptansetest Driftsleverandørens testplan Testbetingelser og testprosedyrer Testrapporter per testnivå Evalueringsrapport Detaljerte testplaner kan utarbeides med utgangspunkt i denne teststrategien. Beslutning om hvilket format testplanen skal utarbeides i, gjøres av testansvarlig og prosjektleder for prosjektet. Omfang av testen, varighet samt kompleksitet er faktorer som vil være med å bestemme format på testplanen. Ukentlige testrapporter vil bli utarbeidet. Testrapporter per testnivå kan også lages. Evalueringsrapport for hver leveranse skal alltid utarbeides. Saksnummer 13/00203 23 / 29
8.1 Testdata Testdata skal være genererte data som er likt data i produksjon, bortsett fra at personopplysninger er anonymisert. Testdata skal versjonshåndteres og administreres som en del av applikasjonen. Under testing vil det være behov for å resette testdatasettene. Dette gjøres ved å laste inn opprinnelig testdatasett fra SVN. Under system- og akseptansetest vil det være behov for å koordinere testdata mellom flere testere. Dette vil bli håndtert ved at hver tester vil få tildelt et unikt sett med testdata. 9 ORGANISERING OG BEMANNING HUKI H: Hovedansvarlig, U: Utførende, K: Konsultert, I: Informert -matrisen nedenfor angir hvilke roller som har ansvar for hvilke aktiviteter i forhold til test i utviklingsprosjektet i eid-programmet. 9.1 Enhets- og integrasjonstest Aktivitet \ Rolle Test-ansvarlig Testere Brukerstøtte Konfigurasjons -ansvarlig Utviklere Systemeier Teknisk prosjektleder Driftsleverandør Styringsgruppe Utarbeide testplan K U H Godkjenne testplan Følge opp testgjennomføring K U H K Teste tildelte testobjekter K H U I Rette feil K H U I Rapportere fra testgjennomføring HU U I K I Godkjenne testdekning U K H Godkjenne test K H U Skrive testrapport K K U K Konfigurasjonsstyring av kode U H Tabell 14 HUKI-matrise Saksnummer 13/00203 24 / 29
9.2 System og Systemintegrasjonstest Aktivitet \ Rolle Test-ansvarlig Testere Brukerstøtte Konfigurasjons -ansvarlig Utviklere Systemeier Tekniskprosjektl eder Driftsleverandør Styringsgruppe Utarbeide testplan HU K K U I K Godkjenne testplan H U Følge opp testgjennomføring H U U U I I Teste tildelte testobjekter H U U U I Rette feil I K U K H Rapportere fra testgjennomføring HU K I I I I Godkjenne testdekning U K I H Godkjenne test H U Skrive testrapport HU K K K K I Konfigurasjonsstyring av kode U H Konfigurasjonsstyring av miljø hos driftsleverandør K K K HU Deploy til Difi-miljø K I U H Deploy til miljø hos driftsleverandør K I K H U Tabell 15 HUKI-matrise Saksnummer 13/00203 25 / 29
9.3 Akseptansetest Aktivitet/Rolle Test-ansvarlig Testere Bruker-støtte Konfigurasjons ansvarlig Utviklere Systemeier Teknisk prosjektleder Driftsleverandør Styringsgruppe Utarbeide testplan K K K K Godkjenne testplan H U UH K I I Følge opp testgjennomføring U K H I Teste tildelte testobjekter H U U K U I Rette feil I K U K H Rapportere fra testgjennomføring HU K I I I Godkjenne testdekning K K HU I Godkjenne test I I HU I Skrive testrapport U K H I Konfigurasjonsstyring av kode U H Konfigurasjonsstyring av Difi-miljø U H Konfigurasjonsstyring av miljø hos driftsleverandør K K K HU Deploy til Difi-miljø K I U H Deploy til miljø hos driftsleverandør K I K H U Saksnummer 13/00203 26 / 29
9.4 Driftsleverandørens Installasjonstest Aktivitet/Rolle Testansvarlig Testere Brukerstøtte Konfigurasjonsansvarlig Utviklere Systemeier Prosjektleder - Utvikling Drifts-leverandør Styringsgruppe Utarbeide testplan K K K I K H U I Godkjenne testplan U I K H Følge opp testgjennomføring K I I Teste tildelte testobjekter K K I H U H U Rette feil I K U K H U Rapportere fra testgjennomføring I I I H U I Godkjenne testdekning K K H U I Godkjenne test U H Skrive testrapport K I K H U Konfigurasjonsstyring av kode U H Konfigurasjonsstyring av Difi-miljø U H Konfigurasjonsstyring av miljø hos driftsleverandør K K K H U Deploy til Difi-miljø K I H U Deploy til miljø hos driftsleverandør K K I H U Saksnummer 13/00203 27 / 29
9.5 Feilhåndtering Alle observasjoner som gjøres underveis i testingen skal registreres i Jira. Observasjonene kan kategoriseres som: Feil Endring Hvis observasjonen defineres som en endring, håndteres den videre i henhold til prosess for endringshåndtering beskrevet i bilag 6 punkt 6.5. Hvis observasjonen kategoriseres som en feil, skal den klassifiseres i henhold til følgende tabell: Nivå Jira Beskrivelse A Kritisk Må En feil skal kategoriseres som Kritisk dersom hele eller vesentlige deler av tjenesten er utilgjengelig. B Alvorlig Bør En feil skal kategoriseres som Alvorlig dersom hendelsen medfører redusert tilgjengelighet. C - Mindre alvorlig Kan Ønsker Tabell 16 Alvorlighetsgrad på feil En feil skal kategoriseres som Mindre alvorlig dersom hendelsen har liten betydning for brukerne og/eller ikke medfører redusert tilgjengelighet for kunden. Testleder vil i samråd med systemeier og Scrummaster for utviklingsprosjektet vurdere den satte alvorlighetsgraden, prioritere, og tildele feilen videre for vurdering og retting. 10 STØTTEVERKTØY I Difi benyttes ulike verktøy som støtte ved forarbeid og test av nye versjoner som blir nærmere beskrevet i dette kapittelet. 10.1 Atlassian JIRA Difi bruker Jira som deres problem og prosjekt styringssystem for utviklingsprosjekter. Jira benyttes til flere ulike oppgaver: Benyttes for å tildele utviklingsoppgaver og holde orden på hvilken fase hver enkelt utviklingsoppgave er i, og hvem som har ansvar for dem til enhver tid. Benyttes for å logge hendelser under test og under normal drift, frem til eventuell feil er rettet, eller til den er vurdert ikke å være en feil. Se for øvrig kapittelet om feilhåndtering Benyttes for å holde orden på de funksjonelle testene og kjøring av disse Alle oppgaver som er knyttet til en bestemt leveranse, blir merket for enkelt sporing og rapportering. Det settes opp egne «skrivebord» for enkelt å holde oversikt over status til enhver tid. Saksnummer 13/00203 28 / 29
10.2 Jenkins DIFI bruker Jenkins som sin Continuous integration server. Jenkins brukes til fler ulike oppgaver: Rapportering og kjøring av automatiske enhetstester Rapportering og og kjøring av automatiske funksjonelle tester Pakking av leveranser for deployment Jenkins brukes generelt til automatisering av tekniske oppgaver i forbindelse med systemutvikling i Difi. 10.3 Atlassian Confluence Difi skriver all systemdokumentasjon i Confluence, for enkel samhandling og organisering av systemdokumentasjon i systemutviklingsfasen. I Confluence dokumenteres blant annet: Systemarkitektur Prosjekt og testplaner Saksnummer 13/00203 29 / 29