Tjeklister

Henvendt til kravstiller, som bør overholde nedenstående principper - og til testeren, som bør sikre, at principperne er overholdt:

• Testbarhed - alle krav skal kunne verificeres objektivt
• Sporbarhed - alle krav skal kunne spores til systemets specifikationer
• Unikt - krav må kun optræde en gang
• Nedbrudt - krav skal nedbrydes til mindre dele
• Højt niveau - krav skal være formuleret i forhold til det endelige behov, ikke i forhold til løsningsmodel
• Kvalitet - kravets kvalitetsfeatures skal være defineret (sikkerhed, performance, brugervenlighed m.m.)
• Solidt - krav skal være en robust base for design (godkendelse/change management)

Henvendt til test manageren - flere af opgaverne herunder vil kun være relevante i forhold til formelle reviews - se i øvrigt beskrivelse af de forskellige reviewtyper.

• Definer testgrundlaget - Hvilket arbejdsprodukt skal reviewes - eksempelvis kontraktkrav, systemdesign-specifikation (arkitektur), teknisk systemdesign-specifikation (detaljeret specifikationer), kode, test-arbejdsprodukter (teststrategi, testplan, testcases, testrapport, indgangs- og udgangskriterier).
• Vælg review-form -  uformelt review, walkthrough/kodereview, teknisk review, inspektion, audit
• Udvælg kvalificerede deltagere i reviewet. Hvilke faglige vinker skal repræsenteres?
• Tildel reviewroller til hver deltager - Roller i reviews
• Hvilke kvalitetsegenskaber skal evalueres? Definer fokus for hver deltager: sporbarhed, testbarhed, målbarhed etc. 
• Identificer evt. nødvendigt baggrundsmateriale
• Planlæg hvordan observationer kommunikeres (review-møde eller individuelt skriftligt/mundtligt)
• Opdater testgrundlaget med observationer, fejl og anbefalinger.
• Rapporter om ændringerne.

Henvendt til modtager af dokumentationen (kravspecifikationen, specificeret systemarkitektur, specificeret løsningsarkitektur, detailspecifikation).
For alle dokumenter kontrollerer et uformelt review følgende:

• at pågældende specifikation findes
• at den er fyldestgørende
• at den er testbar
• at den er klar til realisering

På nedenstående link hentes en tjekliste med aktiviteter pr testniveau.

Aktiviteter pr testniveau

Henvendt til testeren - parametre, der er gode at overveje, når testbetingelser skal identificeres. 

SFDPOT/SFDIPOT udbyg hver overskrift med de elementer, der er relevante specifikt for dit scope.

• Structure (alt, der har med den fysiske løsning at gøre - eksempelvis kode, hardware, databaser, API´er, UI)
• Functions (alt det, produktet gør - eksempelvis applikation, beregninger, tid, sikkerhed, opstart/nedluk, multimedier, fejlhåndtering, interaktioner)
• Data (alt det, produktet processerer - eksempelvis input/output, sekvenser/combinationer, stort/lille, invalid, livscyklus, persistere, uafhængige/interaktive)
• Interfaces (enhver conduite, som produktet er udtrykt gennem - eksempelvis brugergrænseflade, systemgrænseflader, API, import/export)
• Platforms (alt, som produktet er afhængige af, som er udenfor projektet - eksempelvis eksternt hardware (tablet, mobil, desktop), eksternt software ((windows, IOS, android...), embedded komponenter) 
• Operations (hvordan produktet skal anvendes - eksempelvis brugere, miljø, normal brug, uønsket brug, ekstrem brug)
• Time (ethvert forhold mellem produktet og tid - eksempelvis input/output, hurtig/langsom, ændre rater/intervaller, samtidighed)

Et mindmap er et godt værktøj i denne sammenhæng - googl "SFDPOT", så kommer der flere eksempler op.

Henvendt til test koordinatoren/ test manageren

• Er testmiljøet booket? Se Reservation af testmiljøer
• Er testmiljøet klar til test
• Har alle relevante personer adgang til testmiljøet? Login, firewall
• Er testdata tilgængeligt på miljøet? 
• Har testdata den rette spredning og volumen?
• Kan data genskabes ved hjælp af backup eller på anden vis? Er backup´en lavet?
• Er det aftalt med projektlederen, hvornår der lægges nu version af koden på testmiljøet?

Henvendt til udvikleren

• CRUD - er der testet for, at data kan: 
  • Oprettes?
  • Læses?
  • Opdateres?
  • Slettes?
• Ækvivalensklasser
  • Er alle ækvivalensklasser identificeret? 
  • Er der testet med værdi for hver ækvivalensklasse?
  • Invalide input - er der testet med invalide input?
  • Er der testet for alle outputs?
• Grænseværdianalyse
  • Er der testet med højeste positive værdier i alle felter, tabeller, skærme, filer m.m.?
  • Er der testet med laveste positive værdier i alle felter, tabeller, skærme, filer m.m.?
  • Er der testet med "ulovlige" værdier i alle felter, tabeller, skærme, filer m.m.? Eksempelvis højeste værdi plus 1, laveste værdi minus 1
• Scenarier
  • Er der testet positive scenarier?
  • Er der testet negative scenarier?
• Testdata
  • Er der testet med realistisk data?
  • Er der testet med kildesystems testmiljø?
  • Er der testet med invalide input?
  • Er det testet med en meget lang input-streng?
  • Er det testet, om default værdier kan genskabes?
• Review
  • Er der foretaget kodereview med en udvikler-kollega? Er der en grund til, at kodereview er fravalgt?
  • Er der foretaget kodereview af testcases til komponent- og komponentintegrationstesten?
• Risiko
  • Er testen designet risikobaseret? Er de kritiske elementer testet mest jf. servicens (komponentens) risikoprofil.
• Fejlhåndtering
  • Er der testet for fejlbeskeder?
  • Er der testet for "ulovlige" operatorer?
  • Er det testet, hvordan data og service reagerer, hvis der ikke er hul igennem til kildesystemet (manglende internetforbindelse, kildesystem nede)?

Henvendt til tester og test manageren

• Er den planlagte testafvikling risikobaseret, så afviklingsrækkefølgen afspejler risikoprofil? Testcases med højest risiko og/eller forretningsværdi afvikles først?

• Er testresultatere dokumenterede i test management værktøjet eller i andet værktøj?

• Er fremdrift-oversigten opdateret (hvis ikke det håndteres automatisk i test management-værktøjet)?
• Er fremdrift kommunikeret til relevante intereressenter?

Henvendt til testeren

• Er der lavet testcharters?
• Er der lavet aftale om, hvordan testen og dens resultaterer dokumenteres?
• Lad dig gerne inspirere af tjeklisten til komponent- og komponentintegrationstesten.
• Er der testet positive scenarier?
• Er der testet negative scenarier?
• Funktionel test - fokuser testen på funktionel fuldstændighed, funktionel korrekthed og funktionel hensigtsmæssighed

Henvendt til testeren og udvikleren - se i øvrigt Fejlhåndteringsproces

• Er der information nok til at kunne genskabe fejlen? Forudsætning, input, forventet resultat, faktisk resultat? 
• Er det afprøvet, at vejledning til genskabelse faktisk genskaber fejlen?
• Er der vedlagt skærmbilleder, logfiler, stacktrace, etc. til at dokumentere fejlen?
• Er der linket til den/de testcase, som skal genkøres efter fejlrettelse?
• Er foreslået prioritet sat?
• Er forventet severity sat?
• Er testniveau, som fejl er fundet i, registreret på fejlrapporten?

Testmiljøer

• Hvilke muligheder er der for at få testmiljøer? 
• Kan man bestille ekstra testmiljøer?
• Hvad er prisen for et ekstra testmiljø?
• Kan vi populere med egne data? Hvordan?
• Kan vi rette i populerede data?
• Kan vi slette data igen? 
• Kan vi trække data ud af systemet? Hvordan og i hvilke formater?
• Er det muligt og meningsfyldt at få et brugbart udtræk af produktionsdata (til anvendelse ved end-of-life)?
  • Det bør testes kontinuerligt, at løbende ændringer ikke påvirker evnen til at lave udtrækket, når det engang skal anvendes.

 Compliance/IDM governance og integration

• Er der mulighed for at foretage compliance test (op imod data i IDM, IGA eller andre systemer)? 
• Kan systemet performe som kravsat, når der køres compliance test (imod IDM eller andre systemer)?
• Hvilke muligheder er der for at at rette op, hvis compliance viser afvigelser? 
• Kan der laves et anvendeligt udtræk via API´er fra systemet, som kan anvendes til compliance-test?
• Kan alle integrationer testes end-to-end?
• Kan alle integrationer overvåges end-to-end?
• Kan fejlhåndtering testes? 

Systemfunktionalitet

• Hvilke time outs er der i systemet? Hvordan passer leverandørens time outs med AUs?
• Kan timeouts hos leverandør optimeres ift AU processer?
• Hvordan afvikles køer? Hvordan passer det i vores landskab? 
• Hvordan fejlhåndteres der på køer?
• Hvordan håndteres race conditions (beskeder, der kan overhale hinanden – fx. at en opdater kan overhale en opret)? 
• Hvilke API´er udstilles?
• Hvilke muligheder er der for at få lavet nye API´er, hvis AU har behov for det?
• Hvordan er governance på API, f.eks varsling ved ændringer, bagudkompabilitet?

Performance og driftsstyring 

• Hvordan sikres performance dels i brugerfladen og dels via API? Pricing?
• Hvordan sikres performance/tilstrækkelig kapacitet ved initialisering af data i hhv. testmiljø og produktionsmiljø?
• Er der håndtag til at håndtere faldende performance?
• Hvordan håndteres throtling?
• Er der styr på backup?
• Hvordan sikres det, at vi undgår datatab?
• Udfører leverandør jævnligt test af restore/systemgenetablering?
• Hvordan er leverandørens katastrofeberedskab?

Sikkerhed og datastyring

• Er leverandøren sikkerhedscertificeret?
• Er der behov for udvikling af AU kompetencer for at sikre sikkerheden?
• Er der indgået eller er leverandøren villig til at indgå en databehandleraftale?
• Skal der laves aftale om audit på databehandleraftalen? I hvilket omfang, af hvem og hvordan?
• Skal sikkerhedsafdelingen konsulteres?
• Hvordan ser supportflowet ud? Kan det holdes i EU?  Også ved eskablering/second/third level support? Også efter kontraktindgåelse og på sigt?
• Der skal sikres at man som bruger kun kan se de data, man har lov til at se, og ikke mere - og at man generelt kun kan gøre det med dataene, som man skal kunne, og ikke mere.
• Er der mulighed for anonymiserede udttæk til statistik og tendenser?

Support

• Er der en beskreven proces for support?

• Er der en beskreven proces for eskalering?
• Er der en beskreven fejlhåndteringsproces?