https://commons.wikimedia.org/wiki/File:Godin_van_de_Wind_4_Nieuwpoort.jpg

P: Prioritera proffsigt från verksamhetens perspektiv

Av Charlotta Carlsson 2020-06-02

Höjden av professionalism måste väl vara att kunna prioritera. Prioritera upp och prioritera bort. Och motsatsen: att inte klara att prioritera tyder på bristande erfarenhet och förmåga att lyfta blicken. Eller..?

Som erfaren systemutvecklare, systemtestare, IT-projektledare och kravledare men relativt nybliven testledningskonsult på mitt första större uppdrag som acceptanstestledare satte jag självklart upp prioriteringsgrunder i teststrategin. Så här stod det, visst låter det bra? Testa ur ett riskperspektiv minsann, bara en sån sak!

"Tester prioriteras sinsemellan så att man försäkrar sig om att alla de högst prioriterade testerna hinns med. Prioriteringarna påverkar både hur många/djupgående testfall man tar fram och hur man ska agera vid tidsbrist under acceptanstestperioderna. Testgrupperna gör prioriteringen utifrån ett riskperspektiv: på vilka områden man har anledning att misstänka att flest avvikelser kan hittas eller var skulle avvikelser få stor negativ verksamhetspåverkan i produktion? Det kan vara:

• Komplexa verksamhetsprocesser
• Verksamhetskritiska funktioner
• Funktioner där konfigurationer och parametersättningar har varit svåra att definiera under projektets arbete
• Nyutvecklade funktioner
• Verksamhetsprocesser som spänner över systemintegrationer"

Jag tycker fortfarande att de här prioriteringarna är "rätt", inte minst att riskperspektivet är grundläggande. Strategin fungerade rätt bra som vägledning för mig som testledare. Du som läser kan nog plocka med dig detta som förslag till din testverksamhet. Däremot märkte jag när prioriteringsstrategin skulle implementeras, att det finns särskilda dimensioner i just acceptanstest även i prioriteringar.

Jag bokade in en första prioriteringsworkshop och hade förväntat mig stor entusiasm för detta, eftersom det var ett hårt pressat gäng som skulle förbereda testunderlag och testa. Döm om min förvåning när reaktionen blev:

"Men Charlotta, vi måste såklart testa allt."

What? Även om detta inte betydde att vi avbröt mötet eller lät bli att prioritera, så var det en väckarklocka för mig. Jag fick lära mig att i acceptanstest behöver man även vad gäller prioriteringar ta andra hänsyn än i mer utvecklingsnära tester även om grundtänket är detsamma. Acceptantest är speciellt för att:

• Det är då frågan om inte bara att hitta fel, utan också, kanske främst, att landa systemet i en verksamhet. Då finns det ett värde i att köra igenom "allt", även de funktioner och
  processer som kanske är väldigt basic och inte kan antas innehålla särskilt mycket fel och problem.
• De som testar är verksamhetspersoner som inte tänker test utifrån systemarkitektur eller testtekniker. Istället för att t.ex. försöka övertyga dem om att det är onödigt att testa flera liknande flöden om det första fungerar eftersom det borde vara samma programkod som körs, så ger det trygghet inför driftsättning att se sina vardagliga verksamhetsscenarios in action. Man kanske även i samband med test passar på att ta fram lathundar för användarna! Sådant behöver man respektera och det finns ett stort egenvärde i det.
• Om flera olika verksamhetsgrenar berörs av systemleveransen kanske inte alla är lika superkritiska ur ett företagsledningsperspektiv eller kanske de inte påverkar lika många användare. Men att prioritera bort hela verksamhetsområden från testen är ändå ingen bra idé: varje användargrupp behöver få ta emot sin del av leveransen som en bekräftelse på utfört projektarbete.

Med en ödmjukhet för detta är det ändå testledarens roll att hjälpa till med prioriteringarna. Det gamla devisen "man kan aldrig testa allt" är fortfarande aktuell. Jag föreslår en trestegstrappa för det arbete. Jag tänker mig då att man redan har kartlagt bruttolistan av testområden (t.ex. verksamhetsprocesser, funktioner, krav) som ingår i testens omfattning och att det finns en tydlig och överskådlig lista/bild av detta.

1. Beskriv förutsättningarna inför prioriteringarna: Vad är syftet med testen? Vad blir då våra prioriteringsgrunder? Hur mycket tid har vi till testförberedelser och test? Hur viktigt är komplett testresultat på nylevererade funktioner? Osv.
Detta görs generellt för hela testen, gärna i workshopform. På detta stadium kan det finnas övergripande prioriteringar där man lägger mer resurser och analysarbete på vissa verksamhetsområden/processer än på andra, däremot rekommenderar jag som sagt inte att prioritera bort hela verksamhetsområden.

Steg 2 och 3 lämpar sig att göra med fokusgrupper inom varje verksamhetsgren (tänk avdelning), också gärna i en workshop.

2. Tag listan/bilden med alla testområden och ringa in de högst prioriterade utifrån prioriteringsgrunderna. Det kanske kan få bli en tredjedel till hälften av områdena. Vilka delar ger störst affärsnytta (och därmed viktigast att de fungerar bra)? Vilka funktoner används mest? osv. (Kanske tänker du som läser detta nu att det redan bör finnas en prioritering av kraven,
och då gäller samma i test? Absolut, så kan det vara, men det är nog inte hela sanningen. Ett högt prioriterat krav kan vara superenkelt att implementera och därmed inte lika riskfyllt.
Ett lägre prioriterat krav kan å andra sidan vara oerhört viktigt att det fungerar prickfritt när det väl levereras! Dessutom kan man behöva testa saker som inte finns uttryckta i specifika krav,
t.ex. påverkan på hela verksamhetsprocesser av en viss ändring.)

Nr 2 sker i början av testförberedelserna i samband med att man börjar ta fram testfall eller annat underlag. Man får bra input till såväl testfallsframtagning (vad ska vi förbereda extra noga?) som tidsplanering och resurssättning av själva testen i god tid. Högst prio = flest eller mest kvalificerade resurser och mest tid.

3. Tag listan/bilden igen och kryssa över de testområden som ni kan tänka er att prioritera bort vid tidsbrist. Detta görs lämpligen närmare inpå själva testerna när det verkliga tids- och resursutrymmet börjat klarna.

Voilá! Proffsigt och vägledande prioriteringsarbete är gjort! Men hur blev det nu, vad SKA man prioritera och inte...?

Tja, att ge mer konkreta råd om vad som bör prioriteras i test rent allmänt är förstås vanskligt men om du verkligen vill så kan jag ändå till sist skicka med ett sådant generellt råd: Verksamhetsprocesser som spänner över systemintegrationer bör i stort sett alltid prioriteras. (Läs mer vid bokstaven I.) Dessa tester är förmodligen extra krångliga och tidskrävande men det får inte låta er avskräckas! Tvärtom signalerar det att det finns extra stort behov av test: krångligt att testa är ofta = riskfyllt i produktion.

Slutsats för bokstaven P: För acceptanstest görs en proffsig prioritering utifrån verksamhetens behov.