Acceptanstest vid implementering

För att implementeringar ska gå så smidigt som möjligt har vi ett standardförfarande för acceptanstest. Vi jobbar på det här sättet, med alla slags implementeringar och gentemot alla våra kunder. Dels för att vi med tiden samlat på oss erfarenheter om vad som fungerar bäst och dels för att en rutin minskar risken för fel.

 

Följande steg genomförs alltid i testprocessen:

 

SAT (Site Acceptance Test) - Pythagoras egenkontroll 
Det här är ett test som görs av Pythagoras i en uppsatt TEST-miljö för leveransen av systemet. Det görs, innan UAT (se nedan) för att säkerställa att leveransen så långt som möjligt är fri från fel. Efter genomförd SAT lämnar Pythagoras klartecken att all konfigurering och integration är färdigställd i kundens miljö.  

 

UAT (User Acceptance Test) - Kundens leveransprov 

Det här är ett test som görs av kunden med hjälp av acceptanstestprotokoll för respektive produkt och med de krav och förutsättningar som angavs i samband med avtalets påskrift. 

Målsättningen är att ha så få omfattande testtillfällen som möjligt, därför bör testet också ta med samtliga integrationer som ingått i implementeringen.

 

Dokument 

För dokumenteringen under UAT (se ovan) bistår Pythagoras med ett acceptanstestprotokoll som förklaras av er projektledare eller modulexpert inför respektive testtillfälle.

 

Ansvarsområden 

Pythagoras ansvarsområden: 

• Bistå med acceptanstestprotokoll och ifyllnad av krav från upphandling/avtal 
• Säkerställer att systemet är redo för genomförandet av acceptanstestningen för avsedd modul vid uppsatt test-tillfälle 
• Säkerställa att kunden har behörigheter och utbildning för att kunna genomföra de testfall som är aktuella 
• Återkomma med tidsuppskattning för eventuella restpunkter och åtgärder som uppkommer vid testningen 
• Ge användarsupport till kundens testorganisation 

 

Kundens ansvarsområden: 

• Säkerställa resurser för att kunna genomföra tester vid angivet datum 
• Förbereda eventuella testfall/systemdata som krävs för delområdets testning 
• Ansvara för att fylla i acceptanstestprotokollet med resultatet vid testning 
• Delta på uppsatt utbildning för testare 
• Planera med eventuella ytterligare leverantörer för testning av exempelvis integrationer vid angivet testtillfälle

 

 

Metodik för UAT-testning 

Skapa testfall 

1. Kunden har som ansvar att komplettera det i projektet framtagna acceptanstestprotokollet med de testfall som avser egen konfigurering och mot uppsatta avtalade/upphandlade krav. Det förväntade resultatet av respektive krav ska även dokumenteras i detta skede.
2. Eventuella kommentarer från upphandling/avtal ska även framgå i kolumnen för detta, då muntliga överenskommelser kring kravets lösning kan ha diskuterats där. 
3. Krav som inte går att göra utformade testfall för, tas direkt upp vid avstämningsmötet efter genomförd acceptanstestning och godkänns vid mötet och en kommentar läggs in i protokollet exempelvis i form av: ”Förnamn Efternamn godkänner härmed kravet efter visning/överenskommelse vid acceptansmöte den åååå-mm-dd” 

 

Planeringsmöte inför acceptanstestning 

Ett planeringsmöte hålls inför acceptanstestning för att reda ut ansvarsområden, resurser för testförfarandet     och att reda ut eventuella förutsättningar som krävs för att genomföra de planerade testerna.  

 

Acceptanstestprotokollet ses över med alla projektresurser och acceptanstestdeltagare som innefattas av testningen. Kunden ansvarar för att ha ett färdigt acceptanstestprotokoll redo att genomföras utan frågetecken kring hur kravet ska testas. Ett datum för genomförandet av acceptanstestningen sätts vid detta möte. 

 

Genomförande av testfall 

Kundens genomför acceptanstestningen med hjälp av de testfall som har formulerats vid förberedelserna och utfallet av testet registreras i acceptanstestprotokollet samt att ett resultat anges i kolumnen med samma namn.

 

Vid eventuella uppkomna fel registreras även en så kallad felkategori som motsvarar betydelsen av felet hos kunden.

 

Felkategorier vid acceptanstestning: 
 

A – Allvarliga 

Viktiga systemfunktioner är inte tillgängliga och acceptanstestningen måste stoppas om meningsfull testning inte kan utföras på grund av detta. Kräver omtestning. 

 

B – Betydande 

Icke-väsentliga systemfunktioner är inte tillgängliga med det finns sätt att kringgå felet för att nå förväntat resultat och acceptanstestningen kan fortsätta. Kräver omtestning. 

 

C – Mindre 

Mindre fel utan större påverkan på funktion. Exempel är felaktighet i texter, dokumentation eller liknande. Kräver en tidplan för åtgärd, men hanteras som restpunkt i projektet. 

 

D – Önskemål om förbättring 

Används om önskemål dyker upp under acceptanstestningen eller om ett rapporterat fel omvärderas tillsammans av kund och leverantör till en framtida förbättring. Dokumenteras som önskemål för framtida utveckling/konfigurering. 

 

Avstämningsmöte efter genomförd UAT

Pythagoras och kund går igenom resultatet av acceptanstestningen med hjälp av Acceptanstestprotokollet och ser tillsammans över eventuellt angivna Felkategorier som kunden tolkat vid testningen. Felkategorier som motsvarar A och B kräver omtestning, medan C- och D-fel hanteras som restpunkt liksom önskemål för framtida åtgärd av leverantören. C-fel förväntas leverantören åtgärda i en kommande utvecklingssprint, medan D-fel hanteras som ett önskemål utanför projektets scope. 

Pythagoras återkommer när testning åter kan göras för A- och B-kategorier, vilket raskt ska åtgärdas för att kunden ska kunna återuppta testningen. Nytt avstämningsmöte planeras då in efter nytt satt testdatum. 

 

Godkännande av Acceptanstestning

Efter genomförd acceptanstestning av modul/delområde med OK i Resultat-kolumnen i acceptanstestprotokollet, alternativt återstående C- och D-kategorier kan testningen antas godkänd och protokollet signeras av kunden.