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

N: Nu ska vi skriva testfall 

- hjälp, hur börjar man?

Av Charlotta Carlsson 2020-09-28

Jag som är konsult läser en hel del uppdragsbeskrivningar för att hitta dem där min kompetens matchar. När uppdrag som testledare annonseras ut står det ofta först bland arbetsuppgifterna att "ta fram testfall". Det verkar finnas en bild av att testarbete går ut på att producera testfall. Visst, det är inte fel. Ofta är testfall ett kraftfullt verktyg för att reda ut och hålla ordning på vad som ska testas och hur. Men jag skulle vilja påstå att producerandet av själva testfallen (eller om du vill kalla dem något annat: scenarier, flöden...) är en ganska liten del av det som behöver göras för att få fram ett bra testunderlag. 

Om du kommer som testledare till en ny testgrupp som ska förbereda en acceptanstest och försöker få dem att direkt skriva testfall på första mötet så kommer det inte att gå så bra. (Tro mig, jag har försökt, tidigare under min karriär när jag kände viss press att leverera just testfall så fort som möjligt.) Du kan absolut gärna redan då berätta vad testfall är för något och varför ni kommer att ta fram dem (t.ex. för att hitta oklarheter långt före själva testen, eller för att ha som ett underlag när ni testar). Men du behöver backa bandet och göra lite annat innan det blir dags att sätta testfallen på pränt.

Allra första frågan är: vem ska skriva testfall för en acceptanstest? Jag tänker så här: För att få full utväxling av det arbetet (för testfall gäller "nog finns det mål och mening med vår färd men det är vägen som är mödan värd") bör det vara de personer från verksamheten som sedan ska vara med och testa. Dvs, verksamhetskunniga projektdeltagare som också är kravställare på detaljnivå under projektets gång, och som kanske sedan ska in i en roll som superanvändare.

Inom ramen för en acceptanstest kan det även finnas mer tekniska testområden och då utser man såklart andra slags testare.

Testförberedelserna går utmärkt att göra i workshopform, där flera hjälps åt att tänka och strukturera. Vägen fram till färdiga testfall kan se ut till exempel så här:

I gemensam arbetsgrupp för hela testen:

• Identifiera övergripande testområden, t.ex. utifrån krav, funktioner eller verksamhetsprocesser. 
• Gör en övergripande riskanalys för att komma fram till prioritering av testområdena.
• Bestäm vem som ansvarar för att testa och därmed detaljera testunderlaget för respektive område.
• Hitta eventuella beroenden mellan områdena där ansvariga behöver stämma av i testfallsarbetet

I gruppen som jobbar med ett visst testområde, t.ex. en viss verksamhetsprocess eller viss ny funktion:

• Om det inte redan finns, rita upp flödet/processen vem-som-gör-vad i och utanför systemet på grov nivå. Om det finns varianter som skiljer sig mycket åt kan man vilja rita upp flera olika. Ge varje flöde ett namn, t.ex. "Uthyrning av studentbostad"
• Sätt namn på de olika stegen i flödet/processen, t.ex. "Boka rum", "Starta ärende" eller "Skicka faktura". Dessa blir rubriker i de kommande testfallen.
• Identifiera för respektive steg "vad är det vi vill se när vi testar".  t.ex. "Sms går fram till kunden" eller "Fakturan syns hos attestanten". Detta blir så småningom till förväntat resultat i testfallen.
• Hitta beroenden till andra flöden, och andra förutsättningar (datakonvertering? integrationer? tekniska föutsättningar?)
  
• Skriva testfall. Som stöd kan det då gärna finnas en körbar systemmiljö, användarmanualer, eller gemensamt framtagna specifikationer för hur systemet ska fungera. Samt en testledare som coachar metodmässigt i hur man gör.
• Be kollegor och testledare granska testfallen. Prata med dem som man har beroende till.
• Arbeta med testfallen i omgångar allteftersom systemlösningen och kunskapen växer fram. 

Kanske (troligen) hittar man under det här arbetet frågetecken där den förväntade leveransen av systemet som ska stödja flödet inte är uppenbar. Då ska man inte bli ledsen utan tvärtom: Då har ju redan nu testarbetet gett ett kvalitetssäkrande värde eftersom testarna kan ta med sig frågan till systemleverantören eller andra forum och saken kan redas ut i god tid.

Förutom, eller istället för, traditionella testfall kan man arbeta med testidéer och/eller acceptanskriterier som hör till specifika stories eller krav. T.ex. när man arbetar med ATDD och specification by example på formen Given- when - then. Så är ofta fallet ifall organisationen har ett agilt och tvärfunktionellt samarbete där acceptanstestprocessen är integrerad med kravdetaljering och utveckling. Min arbetsgång ovan behöver förstås anpassas efter situation.

Slutsats för bokstaven N:  Börja med att få överblick innan du tar fram testfall.

PS. Läs gärna mer vid bokstaven T: Testfall-behövs de?,  Z: Zooma in eller ut - vilken nivå testar vi på egentligen?, P: Prioritera smart från verksamhetsperspektiv och U: Utbildas för att testa eller testa för att utbildas?