Au Aarhus Universitet. Aarhus Universitet AU på STADS Teststrategi Version 1.0

Transkript

1 Aarhus Universitet AU på STADS Teststrategi Version 1.0

2 Version Dato Version Udarbejdet af Godkendt af Beskrivelse LBA Første udkast GST Revideret udkast GST Revideret udkast til review GST Kommentarer indarbejdet Indholdsfortegnelse 1 Indledning Formål Generelle formål ved test Baggrund Målgruppe Testdokumenter Overordnet beskrivelse af testen Fremgangsmåde Definition af testens omfang Testfaser og acceptkriterier Programmets testfaser Overordnet beskrivelse af dynamiske testtyper Acceptkriterier (start og slut kriterier) Risikoanalyse Testmiljøer og testdata Testroller og uddannelsesbehov Roller Behov for uddannelse Testestimater Testværktøj Side 2 af 20

3 1 Indledning 1.1 Formål Denne teststrategi beskriver hvordan test skal håndteres i AU på STADS. Strategien er et paraply-dokument, og den fortæller overordnet, hvordan der skal planlægges og afvikles test. Den inkluderer ligeledes generiske informationer omkring metoder, der er påkrævede i forbindelse med design, planlægning og afvikling af test. Retningslinjerne i denne strategi er defineret anvendende et højt abstraktionsniveau, eftersom de skal kunne anvendes på de forskellige typer leverancer, der findes i AU på STADS. Idéen er, at skabe et grundlag samt en forståelsesramme, der skal sætte projekter i stand til at kunne gennemføre deres testplanlægning samt testeksekvering. Teststrategien er udviklet til at kunne anvendes operationelt i AU, og har taget sit udgangspunkt i ITIL3 processer, ISTQB test koncepter, og suppleret med test best practice Generelle formål ved test Test defineres som værende en systematisk kvalitetssikring af leverancer. Test er en proces, hvor resultater af en given mængde handlinger sammenlignes med de forventede resultater af disse handlinger, med ønsket om at de stemmer overens. Test omfatter både dynamisk test (som kræver afvikling af software) og statisk test (den manuelle gennemgang (review) af koden eller anden projektdokumentation). Denne teststrategi beskriver de dynamiske tests som er planlagt i AU på STADS samt de statisk tests planlagt for alle test dokumentation. Andre kvalitetssikringsaktiviteter kan beskrives i en kvalitetsplan men er ikke yderligere beskrevet i dette dokument. De primære formål med test er at sikre: At en leveret løsning lever op til modtagerens behov, altså at det er en rigtig løsning der er blevet lavet. At modtagerkravene er blevet opfyldt som specificeret, altså at den valgte løsning er lavet rigtigt. Fastslå hvordan en leverance fungerer (og ikke fungerer), så der ikke forekommer ubehagelige overraskelser i forbindelse med implementering i produktion, altså at der leveres med kendt kvalitet. Andre grunde til at kvalitetssikre er at: Skabe tiltro til den leverede løsning. Sikre at snitflader mellem leverancer og snitflader mellem løsninger, fungerer som forventet. Side 3 af 20

4 1.2 Baggrund Formålet med AU på STADS projekter er at implementere STADS på Aarhus Universitet. I forbindelse med ibrugtagningen af STADS udfases dele af den eksisterende systemportfolio. STADS er udviklet af Logica, og den videre udvikling samt vedligeholdelse koordineres af STADS-sekretariatet. Dele af Aarhus Universitet benytter allerede forskellige versioner af STADS. Udvikling af STADS foregår som en iterativ proces baseret på et tæt samarbejde mellem de institutioner der deltager i STADS samarbejdet. Ønsker/krav til STADS indsendes til STADS-sekretariatet af de enkelte partnere i samarbejdet, og efter en høringsrunde og mulig analyse godkendes eller forkastes forslaget. Godkendte krav bliver planlagt til levering i fremtidige releases af STADS. STADS har følgende hovedkomponenter: estads istads Selvbetjening STADS basis Der er to dokumenterede udviklingsprocesser som bruges ifm. videreudvikling af STADS. Den følgende tabel viser hvornår disse bruges: Hovedkomponent Ændringsomfang Udviklingsproces estads Mindre ændringer eller tilpasninger af eksisterende Kravspecifikation istads Selvbetjening funktioner STADS basis istads Større ændringer med nye Use Case og kravsliste skærmbilleder For at sikre integrationer til andre AU systemer, samt udvikle andre komponenter af AU på STADS løsningen, vil AU Fælles-IT også være leverandør til AU på STADS. 1.3 Målgruppe Modtager Rolle Behandling Steffen Skovfoged Programleder Review, Godkender Alle projektledere Review, Kommenterer Testleder Orienteres 1.4 Testdokumenter Dette dokument, program teststrategien, giver et overblik over, hvordan tests skal planlægges og udføres i programmet. Side 4 af 20

5 Testplaner skal efterfølgende udarbejdes for hver planlagt test. Disse produceres af testlederen, i samarbejdet med projektlederne og programlederen, og beskriver detaljeret, hvordan en given test (testfase eller type) vil blive udført. En testplan vil resultere i udarbejdelsen af en mængde testcases. Detaljeringsgrad, testomfang, samt metode for udarbejdelsen af testcases for en test vil også defineres i testplanen. Testcases skal dokumenteres i Quality Center (QC) anvendende en fastlagt skabelon. Testplanen vil også beskrive følgende for en test: det planlagte testmiljø, testdata, test ressourcer, testværktøjer, relevante processer, samt andre forhold som er vigtigt for den planlagte test. Til sidst vil testplanen også indeholde et estimat for testens forberedelse samt afvikling. Der vil også ved hver tests afslutning blive udarbejdet en testrapport, der kort beskriver testens forløb og resultat, uafsluttede problemstillinger, tidsforbrug etc. Dokumentet er af væsentlig betydning som grundlag for planlægning, estimering og afvikling af de kommende tests. Testdokumentationsopbygningen for programmet kan ses simplificeret i figur 1 nedenfor: Testdokumenter Program Teststrategi Testplaner Testcases og defekts Testrapporter Greg Stone and Lars Blomgren Andersen 2 Overordnet beskrivelse af testen AU på STADS har følgende overordnede succes-kriterier: 1. At implementere STADS i Aarhus Universitetet 2. At gennemføre implementeringen til tiden 3. At sikre at berørte organisationer er parate til at ibrugtage STADS Side 5 af 20

6 Betragtes de overordnede succes-kriterierne fra et testsynspunkt betyder dette, at test vil være: Et værktøj til at opnå det første kriterium, idet test kan give grundlaget for en struktureret kvalificeret sikring af processerne af hvert enkelt forretningsområde Et værktøj til at opnå kritisk viden omkring det andet kriterium, idet testfaserne vil blive opdelt i strengt fastlagte kalenderperioder hvor trendanalyser på testafvikling og observationshåndtering kan anvendes til at forudsige den fremtidige kvalitetsudvikling og dermed estimere realistiske færdiggørelses datoer Et værktøj til at opnå kritisk viden omkring det tredje kriterium, idet testresultater både vil give indblik i hvad der virker og hvad der ikke virker samt give et fælles overblik på et givent tidspunkt, der kan anvendes til at forudse det samlede konsekvensbillede for alle organisationer ved produktions idriftsættelsen. 2.1 Fremgangsmåde Test aktiviteterne bør ende med det resultat at al funktionalitet, konverteret data og alle tekniske elementer lever op til de stillede krav, og at der ikke er nogen kritiske åbne defekts affødt af testaktiviteter på ibrugtagningstidspunktet. Hvis dette ikke er muligt skal testlederen tilstræbe at have et klart overblik over situationen der sætter de ledende beslutningstagere i stand til at foretage informerede beslutninger. Der arbejdes med følgende fire afviklende program testfaser, der hver især tilstræbes afsluttet for alle projekter inden næste fase påbegyndes: GAP Analyse Hands on Test Systemintegrationstest Brugeraccepttest STADS er en færdig-udviklet løsning fra Logica, men der vil være en række krav som skal nyudvikles for AU på STADS. Alle leverancer af nyudvikling fra STADS leverandøren, samt nyudvikling fra Fælles-IT, skal igennem en kundesystemtest samt en kundeaccepttest. Disse leverance testfaser kører uafhængige af de ovenstående program testfaser og følger STADS samt Fælles-ITs release planer. Dog er det planlagt, at alle leverance testfaser skal være afsluttet før program testfase Brugeraccepttest påbegyndes. Leverandøren er også ansvarlig for at gennemføre en række tests. For UNI-IT, er disse tests beskrevet i Teststrategi_OPLÆG_v9.doc. Disse testfaser kan ses grafisk i følgende: Side 6 af 20

7 Au Aarhus Universitet Program vs. Leverance testfaser Program testfaser Gennemføres baseret på programplan Gap Analyse Hands on Test Systemintegrationstest Brugeraccepttest Leverance testfaser Gennemføres efter hver leverance - baseret på leverandørs releaseplan Greg Stone and Lars Blomgren Andersen Der vil også blive udført en række tekniske tests (performance, drifts samt konvertering). Disse tests er planlagt til at blive udført så tidligt i programmets forløb som muligt. Program testfaserne forventes afviklet efter følgende plan. Denne plan kan, og vil højst sandsynligt, ændres efter testplanerne er udarbejdet. 3 Definition af testens omfang Testens omfang kan defineres udefra en kombination af testfase og testtype. Testens omfang skal altid tage højde for den optimale kombination af tid, omkostninger og risici. Den følgende figur viser at man kan definere testens omfang (1) for lidt, (2) for meget eller (3) optimalt. Side 7 af 20

8 Omkostninger Au Aarhus Universitet Testens omfang: Hvad er optimalt? Samlede omkostninger: Testaktiviteter + Produktions fejlretning Testaktiviteter Produktions fejlretning (1) For lidt test (3) OPTIMALT! (2) For meget test Testomfang Greg Stone and Lars Blomgren Andersen I den næste sektion af denne teststrategi, defineres et bud for testomfanget som forsøger at ramme det optimale testomfang. Dette bud skal verificeres i hvert projekt, når testplanerne skal færdiggøres og vurderes under selve testafviklingen. I det omfang at det er muligt og giver mening, vil man undersøge automatisering af tests for at kunne yderligere optimere testomfanget. 4 Testfaser og acceptkriterier Som beskrevet i kapitel 2 vil programmet arbejde med 4 program testfaser (Gap Analyse, Hands On Test, Systemintegrationstest, Brugeraccepttest). Der vil også blive gennemført 3 yderligere tekniske tests for at sikre fokus på nogle specifikke testtyper (Performance, Drift og Konvertering). Indholdet, testfokus, testdeltagere og de ansvarshavende samt initierende roller for disse tests er beskrevet i kapitel 4.1. Kapitel 4.2 indeholder en kort beskrivelse af de dynamiske testtyper, der skal inkluderes i de relevante faser samt valgte tekniske tests. Kapitel 4.3 beskriver acceptkriterierne for hver fase, dvs. hvornår en testfase burde kunne afsluttes og den næste påbegyndes. Side 8 af 20

9 4.1 Programmets testfaser Testfase Test-typer i fasen Deltagere i testen Ansvarlig/ initierende Gap Analyse Fejlhåndtering Proces projekter + Projektleder Fokus: Funktion Systemstrategi + At identificere alle behov for nyudvikling Job afvikling Datakonvertering som skal udføres af de mulige leveran- Sikkerhed dører. Alle GAPS som er identificeret i Snitflade denne test skal placeres i én af de følgende kategorier: - GAP der integreres i STADS - GAP der udvikles AU-specifikt - GAP der håndteres manuelt Hands On Test Fejlhåndtering Proces projekter + Projektleder Fokus: Funktion Systemstrategi + At verificere resultatet af Gap Analysen Job afvikling Datakonvertering ved at gentage testen på konverteret Konvertering AU data. Sikkerhed Snitflade Systemintegrationstest Fejlhåndtering Proces projekter + Programleder Fokus: Funktion Systemstrategi + /Testleder At bevise at forretnings- samt system- Job afvikling Datakonvertering processerne virker som specificeret på Konvertering alle typer data. Det skal også sikres, at Regression manuelle forretningsprocedurer kan Sikkerhed gennemføres som ønsket. Snitflade Denne testfase er todelt. Den første del Transaktionsafvikling afvikles hvor muligt i den eksisterende STADS løsning. Den anden del udvikles i takt med leverancer fra de forskellige leverandører. Brugeraccepttest Dokumentation og Proce- Proces projekter + Programleder Fokus: durer + Udannede brugere i /Testleder At bevise at et udvalg af kritiske og Baseret på hvilke test ca- relevante hovedområ- nødvendige forretnings- og systemfunk- ses og forretningsscenari- der. tioner fungerer uden fejl i et stabilt pro- er der udvælges duktionslignende testmiljø med produktionslignende data. Test cases til denne fase er et udvalg (80/20 perspektiv) fra de tidligere testfaser og vil derfor ikke indeholde nogen nye test. Side 9 af 20

10 Testfase Test-typer i fasen Deltagere i testen Ansvarlig/ initierende Fokus: At bevise at forretnings- samt systemprocesserne virker som specificeret på alle typer data på nyudvikling. Fokus: At bevise at alle fejl fundet under kundesystemtest er løst og leverancen kan accepteres formelt af programmet. Performancetest Fokus: At bevise at løsning kan leve op til definerede SLA mht. svartid og belastning. Denne testfase er todelt. Den første del afvikles mht. at lære arkitekturen/løsningen at kende fra et performance optimerings/skalerings perspektiv. Den anden del er den endelige test. Drifttest Fokus: At bevise at løsning kan indgå som en sikker del af den daglige drift. Konverteringstest Fokus: At bevise at alle typer af konverteret data godkendes af hovedområder. Brugervenlighed Proces projekter + Fejlhåndtering Systemstrategi + Funktion Datakonvertering Job afvikling Konvertering Regression Sikkerhed Snitflade Transaktionsafvikling Brugervenlighed Proces projekter + Fejlhåndtering Systemstrategi + Funktion Datakonvertering Job afvikling Konvertering Regression Sikkerhed Snitflade Transaktionsafvikling Performance Datakonvertering + Stress og Volumen IT Drifts personale + Eksterne testkompetencer til hjælp med loadtest værktøj Backup og Reetablering Datakonvertering + Dokumentation og Procedurer IT Drifts personale Drift Eventualitet Revision og Kontroller Konvertering Datakonvertering + Udannede brugere i relevante hovedområder. Projektleder Projektleder Projektleder /Testleder Projektleder /Testleder Projektleder /Testleder Statisk test Review af specifikationer Besluttes af -> Projektleder Fokus: Eventuelt review af andet Besluttes af -> Projektleder At sikre at der ikke bliver udviklet eller materiale testet på et forkert grundlag Review af Teststrategi Besluttes af -> Testleder Review af Testplan Besluttes af -> Testleder Review af Test cases Besluttes af -> Testleder Side 10 af 20

11 Gap Analyse Hands On Test Systemintegrationstest Brugeraccepttest Performancetest Driftstest Konverteringstest Au Aarhus Universitet Den ovenstående tabel kan opsummeres med den følgende testfase/type matrice: Testtype Brugervenlighed Backup og Reetablering Dokumentation og Procedurer Drift Eventualitet Fejlhåndtering Funktion Installation Job afvikling Konvertering Performance Regression Revision og Kontroller Sammenligning Sikkerhed Snitflade Stress og Volumen Transaktionsafvikling 4.2 Overordnet beskrivelse af dynamiske testtyper Dynamiske test typer Brugervenlighed Backup og Reetablering Dokumentation og Procedurer Drift Eventualitet Beskrivelse Sikrer at løsningen er brugervenlig og nem at anvende Sikrer evnen til at kunne gemme, reetablere og genstarte centrale dele af løsningen efter fejl Sikrer at grænsefladen mellem løsningen og brugeren virker. Sikrer at undervisningsmateriale og manualer er på plads og rigtige Sikrer løsningens evne til at kunne fungere med det påkrævede servicemål i et produktionslignende miljø Sikrer at eventualitetsplaner og procedurer fungerer som forventet (system redundans, nødberedskabsplan, katastrofe genetablering mm.) Side 11 af 20

12 Fejlhåndtering Funktion Installation Job afvikling Konvertering Performance Regression Revision og Kontroller Sammenligning Sikkerhed Snitflade Stress og Volumen Transaktionsafvikling Sikrer at løsningen er i stand til at finde og reagere korrekt på undtagelses tilstande (Fejlbeskeder mm.) Sikrer at løsningens forretningsfunktioner lever op til de stillede forretningskrav Sikrer at løsningen nemt kan blive etableret i og kan køre i det valgte miljø Sikrer korrekt afvikling af jobs og korrekt håndtering af undtagelses tilstande (Overvågning og alarmer) Sikrer ligheden af nykonverterede datapakker, programmer og procedurer med det originale materiale Sikrer at løsningen leverer den forventede ydeevne i et produktionslignende miljø Sikrer at implementeringen af den nye løsning ikke forårsager uønskede ændringer i eksisterende løsninger Sikrer tilstrækkeligheden og effektiviteten af kontroller samt logfiler Sikrer at det samme input på de den nye og den originale løsning giver det samme resultat Sikrer at løsningen leverer det nødvendige niveau af sikkerhed for kritiske data, processer mm. Sikrer at løsningens snitflader (mellem applikationer og mellem systemer) virker som forventet Sikrer at løsningen leverer acceptabel ydeevne under spidsbelastninger Sikrer skridt for skridt kvaliteten af løsningens centrale transaktioner fra de initieres til de afsluttes 4.3 Acceptkriterier (start og slut kriterier) Disse acceptkriterier skal verificeres samt detaljeres yderligere i hver program testfase testplan. Testfase Startkriterier Slutkriterier Gap Analyse Alle funktionelle krav er opdateret i Quality Center Adgang til et STADS miljø med relevant data Administrative processer kendte af test deltagere Alle krav har en relateret testcase med opdateret status (Passed/Failed/N/A) Alle krav er opdateret med de ændringer som måtte findes under testen Hands On Test Alle funktionelle krav er opdateret i Quality Center Adgang til et STADS miljø med relevant konverteret data Alle krav har en relateret testcase med opdateret status (Passed/Failed/N/A) Alle krav er opdateret med de Side 12 af 20

13 Testfase Startkriterier Slutkriterier Administrative processer kendte af test deltagere ændringer som måtte findes under testen Systemintegrationstest Brugeraccepttest Alle testcases er opdateret i Quality Center Adgang til et STADS miljø med relevant konverteret data Alle nødvendige leverancer (fra enten STADS eller Fælles IT) er installeret i testmiljøet Der er ikke udstående kritiske fejl fra tidligere testfaser som kan forhindre test gennemførelsen Der foreligger en godkendt testplan (programlederen godkender) Alle testcases er opdateret i Quality Center Adgang til et STADS miljø med relevant konverteret data Alle nødvendige leverancer (fra enten STADS eller Fælles IT) er installeret i testmiljøet Der er ikke udstående kritiske fejl fra tidligere testfaser som kan forhindre test gennemførelsen Alt bruger-rettet dokumentation er udarbejdet og uddannelse er gennemført for de brugere som skal deltage i testen. Der foreligger en godkendt testplan (programlederen godkender) Alle testcases er opdateret i Quality Center Adgang til et STADS miljø med relevant data Alle nødvendige leverancer (fra enten STADS eller Fælles IT) er installeret i testmiljøet Alle testcases er opdateret i Quality Center Adgang til et STADS miljø med relevant data Alle nødvendige leverancer (fra enten STADS eller Fælles IT) er installeret i testmiljøet Der er ikke udstående kritiske fejl fra tidligere testfaser som kan forhindre test gennemførelsen Alle testcases er gennemført Der foreligger en godkendt handlingsplan (programlederen godkender) for alle åbne defekts Der foreligger en godkendt testrapport (programlederen godkender) Alle testcases er gennemført Der foreligger en godkendt handlingsplan (programlederen godkender) for alle åbne defekts Der foreligger en godkendt testrapport (programlederen godkender) Alle testcases er gennemført Der foreligger en godkendt handlingsplan (projektlederen godkender) for alle åbne defekts Der foreligger en godkendt testrapport (projektlederen godkender) Alle testcases er gennemført Der foreligger en godkendt handlingsplan (programlederen godkender) for alle åbne defekts Der foreligger en godkendt testrapport (projektlederen godkender) Side 13 af 20

14 Testfase Startkriterier Slutkriterier Performancetest Drifttest Performance krav opdateret i Quality Center Alle testcases er udviklet i Loadtest værktøjet Loadtest værktøj er installeret Adgang til et STADS miljø med relevant data samt kapacitet Alle nødvendige leverancer (fra enten STADS eller Fælles IT) er installeret i testmiljøet Nødvendige monitoreringsværktøjer installeret Der foreligger en godkendt testplan (projektlederen godkender) Driftskrav er opdateret i Quality Center Testcases er opdateret i Quality Center Adgang til et STADS miljø med relevant data Nødvendige monitoreringsværktøjer installeret Der foreligger en godkendt testplan (projektlederen godkender) Alle testcases er gennemført Der foreligger en godkendt handlingsplan (programlederen godkender) for alle åbne defekts Der foreligger en godkendt testrapport (programlederen godkender) Alle testcases er gennemført Der foreligger en godkendt handlingsplan (projektlederen godkender) for alle åbne defekts Der foreligger en godkendt testrapport (projektlederen godkender) Konverteringstest Alle nødvendige leverancer (fra enten STADS eller Fælles IT) er installeret i testmiljøet Konverteringsstrategi er godkendt Konverteringstestkrav er opdateret i Quality Center. Testcases er opdateret i Quality Center Der foreligger en godkendt testplan (projektlederen godkender) Alle testcases er gennemført Der foreligger en godkendt handlingsplan (projektlederen godkender) for alle åbne defekts Der foreligger en godkendt testrapport (projektlederen godkender) 5 Risikoanalyse I dette kapitel beskrives de risici, der ses for programmets test. De listede risici her repræsenterer et statisk billede af en analyse foretaget 14/12/2009. Det planlægges, at disse risici løbende vurderes (slutning af hver måned) af testlederen og præsenteres til programmet i det første programmøde i hver måned (start februar 2010). Risiko Konsekvens Sand- synlig- hed Impact Planlagte foranstaltninger Ikke tilstrækkelig kalender tid / testressourcer i projekterne til at planlægge og designe test med den nødvendige kvalitet Testplaner indeholder ikke realistiske datoer og estimater Alle identificerede testcases kan ikke forberedes før testafvikling. Mellem Mellem Testressourcerne estimeres i Q og revurderes hver kvartal Testcase forberedelse prioriteres for at sikre højt prioriterede testcases afvikles Side 14 af 20

15 Risiko Konsekvens Sand- synlig- hed Impact Planlagte foranstaltninger Ikke tilstrækkelig kalender tid / testressourcer i projekterne til den planlagte og forberedte test. De godkendte testplaner dækker ikke det fremtidige faktiske brug af STADS løsning Testmetoderne og værktøjerne bliver ikke brugt ensartet i de forskellige teams og projekter Konvertering bliver kritisk forsinket således at testfaser, som er planlagt til at kører på konverteret data, ikke kan gennemføres Ikke testet kombination af konverteret data kan ikke behandles af STADS efter ibrugtagning Testcases har ikke den fornødne kvalitet Test dækning for lav Fejl, der ikke når at blive identificeret, vil komme til udtryk i produktionen Visse forretningsprocesser vil ikke blive testet Fejl, der ikke når at blive identificeret, vil komme til udtryk i produktionen Visse forretningsprocesser vil ikke blive testet Test bliver planlagt og afviklet forskelligt Der opstår misforståelser Det bliver svært at danne et realistisk overblik over løsningens samlede kvalitet Ny strategi for testdata skal udarbejdes Kvalitet af testen bliver væsentlig lavere Fejl, der ikke når at blive identificeret, vil komme til udtryk i produktionen Dele af konverterings øvelser skal genkøres (den reelle konsekvens er afhængigt af den godkendte konverteringsstrategi samt ibrugtagningsstrategi) først Under testforberedelsen følges der op på forbrugt tid og test estimaterne løbende vurderes Lav Mellem Testressourcerne estimeres i Q og revurderes hver kvartal Testcase afvikling prioriteres for at sikre højt prioriterede testcases afvikles først Under testafvikling, følges der op på forbrugt tid og test estimaterne løbende vurderes Lav Mellem Testplaner bliver reviewet i tværgående teams for at sikre testdækning Brugere fra hovedorganisationer inddrages i testplan godkendelse Mellem Lav Der skal følges formelt op på, at projekter arbejder anvendende de fastlagte arbejdsgange og metoder Der vil blive arrangeret tilbagevendende koordineringsmøder mellem alle testmanagers Lav Høj Kritiske forsinkelser i datakonverterings projekt bliver eskaleret til programledelsen Alternative strategier bliver udarbejdet så snart at det kan ses at kritisk forsinkelse ikke kan undgås Lav Høj Alle testfaser kører på konverteret data i det omfang det er muligt Der planlægges og afvikles en separat konverteringstest Fallback strategi laves for denne risiko Side 15 af 20

16 Risiko Konsekvens Sand- synlig- hed Impact Planlagte foranstaltninger Leverancer fra leverandører er kritisk forsinket, således at integreret tests ikke kan gennemføres Testen skal replanlægges (og muligvis forberedes igen) for at tage højde for den manglende leverance. Kvalitet af testen bliver væsentlig lavere Lav Mellem Højt prioriterede leverancer (som SOG, STADS åbne grænseflade, ) specificeres og leveres så tidligt i programmets forløb som muligt. Alternative strategier bliver udarbejdet så snart at det kan ses at kritisk forsinkelse ikke kan undgås 6 Testmiljøer og testdata Ansvar for oprettelse samt vedligeholdelse af testmiljøer er en del af Miljø projektet (Test-, produktions-, og undervisningsmiljø). Detaljerede krav til miljø og data vil specificeres yderligere i de forskellige tests testplaner, men generelt kan der siges: 1. Alle tests vil køre på konverteret data hvor muligt. 2. Miljø for systemintegrationstest samt brugeraccepttest vil omfatte flere systemer end STADS (der anbefales at bruge det samme miljø). Krav til dette miljø vil udformes under detaljering af disse tests testplaner. Testdata i dette miljø skal være konsistent på tværs af de forskellige systemer (for de testcases som skal køres). 3. Hvis en testcase kræver data udover det som leveres af miljøprojektet, er det projektlederens ansvar (i samarbejdet med testlederen) at planlægge og gennemføre hvordan disse data loades på miljøet, samt hvordan det kan genskabes (hvis nødvendigt). 4. Performancetest del 2 skal køre på et testmiljø som er produktions nær (samme kapacitet) og med konverteret data i produktions størrelse. 5. Hvis det er muligt og praktisk, skal miljøerne altid have den seneste release af STADS samt de øvrige leverancer, når der køres test. Testplanen skal indeholde en klar definition af hvilke release af løsningen testen skal afvikles på. 7 Testroller og uddannelsesbehov 7.1 Roller Følgende beskrivelser dækker relevante rollers ansvarsområder i forhold til test. Disse roller kan være defineret med flere detaljer i de forskellige tests testplaner. Side 16 af 20

17 Roller Programleder Testleder Projektleder Tester STADS samarbejdet Leverandøren Ansvarsområde Opfølgnings- og rapporteringsansvar for det samlede program inklusiv test og dets igangsætning Primær kontaktperson for testrelaterede issues og spørgsmål Ansvarlig for den overordnede og tværgående teststrategi Overordnet opfølgningsansvarlig for testaktiviteter Overordnet ansvar for uddannelse af testressourcer i testværktøjer og metoder Rapporterer samlet omkring test Koordinering med øvrige interessenter i testen udenfor projektet Sikrer, at fejl prioriteres efter vedtagne principper Sikrer, at den samlede test afsluttes jf. gældende slutkriterier Sikrer synliggørelse af, at testen er afsluttet, således at ibrugtagningsaktiviteterne kan igangsættes Overordnet ansvar for det samlede projekt inkl. test og dets igangsætning Allokering af de fornødne ressourcer til test jf. estimater fra testplan Sikrer, at den enkelte tests startkriterier er opfyldt før påbegyndelse. Sikrer, at fejl prioriteres efter vedtagne principper Sikrer, at den enkelte test afsluttes jf. slutkriterier samt frigives til næste fase Udarbejder testcases Testafvikling, fejlrapportering og gentest Sikrer, at fejl prioriteres efter vedtagne principper Vedligeholder testlog som dokumenterer den udførte test Godkender testcases for brug i STADS kundesystemtest samt kundeaccepttest Udover udvikling og fejlretning er leverandøren ansvarlig for unittest, modul integrationstest og leverandør systemtest samt udarbejdelsen af testcases til disse testes. 7.2 Behov for uddannelse Test foretages primært af procesprojekternes deltagere der har udarbejdet specifikationer (krav og mulige usecases) til de relevante forretningsområder. Det kan forventes at en stor del af disse deltagere ikke tidligere har 1) arbejdet struktureret med test eller 2) brugt et teststyringsværktøj som Quality Center. Der skal derfor prioriteres at testerne uddannes i relevante test metoder samt de praktiske procedurer om, hvordan man bruger Quality Center til at forberede og udvikle en struktureret test. Side 17 af 20

18 Uddannelsen vil blive udført af testlederen og forventes at tage ca timer (opdelt over 3-4 workshops). Testerne for de forskellige tests vil bestå af både uddannede administrationsmedarbejdere, projektledere, IT udviklere, driftsmedarbejdere og evt. studentermedhjælpere. Målet er, at gruppen konstant bliver udvidet, således at der med tiden opstår en pulje af testerer, der kan trækkes ind, hvis og når det er nødvendigt. Side 18 af 20

19 8 Testestimater Detaljerede testestimater bliver først udarbejdet under færdiggørelse af testplanen. For at støtte dette arbejde, samt give et første skøn (WAG=WildAssGuess) over den totale testressource behov, er der udviklet et regneark som kan bruges til test estimering. Et uddrag af dette regneark vises nedenfor. Regnearket vil blive videreudviklet under hele programmet for at kunne give programlederen samt projektlederen et klart billede af det forventede testressource behov. Estimerings input Forbered testcase 2 timer Review testcase 0,75 timer Forbered testdata per testcase 0,2 timer Systemintegrationstest - Antal testcases 700 TC's - Afvikle testcase 0,5 timer - Antal gang TC afvikles 3 gang - Defekts pr TC 1,25 defekts Brugeraccepttest - Antal testcases 250 TC's - Afvikle testcase 1 timer - Antal gang TC afvikles 1,5 gang - Defekts pr TC 0,5 defekts Defekt lukningstid 2,5 timer Møder, uddannelse, % 15% Antal defekts fundet SIT Antal defekts fundet BAT Timer pr årsværk Samlede testestimat uden testlederen Systemintegrationstest Brugeraccepttest Performancetest Driftstest Konverteringstest Total 875 defekts 125 defekts 1600 timer 6430 timer 1220 timer 4510 timer 680 timer 920 timer 630 timer 520 timer timer 9 Testværktøj For at sikre at alle projekter kan planlægge, forberede, udføre og afslutte test så effektivt som muligt, vil programmet anvende testværktøjer og lægge vægt på at uddanne testressourcer rigtigt. I dette kapitel beskrives de værktøjer, som er af tværgående karakter (udover de nævnte vil der være snitflader med fx Logicas supportsystem via fejlrapporter...) Side 19 af 20

20 HP Quality Center 10.0 Anvendes som primært værktøj til styring af krav, usecases, testcases, fejlhåndtering, afrapportering etc. Microsoft Office (Word, Excel, Powerpoint ) Standard MSOffice dokumenter gemmes i enten 2003 eller 2007 format. MS Sharepoint Benyttes til arkivering og deling af dokumenter Andre værktøjer som fx LoadRunner (til performance test) kan blive inddraget. Side 20 af 20