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

T: Testfall - behövs de?

Av Charlotta Carlsson 2020-03-01

När någon säger "test" så tänker väl de flesta av oss på testfall. Men vad är de till för egentligen? Behövs det testfall i en acceptanstest?

Jag skulle säga att det beror på situationen - vad det är för slags leverans, vad syftet är med testen, vem som ska testa, hur bekant är testsituationen, och om det finns några andra underlag att använda. Testfall har faktiskt, om du tänker efter, inte något egenvärde som produkt. Så skriv inte testfall utan att först reflektera över syftet. Men min erfarenhet säger att testfall är ett kraftfullt arbetsverktyg. Troligen kommer du fram till att de behövs.

Kärnan i ett testfall är i princip uppbyggt på följande vis, och det gäller alla testnivåer, allt ifrån automatiserad testkod i en continuous delivery-miljö till traditionell acceptanstest:

1. Gör så här - Då ska detta hända (förväntat resultat)
2. Gör så här - Då ska detta hända
3. etc

Att "köra" testfallet innebär att man gör steg 1, 2 etc i tur och ordning. Om det händer som ska hända, så är teststeget godkänt. Annars har man (troligen) hittat ett fel.

Den stora potentialen i testfall är därför att de innebär en konkretisering av förväntningarna. Jag brukar faktiskt säga att det är bland annat det som gör att jag tycker om att jobba med test (oavsett om man skriver testfall alltså): när man tänker test går det inte att glida på målet längre, utan allting måste plötsligt bli väldigt konkret. Det är väldigt befriande - men kan förstås också vara svårt!

Här är några anledningar att använda sig av testfall i acceptanstest, samt lite tankar om det kan finnas alternativ:

1. Kravverifiering. Om vi jobbar med testfall parallellt med kravdetaljeringen och utvecklingen så fungerar de som ett sätt att verifiera kraven. Kan du inte lista ut hur testfallet ska skrivas, så ställ frågor! Kanske upptäcker ni då att det fattas något i specifikationen. I arbetet med att ta fram testfallen finns därför en potential att hitta fel tidigt. Här behövs en samsyn mellan systemleverantör/IT och beställare/verksamhet om hur testfallsframtagningen ger input. Bestäm er för ett mönster för dokumentationen där krav och testfall hänger ihop.

Men om..
..det gemensamma krav- och utvecklingsarbetet utmynnar i väl dokumenterade, konkreta beskrivningar av arbetsprocessen och hur användarna ska stödjas av systemet, gärna i ett visualiserat flöde, eller att systemlösningen växer fram efter hand via körbara prototyper som användare får ge input kring, så kan jag tänka mig att det i vissa fall täcker behovet av "kravverifiering" och då skulle inte testfall behövas för det syftet.

2. Tänka efter. Genom att ta fram testfall får du chansen att i god tid klura ut alla möjliga varianter som behöver testas. Du hinner utreda oklarheter, lära dig mer om systemet, och ställa frågor till olika intressenter. Testfallsarbetet blir nästan som en utbildning och bidrar samtidigt till kartläggning av de praktiska konsekvenserna i verksamheten.

Men om..
..det är frågan om ett befintligt system, en begränsad leverans av mindre saker och testare som vet precis vad som förväntas komma så kan jag se att alternativet att bara sätta sig och köra utan testfall är fullt möjlig. Men jag skulle förorda någon from av avprickningslista i vilket fall som helst.
 
3. Manus. Testfall fungerar som ett manus för den som ska testa. Detta är naturligtvis till hjälp för testare som är nya på området, men även för den som kan både systemet och verksamhetsbehovet bra; i testsituationen är det ofta stressigt och att i det läget behöva uppfinna hjulet är ingen bra idé.

Men om..
..det finns en risk att testfalls"manuset" blir alltför styrande så att nya bra testidéer inte kommer upp? Ja den risken finns. Det är bra att komplettera de förutbestämda testfallen med utforskande test.
..testfallen är fel? Ja det kan förstås hända, speciellt om någon försökt skriva dem på en detaljnivå innan systemlösningen varit känd. (Det här är ett knepigt dilemma som jag skriver mer om vid bokstaven N: Nu ska vi skriva testfall)
..det som i punkt 1 finns andra tydliga flödesbeskrivningar som täcker in det som man vill testa, så kanske det kan fungera som ett underlag istället för testfall. Det behöver troligtvis kompletteras med användarhandledningar, om det är komplexa funktioner och användargränssnitt.

4. Testtäckning. Genom samlingen testfall så får ni bra överblick över vad som ska testas. Dels på planeringsstadiet för att få koll på testtäckningen av leveransen/kraven. Och för att se hur du ska fördela ansvaret för olika testområden. Dels under pågående test för att följa upp vad som är testat och vad som återstår.

Men om..
..det finns något annat sätt att få överblick över helheten och testtäckningen så behövs inte testfall av den anledningen. Men jag tror det oftast finns fler anledningar så då kommer detta på köpet.

5. Spårbarhet. Genom att koppla kraven till testfall och sedan koppla felrapporter till testfall får du en spårbarhet hela vägen. Du kan över tid hålla reda på testresultatet per krav. Detta går fint med tillgång till ett bra testverktyg. Men gäller även i enklare situationer där det räcker med ett excelark (mer om testverktyg vid bokstaven V)

Men om..
..det känns som overkill att skapa en avancerad struktur med spårbarhet mellan krav och testresultat - så är det antagligen det! Allt beror på situationen. Men det behöver inte vara alltför stor testomfattning innan det börjar bli svårt att få koll.

6. Återanvändning.  Här får jag backa lite från påståendet i början att testfall inte har något egenvärde som produkt. I den mån de speglar en återanvändbar kunskap som någon annan kan återanvända i senare leveranser som kan testfall faktiskt vara en output. Problemet med det är dock att en situation aldrig är den andra lik. (mer om det vid bokstaven Å: Återanvändning)

Men om..
..liknande tester aldrig mer kommer vara aktuella att göra så faller återanvändningsargumentet.

Nu vill jag också passa på att säga vad testfall INTE är enligt mitt sätt att se på saken:

• Testfall är inte något som ska "godkännas" av någon i någon avtalsmässig mening. Däremot kan de med fördel granskas av olika intressenter som en del i framtagningen, vilket ökar kvaliteten. Ordet "granskning" har jag märkt kan leda till formella diskussioner kring testfall som inte är särskilt lyckat. Testfall är ju bara ett arbetsmaterial som ständigt är under pågående översyn!

• Testfall är inte ett facit. Det kan faktiskt vara fel på testfallen. Däremot visar ju "felaktiga" testfall att det finns behov av ytterligare information och förtydliganden i någon ände.

• Testfall funkar inte som lathundar till användare. Jag har varit med om att det funnits en ambition att det ska gå att kombinera. Men det har inte lyckats. Jag tror det beror på att det är olika syften. Däremot vet jag att färdiga lathundar och användarmanualer är till stor hjälp för testare.

Till sist: "Nog finns det mål och mening i vår färd - men det är vägen, som är mödan värd." (Karin Boye) Detta gäller i allra högsta grad arbetet med testfall!

Slutsats för bokstaven T: Testfall gör nytta för det mesta.