Inden du når her til har du allerede gennemgået denne Tjekliste til PO/PL samarbejdsprojekter og derefter igangsat OAT processen.

Som en del af OAT processen kan der i dette skriv læses om hvilke forventninger der er til leverandørerne ved modtagelse af leverancer, og hvilken QA proces leverancen gennemgår. Procesbeskrivelsen har til formål at skabe et overblik  og ridse overfladen. Det vil sige, at der lægges op til at inddrage QA leverandøren tidligt i leverancen for at minimere fejl ved leverance. Inddragelse kan betyde sparring på NSP platformen opsætning og den komplekse integration der eksisterer på NSP.

Forventninger til komponentleverandør ved modtagelse af leverance:

• Kode skal forefindes på subversion trunk som skal anvendes til den daglige udvikling således at al commit historik er tilgængelig.
• En release laves med et Maven versionsnummer (IKKE snapshot) og et subversion tag på formen "release-x.y.z" under folderen "tags".
• Samme folder struktur ved hver leverance
• Det er vigtigt at der kun er en afhængighed til NSP Nexus repository. Andre repoer er ikke tilladt.
• Alle konfigurationsfiler skal forefindes i eksempelversion med så realistiske opsætninger som muligt i forhold til "NSP In a Box"
• Send en mail til nsp.support@arosii.dk med "Leverance beskrivelse" I mailen og i "Leverance beskrivelsen" skal der være links til den version af de 7 påkrævede dokumenter som gælder for leverancen.
• Sørg for at alle relevante Jira sager er opdateret, har gennemfør transitionen "Leveret til QA"
• Det forventes at man har testet Installationsvejledningen og Driftsvejledningen ved at tjekke releasen ud på en NIAB, bygge den og deploye den på applikationsserveren.

QA proces:

• Softwaren bygges via et Pipeline script i en Jenkins installation.
• Koden og konfigurationsfilerne reviewes i det omfang det er muligt.
• De relevante binære pakker og konfigurationsfiler samles i en samlet leverance til driftsorganisationen.
• Der deployes så vidt muligt på et lokalt miljø der minder om test1 og tester om muligt at der er hul igennem.
• Der beskrives om muligt tests som driften kan gennemføre efter softwaren er kommet på test1.
• Konfigurationsfilerne gennemgås og der beskrives eventuelle komplikationer til driften.
• Hvis det er nødvendigt patches koden for at rette eventuelle fejl/mangler.