Forvaltning

En teststrategi i en forvaltningsorganisation beskriver på overordnet niveau, hvorledes der arbejdes med test i den pågældende forvaltning. Strategien udarbejdes i overensstemmelse med i AU IT’s testpolitik. Skulle der være områder, hvor det ikke er muligt for projektets teststrategi at følge AU IT's testpolitik, skal dette synliggøres og begrundes i teststrategien.

Det er vigtigt at have forståelse for regressionstest ved opdateringer. Herunder er risikovurdering et helt nødvendigt værktøj.

Fokus på de elementer, der er nye eller ændrede

• Hvordan virker de "i sig selv"?
• Hvordan virker de i sammenhæng med den øvrige løsning?
• Kræver de ændrede opsætninger ændret konfiguration/opsætning andre steder i løsningen?
• Skal de slås til, eller er de der default?
• Ønskes de anvendt, hvis det er muligt at vælge? Testen bør afspejle valget.

Konsekvensvurdering af, hvordan ny funktionalitet påvirker eksisterende funktionalitet

• Det kan være svært at vurdere udfra en releasenote, og så kan det være nødvendigt at basere regressionstesten på de områder i løsningen, som er vurderet til at være forretningskritiske forretningsflows (typisk et mindre antal forretningsflows, som tester end-to-end).
• Er der integrationer, der bliver påvirkede?
• Er der arbejdsgange, der bliver påvirkede?

Man bør altid teste

• Integrationer - virker de efter opdatering?
• Kritiske forretningsflows
• Regressionstest af øvrig løsning

Proces for testen:

• Bred og stor regressionstest i testmiljøet 
• Mindre regressionstest/smoketest i produktionsmiljøet
  • Sikre, at integrationer kører (hul-igennem-test)
  • Sikre, at de absolut mest kritiske forretningsflows virker
  • Vær obs på ikke at lave ændringer i produktionsmiljøet, som ikke kan rettes tilbage (eller som efterlader sig spor

Regressionstest imod øvrig løsning

• Se opgaven "Leverandøren varlser en ny release til standardløsningen" - samme overvejelser er relevante, selvom det er en mindre udviklingsopgave.

Hvis det er en udviklingsopgave, skal det undersøges, hvordan testen er dækket på de nederste testniveauer- spørg udviklerne, om de har lavet unittest og integrationstest, hvad de tester for, og om de er afviklede på testmiljøet i forbindelse med udviklingsopgaven - og eventuelt også, om de afvikles, når koden flyttes til produktionsmiljøet. Spørg efter dokumentation for deres test. Vær obs på, at udviklere ofte nøjes med at lave unittest i udviklingsmiljøet, men overlader integrationstest til testeren eller driften, der skal deploye og release. I disse tilfælde er det vigtigt, at den, der står for integrationstest, sørger for at lave testen i det integrerede testmiljø, hvis mere end ét system er involveret.

Der skal laves systemtest af selve udviklings-/konfigurationsopgaven - virker "dimsen", der er udviklet/konfigureret i samspil med det øvrige system? 

• Er der behov for non-funktionelle test? Er performance vigtig? Er brugervenlighed vigtig? Er sikkerhed vigtig? 
  • Hvis noget vurderes som værende vigtigt, bør der planlægges med tilsvarende test. Hvis brugervenlighed er vigtigt, bør der planlægges med brugervenlighedstest.
• Er der defineret acceptkriterier? Så tag udgangspunkt i dem, når der laves testcases. Alle acceptkriterier skal være dækket - og i udgangspunktet af både positive og negative testcases, altså hvor man både tester, at det virker, men også tester, at det, der ikke må virke, faktisk ikke virker.
  • Hvis ikke der er defineret acceptkritererier, så lav i stedet et mindmap med testscenarier (testbetingelser - hvad skal testes) og bryd dem efterfølgende ned i testcases (hvordan skal scenariet testes - step by step).  Tjeklisten SFDPOT til testanalyse og -design er et rigtigt godt værktøj til at tænke hele vejen rundt om opgaven og til at identificere de rette testbetingelser. 
• Anden hjælp til identifikation af testscenarier:

For implementeringsopgaver i forvaltningen gælder følgende overvejelser:

• Lad testen tage udgangspunkt i specifikationer og releasenotes 
• Sørg for at testen er risikobaseret ud fra specifikationer og releasenotes - det kan overvejes, at den risikovurdering, der faktisk laves, dokumenteres i en testplan.
• For de situationer, hvor test i produktion er eneste mulighed, sørges for en tæt opfølgning efter idriftsættelse samt mulighed for at rulle ændringer af igen. 
• Dokumenter testen (i form af rollbackplan, testplan, testcases, fejlregistreringer og testrapport).