Delleveranceprøven skal måle på:
Delleveranceprøven gennemføres for enhver delleverance. En godkendt delleveranceprøve er således den umiddelbare forudsætning for og et indgangskriterie for den efterfølgende overtagelsesprøve.
Kort beskrivelse af delleveranceprøven
Begrebet delleverance anvendes om enhver aftalt leverance fra leverandøren med henblik på afprøvning før implementering og sidenhen ibrugtagning i AU's systemlandskab.
Begrebet anvendes, uanset om der er tale om en SaaS-løsning, en on-prem-løsning, der skal driftes på AU, eller hybrider inden for dette spektrum. Det essentielle er, at det er leverandøren, der har produceret en given leverance (udvikling, konfigurering (funktionel/non-funktionel), andet) på baggrund af en aftale og en plan, udarbejdet sammen med AU.
Designet af den enkelte delleveranceprøve afhænger fuldstændigt af delleverancens indhold (se herunder: Delleverancens fokus). Derfor er der mange testtyper i spil i fbm denne prøvetype.
Delleveranceprøven er således en forretningsorienteret afprøvning af, at AU’s krav til den enkelte delleverance, for så vidt angår specifik funktionalitet, arbejdsgange/processer, opsætning, konfiguration, integrationer, performance og dokumentation er opfyldt i delleverancen. Delleveranceprøven er først og fremmest en afprøvning af, at den pågældende delleverance fungerer korrekt under produktionslignende forhold.
Den enkelte delleveranceprøve omfatter ikke fornyet test af allerede leveret og godkendt funktionalitet og non-funktionalitet. Ved eksempelvis tværinstitutionelle eller nationale systemanskaffelser gælder, at såfremt funktionalitet / non-funktionalitet er testet og godkendt på tværinstitutionelt eller nationalt niveau, er det ikke også nødvendigt med en fuld test lokalt på AU. Test af funktionalitet og non-funktionalitet, der er leveret og godkendt i tidligere delleverancer, er således begrænset til regressionstest af, at den tidligere leveret funktionalitet / non-funktionalitet fortsat fungerer efter deployment til test af den aktuelle delleverance.
Set fra leverandørens side er en godkendt delleveranceprøve objektiv vidnesbyrd for, at pågældende delleverancen opfylder de krav, som AU har stillet til pågældende leverance.
Set fra AU’s side er en - af AU - godkendt delleveranceprøve betingelsen for, at delleverancen – sammen med øvrige, godkendte delleverancer - er klar til at udgøre grundlaget for den endelige og afsluttende overtagelsesprøve.
Delleveranceprøvens fokus
Delleveranceprøven måler på, at aftalte krav af alle typer, er opfyldt fra leverandørens side. Det drejer sig om:
Funktionelle krav
Non-funktionelle krav
Krav til brugervenlighed (non-funktionelt krav)
Integrationskrav
Dokumentationskrav
Krav til migrering
Hovedansvar | Udførende Leverandøren er udførende på de non-funktionelle test og test af driftsparathed. Leverandøren udarbejder følgende for de testyper, leverandøren er udførende på:
AU er udførende på funktionalitetstest, integrationstest og brugervenlighedstest. AU er udførende på at fremfinde og stille test data til rådighed for alle testtyper i delleveranceprøven, ligesom AU også har ansvaret for at bidrage med viden om AU's it-miljø i forhold til detaljer om opsætning af miljø, herunder netværk, integrationer, adgang med videre. AU udarbejder følgende for de testtyper, AU er udførende på:
| Godkendende Leverandøren udarbejder den samlede prøveplan for de testtyper, leverandøren er udførende på.
Leverandøren udarbejder den samlede prøverapport for de testtyper, levarendøren er udførende på.
Reviews af artefakter og resultater både før og efter delleveranceprøven sker fra AU’s side med involvering af Test manager og Data manager. Den endelige godkendelse af de samlede prøverapporter og prøveresultater gennemføres hos AU af Product Owner eller Systemejer. |
Involverede testtyper i delleveranceprøven
Alle involverede testtyper er på systemniveau, og delleveranceprøven omfatter relevante testtyper blandt nedenstående:
Funktionstest (E2E)
Test af funktionalitet og derigennem også konfiguration, opsætning, workflow, implementering af forretningsregler. Testen adresserer såvel positive som negative test.
Positive test:
Test af, at krav er opfyldt i tilstrækkeligt omfang, således at ønsket funktionalitet er indeholdt i den leverede delleverance.
Negative test:
Test, som skal sikre, at systemet er robust og pålideligt under alle anvendelser.
Brugervenlighedstest
Afprøver den aftalte og implementerede delleverances brugervenlighedstest med en repræsentativ gruppe af brugere
Systemintegrationstest
Tester, om grænseflader mellem systemets programmelenheder samt integrationer mellem systemet og AU fagsystemer eller andre tredjepartssystemer fungerer korrekt og i overensstemmelse med de beskrevne løsnings- og integrationspecifikationer.
Testen måler på, at alle de beskrevne integrationer/snitflader fungerer korrekt i henhold til delleverancen.
AU har ansvarlig for at bidrage med viden om AU's it-miljø i forhold til detaljer om opsætning af miljø, herunder netværk, integrationer, adgang med videre.
Dokumentationstest
Afprøver, at de leverede artefakter/den leverede dokumentation er fyldestgørende, korrekte og operationelle – både ift initialiseringen og den efterfølgende driftssituation
Test af driftsparathed
Afprøver, at non-funktionelle krav på de aftalte områder er mødt, herunder krav til sikkerhed og andre relevante compliance krav. I fokus er sikkerhed, svartid, skalarbarhed, stabilitet, fail-over, genoprettelse, performance samt diverse aftalte servicemål
Migreringstest
Sikrer, at data migreres korrekt, og at migrerede data kan tilgås og behandles korrekt i systemet i overensstemmelse med de stillede krav i kontrakten (forudsat, at datamigrering er en del af pågældende delleverance)
Miljø til prøveafvikling
For hver enkelt testtype i delleveranceprøven skal behovet for bestykning af det nødvendige og samlede testmiljø afdækkes og specificeres, således at miljøet kan bygges.
AU har for indeværende og i transitionsfasen frem mod implementeringen af en cloud-baseret integrationsplatform begrænsede muligheder for at stille integrerede testmiljøer til rådighed. Her vil man i stedet designe skræddersyede testmiljøer, der benytter stubbe/mocks og dermed i fornødent omfang simulerer sammenhænge i systemlandskaber, hvor den fulde sammenhæng ikke kan etableres. Dette vil eksempelvis være tilfældet, hvor cloudbaserede systemer skal bruge centrale on-prem-systemer på AU.
Data til prøveafvikling
På samme måde skal behovet for testdata til den enkelte testtype (både omfang, typer og karakteristika) afdækkes og specificeres. Dette sker i forbindelse med test designet, hvor en integreret del af arbejdet med test cases vil være at afdække, hvad der skal til af data (både omfangsmæssigt og ift test data karakteristika) for at gennemføre og vurdere resultatet af en given test case.
Generelt gælder, at omfanget af test data skal være lige-præcis-tilstrækkeligt og dækkende for den specifikke testtype. Jvf beskrivelsen af testmiljøer ovenfor, kan drivers og stubbe anvendes efter behov.
Startkriterier
Prøveafviklingen kan starte, når:
Acceptkriterier
Prøven kan godkendes, når den er gennemført efter prøveplanen, og følgende kriterier er imødekommet:
Test cases
Udarbejdes af leverandøren – reviewes og godkendes af AU som ovenfor beskrevet.