Konsten att skriva bra testfall

 Jaime Gomez berättar om vad man behöver tänka på när man skriver testfall.

En dag frågade en kollega som arbetar på ett konsultföretag hur jag brukade göra för att skriva bra test instruktioner. Frågan är inte helt trivial och man kan inte svara utan att tänka lite extra. Först då efter dök upp i mina tankar den intressanta diskussionen om det är dags att lägga test instruktioner i källaren tillsammans med gamla minnen från urtiden eller om man ska utveckla det vidare. Det första alternativet är så omfattande i sina konsekvenser att vi lämnar det till någon annan gång. Om vi tar den andra väg, alltså att vi ska dokumentera och skriva test instruktioner kan jag säga att det handlar om en mix av fantasi, saklighet och balans.

Fantasi är ett nyckelord i hela resonemanget. Det handlar inte bara om att verifiera vad en knapp, en dropdown lista eller något annat objekt i en applikation gör för någonting utan också vad det inte gör och vad som händer när saker runt omkring påverkar det. Det handlar om att ha ett varierande perspektiv på testobjektet.

Jag brukar isolera funktionen eller testobjektet och med lite kreativitet tänka på alla möjliga saker som objektet kan påverkas av: andra funktioner, andra objekt, en beteende från ett extern objekt och framför allt påverkan från användaren. Man kan inte utgå ifrån att en användare gör alltid rätt. Det mänskliga misstaget är som vanlig en faktor som i stor utsträckning påverkar en applikation. När listan är klar sorterar jag det efter sannolikhetsnivå och sedan efter riskomfattning. Bara efter det kan jag veta ungefär vilka scenario som är värda att omvandla till ett testfall. Som alla vet mycket väl går det inte att testa allt. Det gäller att avgränsa det som är värt att testa.

Saklighet är en annan aspekt som är bra att ha i åtanke när man skriver testinstruktioner. Det är inte alls bra att skriva information som är redundant eller som inte har någonting med testobjektet att göra. Vi ska sträva efter information som ger testprocessen högre värde för att det är relevant för test exekvering och för att det skapa bättre förutsättningar för testare att göra ett bättre test helt enkelt. Om du testar en applikation med Client/Server arkitektur kan det vara relevant att säga till exempel hur kopplingen mellan server och klient sker i stället för att prata om hur databasen är modulerad. 

Balans är den tredje magiska faktor och det har en direkt koppling med saklighet. Med balans menar jag den bästa kombination mellan generella och detaljerade beskrivningar. Det är inte alls bra att skriva för många detaljer i ett testfall för det kräver större krafter för att underhålla det. Om testfallet är för detaljerat krävs det att testfallet måste uppdateras för minsta lilla förändring i testobjektet och detta kräver resurser som skulle kunna användas med fördel i testexekvering istället. Formuleringar som t.ex. ”Öppna dialogen och se till att artikelnamnet hanterar både strängar och integer” är en allmän formulering. Det säger inte hur man ska dialogen öppnas, var ska man klicka, i vilket fält ska testdata skrivas in osv. Det säger vad dialogen är tänkt att göra och vilket det förväntade resultatet är. Allt annan kringinformation förutsätter en duktig testare som tolkar och exekverar testet på bästa möjliga sätt. Därför kräver denna sorts beskrivning betydlig mindre resurser för att uppdatera. ”Då kan inte alla testare exekvera testfallet på samma sätt”, säger min vän lite förvånad. Ja, det är sant och där finns också en styrka enlig min mening. Om inte alla testare exekverar testet på samma sätt så möjliggör det att testprocessen berikas för att den exekveras från olika tankesätt och det ökar täckning. Det är utmärkt!

Man kan inte vara nöjd och tror att man är färdigt utan en riktig bra granskning. Detta moment är extrem viktig för att kvalitetssäkra slut resultatet. Var inte rädd för att man hitta saker i granskningsmötet. Det är själva poäng med mötet. 

Det sista jag vill tillägga är att man kan komma till en nivå där man skriver bra testfall bara genom att träna och träna. Allt teoretisk kunskap ger bara tips, men den verkliga färdigheten skapas med praktiken. Min uppmuntra är att alla ska utnyttja alla möjliga tillfällen för att skriva testfall och inte vara rädd för att göra fel. Misstaget är den bästa läraren!

About Jaime Gomez

Jaime Gomez
Senior QA Engineer Axis Communications
En av grundarna av SAST-Öresund

Ämne jag gillar arbeta med: testledning, testautomatisering, testprocess. Jag började arbeta med QA frågor år 2001. Jag har arbetat som utvecklare också på olika företag och därför har ett utvecklingsperspektiv hos mig.

Alla kommentarer på denna webplatsen speglar bara författares åsikter och inte arbetsgivare.