STAR Test af Release
Testplan ekstern integrationstest og end-to-end test
Formål med testplanen
Dette dokument beskriver overordnet, hvordan eksterne leverandører tester i en STAR release.
Testplanen beskriver, hvad der skal testes af ekstern integration og end-to-end test, men ikke nødvendigvis hvordan. Samt hvad der skal afleveres af test dokumentation.
Testproces
Op til hver release afgiver hver enkelt ekstern leverandører tilsagn til, hvilke epics de vil udvikle og teste op i mod.
Hver enkelt leverandør skal til hver release selv udføre test af deres eget udviklet kode f.eks. komponenttest, en komponentintegrationstest og en systemtest. Dette er helt uafhængig af denne testplan.
Testen, der skal foregå sammen med STAR, er ekstern integrationstest og End-to-End test (E2E), og det er denne proces, som beskrives her.
Testen er bestemt af de epic, som der er givet tilsagn til i releasen. Leverandøren har selv ansvar for at lave testcases til den eksterne integrationstest og eksekvere den.
Ekstern integrationstest
Integrationstesten skal afvikles i leverandørens system. Enten fra business laget (forretningslaget) eller fra den grænseflade, som slutbrugeren skal benytte. Testes der på business laget skal leverandøren sikre, at der fra grænsefladen, som slutbrugerne skal benytte, kan udføre de testcases, som er planlagt i end-to-end testen.
Leverandørens system skal være integreret mod STAR’s testmiljø.
Der må ikke benyttes stubbe/mocks objekter/detours.
Hvis der benyttes testautomatisering, skal testcases være implementeret, så de tester på det øverste lag – det lag som slutbrugeren skal benytte applikationen fra. Altså må der under ingen omstændigheder testes direkte på OLTP/Service/Webservice lag.
Det er leverandøren selv som står for at skrive og afvikle testcases.
End-to-End
Indholdet af E2E testen bestemmes og skrives af STAR systemforvaltning. Testcases til E2E leveres 14 dage før test start. Leverandøren skal i fællesskab med STAR systemforvaltning afvikle E2E testen.
Til at holde styr på eksekveringen af en testcase benyttes TopDesk.
Hver Leverandør modtager 14 dage før E2E starter:
Test testrapporteringsark i Excel, hvor leverandør bogfører sin plan for gennemførelsen af EI Integrationstest og E2E testcases.
Word Dokument med alle E2E Testcases beskrevet.
E2E testcases i Topdesk.
Når leverandøren er klar til test afvikling, initierer han testcasen i TopDesk som det første. Derefter afvikles testcasen trin for trin til den er færdig sammen med STAR Systemforvaltning.
I E2E testen skal alle testcases være gennemført, og der skal være taget stilling til alle fundne fejl for at testen kan godkendes.
STAR Systemforvaltning leverer E2E testcases så de er tilrådighed i releasen: Mulig ibrugtagning i prod i tilsagnsarket. Leverandør har mulighed for at gennemføre E2E på Epic indtil Seneste ibrugtagning i prod i tilsagnsarket.
Hvis en testcase udskydes til næste release sættes den POSTPONED i rapporteringsark, og testcase bliver dermed aktuel igen. Hvis testcase er gennemført i tidligere release sættes testcase OBSOLETE i testrapporteringsarket.
Testbasis
Indholdet af hvilke epic der indgår i en release fremgår af Epic release overblik på STARWIKI.
Hver enkelt leverandør har inden release start givet tilsagn til STAR Portefølje Manager, hvilke epic de har tænkt sig at udvikle, teste og sætte i drift. Tilsagnsprocessen bliver håndteret og styret af STAR Portefølje Manager.
Store Epics gives ofte mulighed for mulighed for opdeling i flere Releases. I tilsagnsarket kan Leverandør give tilsagn : Tilsagn til Løsning, Tilsagn til udvikling, Tilsagn til Test.
Tidsplan
Tidsplanen fremgår af Epic release overblik på STARWIKI
Generelt følges denne generiske tidsplan til test for hver release:
• Der er 6 uger til EI og E2E test.
• De første 2 uger er tiltænkt eksekvering af EI test.
• De næste 4 uger er tiltænkt eksekvering af E2E test.
• Fredagen før start på EI og E2E testen, udfylder hver leverandør et testreadinessark, som angiver hvorvidt leverandøreren er klar til at påbegynde test.
• Sidste dag i testforløbet leves endelig testrapportering. Fredag kl. 1600.
Visuelt ser det således ud. Den røde cirkelt indikerer tidsrummet EI og E2E foregår i:
Start og slut kriterier for testen
Testfase | Start kriterier | Slut kriterier |
End-to-End |
|
|
Ekstern Integrationstest |
|
|
For alle eksterne leverandører gælder at godkendelseskriterierne samlet set for en release er (som er henvendt mod STAR’s systemer):
| ||
Løbende testrapportering
Hver enkelt ekstern leverandør rapporterer ugentligt hver fredag kl. 1600 på test fremdriften. STAR systemforvaltning udleverer et testrapporteringsark til formålet, som er placeret på dokumentationsarkivet. Der skal rapporteres både på den eksterne integrationstest og End-to-End testen.
Systemforvaltning og hver leverandør har desuden et ugentlig telefonisk statusmøde, for at sikre at testen kører som den skal og der ingen forhindringer er til fremdriften på testen. Systemforvaltningen indkalder og afholder statusmøderne.
Endelig testrapportering
Efter 6 ugers test laver de eksterne leverandører hver deres endelige testrapportering på sidste dagen kl 1500.
Her verificeres at alt test er gennemført og om godkendelseskriterierne er overholdt.
Rapporten uploades til dokumentationsarkivet.
Testrapporteringsark udleveres af STAR systemforvaltning via dokumentationsarkivet.
Test status koder til brug i EI og E2E testen
Status | Forklaring |
Passed | Når testen er udført med succes |
Failed | Når en test er fejlet |
Not Completed | Angiver at en test er påbegyndt men ikke færdig testet endnu |
Planned | Angiver at en test er planlagt til at ske i en bestemt uge |
Not planned | Angiver at en test ikke er planlagt endnu |
Blocked | Når en test er blokkeret af en fejl enten i eget system eller i STAR system |
Obsolete | Når der ikke er givet tilsagn til løsningen eller når der ikke er noget test at udføre |
Postponed* | Angiver at man udskyder en planlagt test af en epic til et senere tidspunkt efter idriftsættelse af releasen |
*Bemærkninger til Postponed:
Hvis en testcase udskydes til næste release sættes den POSTPONED i rapporteringsark, og testcase bliver dermed aktuel igen. Hvis testcase er gennemført i tidligere release sættes testcase OBSOLETE i testrapporteringsarket.
Ideen bag ’postponed’ er IKKE at man skal påbegynde at udskyde test til andre releases. Tanken er stadig at man skal udføre alt test på de epic man har givet tilsagn til indenfor test perioden i releasen.
Man kan ’postponed’ en EI test og/eller en E2E test.
Reglen er dog at man skal sørge for at få udført EI og E2E testen i næstfølgende release, da funktionaliteten i test casen ellers kan risikere at ændre sig henover et release år pga. nye eller ændrede epics.
Udover at sætte E2E testcasen til ’postponed’ så skal den tilhørende E2E TopDesk-sag sættes i status ’resolved(postponed)’.
Systemforvalter vil overføre evt. ’postponed’ testcases (både EI og E2E) til næste release’s testrapporteringsark, så ekstern leverandør husker at få testcasen afviklet.
Hvis en ’postponed’ E2E testcase i TopDesk ikke er tilgængelig mere, så skal man oprette en TopDesk til SF med besked om at man vil teste E2E testcase med ID-nummer xyz.
ID-nummeret på E2E testcasen står i testrapporteringsarket.
Man skal være obs på at Systemforvalter ikke opdaterer de enkelte test steps i en ’postponed’ E2E testcase til at passe til funktionaliteten i en anden release.
Ekstern leverandør er i øvrigt altid selv ansvarlig for, at få udviklet og testet og dermed sikre sig at deres system kan fungere sammen med STAR systemet ved idriftssættelse af ny release. At udsætte udvikling og test er ikke en ansvarsfraskrivelse, hvis eget system efterfølgende fejler i produktion.
Testmiljø
Der henvises til miljø oversigten over hvilke miljøer der skal testes på.
Der skal benyttes testcertifikater på testmiljøerne. Disse fås ved at kontakte STAR systemforvalting.
Vær opmærksom på opsætning af Webservicebeskeder WSB, som leverandører fremover selv skal sætte op til modtagelse. Det svarer til opsætningen af WSRM som man bestiller i Systemforvaltning.
Test data
Systemforvalter dataløfter testmiljøerne med produktionsdata til hver release. Data vil være anonymiseret.
I dataløft planen fremgår det, hvornår der er/bliver dataløftet.
Ønsker man selv at generere noget testdata, som ikke kan dannes i egne systemer, er det muligt via værktøjet ”Datakanonen”. Der kan f.eks. genereres hændelser på vegne af et Jobcenter, som resulterer i, at der bliver genereret WSRM-beskeder til A-kassen. På denne måde undgås tunge arbejdsgange, med at oprette TopDesk-sager og afvente svar fra STAR systemforvalter testteam.
LSS bliver desuden også stillet til rådighed i testmiljøerne. Her er det muligt at danne hændelser på borgere, så de kan bruges i testøjemed. Det er også muligt i LSS at udsøge borger ud fra forskellige parametre.
Der er adgang til datakanonen og LSS via et personligt datakanoncertifikat, som kan bestilles via TopDesk.
Vejledning i brug af Datakanonen og LSS kan findes på Starwiki.