Idékatalog Planlægning og brug af test i statslige it-projekter Januar 2014
INDHOLD 1. INDLEDNING...1 2. TYPER AF TEST...2 3. PLANLÆGNING AF TEST I FASERNE...6 3.1 IDÉFASEN...6 3.2 ANALYSEFASEN...7 3.3 ANSKAFFELSESFASEN...7 3.4 GENNEMFØRELSESFASEN...9 3.5 REALISERINGSFASEN... 11 4. YDERLIGERE INFORMATION VEDRØRENDE TESTMETODER OG -TYPER... 12
1. Indledning Formålet med idékataloget er at give inspiration til og indsigt i testtyper og planlægning af test, og hvornår forskellige typer af test er relevante at bruge i de forskellige faser for et statsligt it-projekt. Idékataloget er henvendt til statslige it-projektledere og vil kunne inspirere projektledelsen i arbejdet med at planlægge og gennemføre test. Forudsætningen for at bruge idékataloget er, at man har et vist kendskab til den fællesstatslige itprojektmodel og dens faser, jf. figur 1, og at man kender til kontraktparadigmerne K01-K03, som anvendes i det offentlige. For yderligere information om den fællesstatslige it-projektmodel og kontrakterne henvises til: www.digst.dk/projektmodel Figur 1 Den fællesstatslige it-projektmodels fem faser Idékatalogets afsnit 2 giver et overblik over de mest gængse typer af test, der bliver brugt i it-projekter. I afsnit 3 bliver det beskrevet, hvordan test kan tænkes ind i de forskellige faser i den fællesstatslige projektmodel, og der gives en introduktion til sammenhængen mellem de mest anvendte udviklingsmetoder for it-projekter og test. Afsnit 4 indeholder links til yderligere information og inspiration vedrørende testmetoder og testtyper. Den fællesstatslige it-projektmodel, Digitaliseringsstyrelsen [1]
2. Typer af test Der findes en lang række testtyper, som kan bruges i de forskellige faser af et statsligt it-projekt. Det er vigtigt som projektleder at sortere og vælge de testtyper, der er relevante for det it-projekt, man skal eller er i gang med. Testtyperne er inddelt i følgende temaer: Software Brugervenlighed Performance Overtagelse Drift Hver testtype er kort beskrevet, ligesom det er angivet, hvilken fase den gennemføres i, og hvem der er ansvarlig for at gennemføre den. Som det fremgår af skemaet, gennemføres de fleste test i gennemførelsesfasen. Men, som det er beskrevet i afsnit 3, er det allerede i anskaffelsesfasen, man skal træffe valget om testtyper. Mange testtyper vil kunne understøttes af software, som leverandøren har, eller som myndigheden selv kan erhverve. Tema Testtype Beskrivelse Fase Ansvarlig Komponenttest Tester forretningslogikken i de individuelle komponenter. Målet er at sikre, at den enkelte komponent virker efter hensigten og som aftalt. Software Komponentintegrationstest Tester grænseflader og samspil mellem komponenterne i systemet. Målet er at sikre, at de virker og interagerer som aftalt. Der er fokus på blandt andet udvekslingsformater og protokoller. Funktions- og integrationstest Tester systemets funktionalitet og integration af systemet mod andre (del-) systemer og grænseflader til eksterne organisationer. Den fællesstatslige it-projektmodel, Digitaliseringsstyrelsen [2]
Tema Testtype Beskrivelse Fase Ansvarlig Installationstest Tester installationen af en release/version. Udføres hver gang en ny release installeres. Tester, om installationen kan gennemføres på driftsmiljøerne. Smoketest Tester (ved brug af en mindre mængde testcases en netop installeret release/version), at alle centrale komponenter kan tilgås. Udføres, hver gang en ny release installeres. Smoketest er nogle gange det samme som testbarhedstest. Realisering Prototypetest Tester tidligt i udviklingsforløbet, at brugergrænsefladedesign virker forståeligt og tilfredsstillende, og at der leves op til krav om funktionalitet. Anskaffelse Kunden Brugervenlighed Brugervenlighedstest Tester brugergrænsefladen med bagvedliggende funktionalitet sammen med en repræsentativ gruppe af brugere. Kan gennemføres flere gange i projektet. Kunden Webtilgængelighedstest Tester tilgængelighed i en browser, om de enkelte elementer lever op til standarder og retningslinjer for tilgængeligt webdesign, som alle statslige myndigheder skal opfylde. Tilgængeligheden testes tillige med en skærmlæser. Kunden Performancetest Svartidstest Tester om kravene til svartider er overholdt, jf. de aftalte krav til svartider. Den fællesstatslige it-projektmodel, Digitaliseringsstyrelsen [3]
Tema Testtype Beskrivelse Fase Ansvarlig Belastningstest Tester systemets ydeevne ved høje belastninger, for eksempel målt i form af antallet af samtidige brugere og/eller antallet af transaktioner, jf. de aftalte krav til ydeevne. Svartidstest og belastningstest overlapper, da svartiderne skal overholdes under den forventede belastning (og kompleksitet i forhold til datamængder og typer af kald). Skalerbarhedstest Tester systemets evne til at kunne opgraderes til at have mere kapacitet, med henblik på at sikre, at de aftalte krav til skalerbarhed er opfyldt. Konverteringstest Tester involverede processer, software og resultater ved konvertering af data fra et format til et andet. Med henblik på at sikre, at konverteringsprocesser og software, der skal konvertere data fra et eksisterende format til et nyt, virker og har det ønskede resultat, herunder at konverterede data er korrekte og komplette. Overtagelse Funktionel kravtest Tester funktionalitet med henblik på at sikre, at forretningsmæssige krav er opfyldt. Kunden Dokumentationstest (review) Tester via review, om den aftalte dokumentation, f.eks. systembeskrivelse, brugervejledning, installationsvejledning eller testrapport, opfylder kravene. Kunden Regressionstest Tester et tidligere testet system efter modificering med henblik på at sikre, at ændringen ikke har genereret følgefejl. Den fællesstatslige it-projektmodel, Digitaliseringsstyrelsen [4]
Tema Testtype Beskrivelse Fase Ansvarlig End to end test Skal sikre, at systemet kan fungere korrekt fra start til slut. Recovery test Tester om systemet kan genoprettes efter nedbrud med henblik på at sikre, at systemet kan genetablere det specificerede performance-niveau og gendanne de data, der direkte påvirkes i tilfælde af nedbrud. Sikkerhedstest Tester systemets modstandsdygtighed over for angreb og misbrug med henblik på at sikre, at systemet lever op til de krav til sikkerhed, der er aftalt. Kunden Pilottest Tester systemet med brugere/virksomheder/borgere, der i en periode får adgang til at bruge systemet under driftslignende vilkår, men før det bliver sat i faktisk drift, med henblik på at sikre, at systemet fungerer tilfredsstillende i denne kontekst. Her arbejdes der både med test, hvor testerne kender opbygningen, og hvor de tester sikkerheden udefra uden at kende det. Kunden Overtagelsestest Tester om alle krav til funktionalitet, servicemål og dokumentation er overholdt i forbindelse med det endelige system og dermed kan overtages. Drift Driftstest Tester systemet i produktionsmiljøet under faktisk brug med henblik på at sikre, at systemet i en driftskontekst overholder alle aftalte servicemål over en aftalt periode. Realisering Den fællesstatslige it-projektmodel, Digitaliseringsstyrelsen [5]
3. Planlægning af test i faserne Det er især i gennemførelsesfasen, der er fokus på test, og her man gennemfører de fleste af dem. Men allerede i idéfasen kan man få en indikation af, hvilke testtyper og testmetoder, der senere skal bringes i spil, og i analysefasen begynder man at arbejde med sin teststrategi. I dette afsnit beskrives det, hvordan man arbejder med test i den fællesstatslige itprojektmodels fem faser, og hvilke typer af test der typisk bruges i forbindelse med forskellige typer af udviklingsmetoder. I forbindelse med test er det vigtigt at få afklaret, hvem der tager sig af test i de forskellige faser, og hvem der har ansvaret for hvilke typer af test. Har projektlederen for eksempel det fulde ansvar for test, eller kan der knyttes en testspecialist til it-projektet, som har det fulde ansvar for udarbejdelse af teststrategi og gennemførelse af test? Eller er der behov for en særlig rolle til at varetage styring af test, og hvor mange testere skal der være og hvornår? Det vil afhænge af projektets kompleksitet og størrelse, om der er behov for sådanne testressourcer og hvor mange. Ud over de roller, der specifikt har med test at gøre, kan det være relevant at inddrage myndighedens it-arkitekt til for eksempel at give input til performancetest. I forbindelse med udarbejdelse af testcase og sikring af brugervenlighed i forhold til de specificerede krav, skal repræsentanter fra forretningen inddrages. Det er med til at sikre, at de udvalgte testcases afspejler de reelle processer, og at brugervenligheden testes i den rigtige kontekst. Se endvidere vejledningen om roller og ansvar i it-projekter på www.digst.dk/projektmodel 3.1 Idéfasen I idéfasen er det begrænset, hvilke tiltag og overvejelser projektledelsen skal gøre sig vedrørende test, medmindre man bruger v-modellen, som er beskrevet under gennemførelsesfasen. Gør man det, skal man allerede i idéfasen tænke test af forretningsmål ind i processen. Ellers er det primære i idéfasen er at få afklaret, om idéen kan resultere i et bæredygtigt it-projekt, undersøge hvilke gevinster der kan forventes og at få lavet et overslag over projektets udgifter. I idéfasen er de første overordnende risici for projektet blevet identificeret, og det kan give en indikation af, hvilke testmeotoder og testtyper det pågældende itprojekt skal være omfattet af. Resultaterne af dette arbejde beskrives i projektgrundlaget. Den fællesstatslige it-projektmodel, Digitaliseringsstyrelsen [6]
3.2 Analysefasen I analysefasen bliver der foretaget en grundig og detaljeret analyse af projektets omfang, kravene til ressourcer, udgifter, mulige gevinster, tidsplan, risici, kvalitet, etc. I analysefasen bliver kvalitetskravene til projektets leverancer også defineret, og de er med til at definere, hvad der senere testes op imod. De første idéer til en teststrategi for it-projektet kan begynde at tage form. I den forbindelse skal der tages udgangspunktt i myndighedens egen teststrategi. Den vil typisk være af generel karakter, men vil danne rammen for strategien for itprojektet. 3.3 Anskaffelsesfasen I anskaffelsesfasen forberedes og gennemføres udbuddet. I denne fase færdiggør projektledelsen også teststrategien. Heri beskrives blandt andet den generelle strategi for de test, der skal gennemføres i forbindelse med udvikling og levering af itprojektet. I teststrategien er det også hensigtsmæssigt at beskrive test, der er relateret til den efterfølgende driftsfase og dermed videreudvikling og vedligeholdelse af itsystemet. I anskaffelsesfasen besluttes og planlægges det også, hvilke testtyper der skal bruges. Der findes mange relevante testtyper. Hvor mange og hvilke der vælges, vil være afhængig af, hvilken type it-projekt der er tale om, for eksempel om det er et projekt med høj eller lav risiko. Teststrategi, -planer og -cases I teststrategien beskrives det, hvordan testarbejdet organiseres, og hvilke test der skal gennemføres. Der er ikke udarbejdet nogen skabelon til en teststrategi i den fællesstatslige it-projektmodel, men følgende punkter giver en indikation af, hvad der kan indgå i arbejdet med en teststrategi. Der er dog ikke tale om en udtømmende liste: 1. Testtilgang Teststrategien beskriver eksplicit, hvilken udviklingsmetode, der skal bruges i projektet (se afsnit 3.4 for beskrivelse af forskellige udviklingsmetoder), og hvilken betydning, det har for tilgangen til testen. Herudover skal der foreligge en beskrivelse af brugen af forskellige testdesignteknikker, risikobaseret test, testdækning, prioritering og sporbarhed til krav og løsning. Beskrivelsen omfatter ligeledes, hvordan disse dokumenteres. Et it-system indgår i samspil med en samlet it-løsning, der integrerer flere itsystemer. Derfor vil test af grænseflader til andre systemer være vigtig og skal adresseres og beskrives. Eksempelvis skal integrationstest koordineres med tilpasningerne i andre systemer, og testen skal foretages i samarbejde med den ansvarlige for hvert af disse systemer og evt. systemets leverandør. skal i sin løsningsbeskrivelse beskrive sin support til testen af tekniske og forretningsmæssige grænseflader og den tilhørende fejlanalyse. En forudsætning herfor er dog, at myndigheden i sin kravspecifikation sikrer sig, at leverandøren beskriver dette og / eller er forpligtet til at bistå. Den fællesstatslige it-projektmodel, Digitaliseringsstyrelsen [7]
Endelig er det vigtigt, at brugerinddragelse og brugertest adresseres særskilt, når I beskriver jeres tilgang til test. Brugertest bør udføres løbende under hele udviklingsforløbet med henblik på at sikre en brugervenlig løsning, der lever op til forretningens og evt. eksterne brugeres behov. 2. Kravstyring Teststrategien omfatter metoder til verifikation af alle krav, herunder også de krav, der ikke er testbare. Processen for styring og dokumentation af kravopfyldelse skal ligeledes beskrives, herunder brug af eventuelle værktøjer. 3. Risikoanalyse og styring Under hele gennemførelses- og realiseringsfasen skal man vedligeholde en risikolog med de risici, der relaterer sig til test. Risikologgen skal dække på tværs af samtlige test og vil være en del af den generelle risikostyring af projektet. 4. Testplaner Teststrategien for projektet suppleres af en testplan for den enkelte test. Testplanen for en given test udarbejdes oftest af den, der er ansvarlig for gennemførelse af testen (hos kunden eller leverandøren). Der skal være sporbarhed mellem testplanen og teststrategien og mellem testplanen og kravene, som er beskrevet i kravspecifikationen, samt andre relevante specifikationer, der udtrykker krav, der testes. 5. Testdrejebøger Hver testplan detaljeres, så der findes en specifikation af den konkrete udførelse af en test. Den kan indeholde den adresse, hvor testen foregår, tidsrum for hvornår testen foregår, hvem der gennemfører hvilke testcases og i hvilken rækkefølge og den praktiske håndtering af fejl. Der skal være sporbarhed mellem en testdrejebog og den testplan, den detaljerer. 6. Testmiljøer Det skal fremgå, hvilke miljøer der skal anvendes i forbindelse med udvikling og test. Herudover skal det være klart, hvem der for eksempel er ansvarlig for at udvikle og vedligeholde de testdrivere/-stubbe, som er nødvendige for at foretage den planlagte test på de miljøer, der ikke indeholder integrationer til andre systemer. 7. Testdata og testcases Enhver testcase skal indeholde en beskrivelse af formål, forudsætninger, de trin der skal gennemløbes med angivelse af input, forventet resultat og en angivelse af, hvilke(t) krav der testes. Der udarbejdes både positive og negative testcases; det præcise indhold skal fremgå af testplanen. Det skal ligeledes beskrives i teststrategien, hvordan testcases dokumenteres, samt hvordan det dokumenteres, at it-projektet lever op til de krav, en given testcase tester. Brug af prototyper som metode til test En prototype er et bud på, hvordan det fremtidige system eller en del af det kan fungere, og hvilket indhold det kan have. Formålet med prototypen er at teste de idéer, man har, om funktionalitet og indhold. Man kan lave prototypen, før den endelige udvikling sættes i gang. Prototypen kan bruges i en afklarende fase eller tidligt i udviklingsprocessen med leverandøren, men den kan også bruges forud for kravspecificeringen til at få en forståelse af brugernes behov. Prototypen viser typisk enten bredden i funktionaliteten, så man får et overblik over, hvad systemet helt overordnet skal kunne. Eller den illustrerer dybden i en Den fællesstatslige it-projektmodel, Digitaliseringsstyrelsen [8]
enkelt eller nogle få funktioner, så man for eksempel kan se, hvordan hele forløbet fra man starter processen med at melde flytning, til man har fået en kvittering, vil foregå. En prototype kan antage mange former, for eksempel skærmbilleder, der illustrerer det pågældende it-system eller et storyboard, der viser, hvordan de forskellige brugere skal interagere via it-systemet. Prototyper kan testes med brugere i små, hurtige iterationer, hvor brugernes kommentarer og forslag løbende indarbejdes i prototypen, så den kan testes igen, indtil den endelige løsning er fundet. Sammenhængen mellem test, kravspecifikation og kvalitet I relation til test skal man sørge for, at de krav, der er stillet i kravspecifikationen, er testbare, og at de opfylder de kvalitetskrav, der er til it-projektet. Der er en tæt sammenhæng mellem test, kravspecifikation og de kvalitetsmål, der er beskrevet for projektets leverancer. Kravspecifikationen er en udmøntning af de kvalitetsmål, man har for it-projektet, og det er i forhold til kravene, man tester. Figur 2 Samspillet mellem kravspecifikation, kvalitetsplan og test Det kan være en god idé at inddrage testkompetencer og ressourcer i projektet allerede i starten af anskaffelsesfasen for at få tjekket og valideret, om kravspecifikationen lever op til dette. 3.4 sfasen I gennemførelsesfasen er der fokus på at designe og udvikle it-systemet og forberede overdragelsen til forretningen, så projektet kan afsluttes. Udviklingen sker på baggrund af de krav, der er formuleret i kravspecifikationen som nævnt i afsnit 3.3. sfasen er den fase, hvor de væsentlige og mest omfangsrige test gennemføres, enten af leverandøren, af kunden eller i samarbejde mellem leverandør og kunde. kan have forskellige tilgange til test. Det afhænger Den fællesstatslige it-projektmodel, Digitaliseringsstyrelsen [9]
dels af, hvilke type it-projektet der er tale om, dels hvilken udviklingsmetode den valgte leverandør har tradition for at anvende. Herudover kan det afhænge af, hvilke krav kunden har stillet til brugen af specifikke testtyper. I det følgende beskrives tre udviklingsmetoder, der ofte anvendes, og den tilgang til test der er i hver af dem. For yderligere information se endvidere afsnit 4. 1. Vandfaldsmodel Vandfaldsmodellen er en sekventiel softwareudviklingsproces, hvor udviklingen gradvist flyder nedad i faser, ligesom et vandfald. De enkelte faser har deres egne definerede aktiviteter og mål. Vandfaldsmodellen er typisk inddelt i følgende faser: Kravspecifikation og analysefase Software design Implementering og test Vedligeholdelse. Den enkelte fase kan først påbegyndes, når den foregående fase er afsluttet. Det betyder, at man ved afslutningen af hver fase gennemgår projektet for at afgøre, om det er på rette vej, og om det kan fortsætte eller ej. I vandfaldsmodellen overlapper faserne ikke hinanden. 2. V-model V-modellen opererer med både en udviklingslivscyklus og en testlivscyklus, hvor der hele tiden foregår verifikation og validering. Der henvises til illustration af V-modellen i de links, der findes i afsnit 4. V-modellen opererer med test allerede i de tidlige faser i projektets udviklingscyklus. Før de egentlige test starter, arbejder et testteam på forskellige aktiviteter inden for test, såsom udarbejdelse af teststrategi, testplanlægning, oprettelse af testcases og testscripts. 3. Agil model Den agile udviklingsmodel er en form for inkrementel model. Softwaren bliver udviklet i en inkrementel cyklus af korte iterationer. Dette resulterer i små trinvise releases, hvor der for hver release bygges videre på tidligere frigivet funktionalitet. Hver release er grundigt testet for at sikre, at softwarekvaliteten er tilstrækkelig. Der henvises til illustration af den agile model i de links, der findes i afsnit 4. I agil udvikling er test en integreret del af softwareudviklingen sammen med kodningen. Test og kodning afsluttes trinvist og iterativt, hvor de enkelte funktioner opbygges og frigives til produktion, når det giver tilstrækkelig værdi for forretningen. Der vil dog i praksis ofte være tale om en samlet test, fordi man typisk ikke kan automatisere alle tests og / eller have en bredere skare af testere på ved hvert sprint. Nogle softwarehuse anvender også automatiserede test i deres udvikling, hvilket giver en øget sikkerhed af den kvalitet, som softwarehuset kan levere til kunden. Den fællesstatslige it-projektmodel, Digitaliseringsstyrelsen [10]
Dette er med til at sikre mod regression og kan være en meget stor hjælp ved al videreudvikling og forståelse af systemet. 3.5 Realiseringsfasen I realiseringsfasen er it-projektet afsluttet, og man er overgået til drift. Den obligatoriske driftstest skal gennemføres, jf. den aftale, der er indgået om servicemål med leverandøren. Det er essentielt få aftalt planlægning af test af de releases, der er planlagt som følge af behov for nyudvikling eller vedligeholdelse. Ved overgangen til driftsfasen er det vigtigt, at udestående fejl bliver dokumenteret og overdraget til driftsorganisationen. Supporten skal blandt andet kende til fejl, der arbejdes på at rette, så kan give brugerne besked om kendte fejl. Den fællesstatslige it-projektmodel, Digitaliseringsstyrelsen [11]
4. Yderligere information vedrørende testmetoder og -typer Der findes en lang række beskrivelser af testmetoder og testtyper på nettet med yderligere information om hver af dem. Linkes om forskellige typer af softwaretest metoder og typer: http://istqbexamcertification.com/ http://www.softwaretestingclass.com/what-is-software-testing-methodologies/ http://www.softwaretestinghelp.com/types-of-software-testing/ http://www.tutorialspoint.com/software_testing/testing_overview.htm Om automatiseret test: http://www.tutorialspoint.com/software_testing/testing_types.htm Artikel om testdrevet udvikling af integrationer, som er relevant i forhold til integrationen af flere it-systemer til en løsning: http://www.hohpe.com/gregor/work/docs/testdriveneai.pdf Link til mere information vedrørende rapid prototyping: http://www-personal.umich.edu/~jmargeru/prototyping/ Den fællesstatslige it-projektmodel, Digitaliseringsstyrelsen [12]