Testfallens vara eller icke vara
torsdag 10 september, 2009 Att skriva testfall är en självklar del av testprocessen i de flesta organisationer. Men har du någon gång frågat dig: Varför använder vi testfall? Till vad används och tillför de?
Vi börjar med den första frågan; varför använder vi testfall?
Test var länge en syssla för de nya och oerfarna. När en testare fick frågan; -Vad är det egentligen du gör på dagarna? Så på grund av deras begränsade erfarenhet så hade de svårt att förklara på ett enkelt sätt hur test egentligen fungerar, detta gillade inte cheferna.
-Vi måste få ordning och reda på testerna! Det verkar ju vara rena rama lekstugan, kanske någon sa.
Det var då någon kom med idén att varför inte be testarna skriva ner vad de gör, då kan vi både granska och mäta deras arbete på samma gång. Perfekt! Låt oss kalla detta för testfall!
La du märke till det alldeles för stora e:t i första meningen? Va? Gjorde du? Hur kunde du göra det utan att du hade ett testfall? Helt makalöst!
Anledningen är att din modell av skriven text på svenska i en ordbehandlare säger dig att något inte stämde.
Har någon bett dig korrekturläsa en text någon gång? Vilka testfall brukar du använda då?
Känns frågan dum eller konstig? Varför?
Test handlar om att ställa frågor, om och om igen till dess att du känner att har svaret på dina frågor, eller någon annans frågor.
Kan jag registrera mig? Kan jag logga in? Skall den knappen vara blå? Skall det gå så här långsamt? Vad händer om vi släpper på 10 000 användare samtidigt?
För någon som inte har en modell av det system som är under test är det också svårt att ställa frågor.
Skulle du kunna göra ett enkelt test av startmotorn på din bil? Skulle du kunna göra ett enkelt test av startmotorn på ett jetplan?
Om du inte är pilot så är svaret antagligen ja på den första frågan och nej på den andra.
Varför? Jo därför att du saknar en modell i ditt huvud av ett flygplan men du har en modell av en bil.
IT-organisationer försöker idag ofta att skriva ner modellen av ett system i form av testfall så att vem som helst skall kunna testa. Men hittar man egentligen fler fel genom att använda testfall? Är det inte egentligen så att när man använder testfallet så ser man något helt annat som verkar konstigt, och genom att undersöka det så hittar man en bugg? Hur skall då någon som inte har en modell av systemet, och därför inte märker att något var konstigt, kunna hitta dessa buggar?
Om du räknar på den lilla tid det kostar att få någon att skapa sig en korrekt modell av systemet, mot den tid det kostar att skapa och underhålla testfall som inte används (vem läser testfallen efter första gången) så blir det ganska självklart.
Se till att testarna kan grunderna i hur man kör en testanalys av ett system och satsa sedan på att se till att alla har en bra modell över hur systemet under test skall/borde fungera.
Ni kommer att se en stor skillnad, dels hur många buggar som hittas och dels på systemets kvalitet i det långa loppet. Ni har ju nu också skaffat er ett stort antal människor som kommer på nya bra förbättringar på ert system. Bra va?
-Hur ska vi kunna mäta deras arbete då?
Ja, den frågan tar jag en annan gång.
Reader Comments (8)
Det kräver att man som testare har god domänkunskap. En möjlig invändning är att det inte är självklart att medlemmar i ett utvecklingsprojekt också är experter på det IT-system de ska utveckla. Som konsult är det ju sällan man hinner utveckla djupare domänkunskap då man ofta är inne i ett projekt för att man besitter tekniska kunskaper.
Håller med dig Magnus om att man borde ifrågasätta varför man lägger stora resurser på att skriva och underhålla en stor uppsättning testfall. Det viktiga är ju egentligen att man lyckas hitta felen i systemet och för att göra detta tror jag att det är mycket värdefullt om de som testar systemet verkligen har kunskap om hur slutanvändarna kommer använda systemet och åtminstone kan gissa sig till deras önskemål. Om detta är en svår uppgift för test-teamet så kanske man borde plocka in några med domänkunskap som kan hjälpa till med acceptanstestningen.
Jag håller med dig om att det till 95% är onödigt arbete att ta fram testfall. De återstående 5% är scenarier där man faktiskt behöver göra det. Det kan t.ex. handla om komplicerade scenarier vilka kräver utredning och eftertanke, regulatorriska skäl eller att det rör kritiska system.
Michel - Att ta in personer med domänkunskap för acceptanctest är bra, problemet man får är att man riskerar att hitta missförstånd och buggar försent. Om testarna saknar domänkunskap och man inte hinner lösa det så har jag löst det med att sätta in "business test" så tidigt som det bara går för att få feedback.
Tor - Jag förstår vad du menar, men att inte skriva testfall behöver inte betyda (och ska inte betyda) att man inte gör testanalys eller dokumenterar hur man testar.
Så här vill jag lägga upp mina tester:
Varje testsession (a 90 min) delas upp i 3 delar och görs i par (minst). Gruppen skall skriva testnotes som i kort består av:
1. Förberedelse - Hur testar vi denna delen av systemet? Vad är kraven? Hur har man byggt det? Vad kan egentligen gå fel här? De anteckningar man får fram sparar man.
2. Test - Under testet så skriver man vad man gör, inte för detaljerat, men så att man har koll på vägen man gick, data man använde osv.
3. Sammanfattning- Skriv en kort sammanfattning om testsessionen, några problem? Något som man inte kunde / hann testa? Hur många buggar? Osv.
Denna testnote lämnas sedan till testledaren som snabbt kan läsa och se om det är något som man saknade, kanske finns en del som han/hon vill skall testas lite djupare osv.
När alla börjar bli bekväma i detta arbetssätt tycker jag att detta arbetssätt ger mig en bra koll på vad som är testat, hur läget är och hur duktiga mina testare är.
Att säga att man inte behöver testfall är att fomulera sig väl svepande i mitt tycke. De skriptade testfallen (ej automatiserade) fyller sitt syfte väl. De är förvisso tidsödande att ta fram och de gör största nytta första gången de körs och man kan därför alltid argumentera för att man istället skall lägga den tiden på att testa. Icke desto mindre så har de uppenbara fördelar; de kan uföras även av en testare som är oerfaren inom yrket och/ eller domänen, de kan användas för regressionstester och inte minst så vet man när man hittar ett fel exakt vilka steg man gått
igenom när felet uppstod. Att bara rapportera fel utan att kunna återge vad man gjorde för att det skulle uppstå är oftast utan värde.
För att köra utforskande tester krävs det förutom testerfarenhet och helst domänkunskap dessutom disciplin och fokus, annars blir det bara ett meningslöst klickande där men efteråt inte kan återge någonting.
Därtill behöver vi innan, under och efter testet skriva noteringar av två slag.
1 För planeringen och styrningen; a/ beskriva vad vi testat, dvs vilket subsystem, vilken bild, vilken process eller hur vi
nu väljer att dela upp våra tester; b/ buggar skall noteras utförligt; c/ övriga observationer vilket kan vara förslag på nya tester, intryck av applikationen etc
2. För minnet och för att kunna återskapa testet behöver vi dessutom dokumentera; a/ vilka steg vi gick igenom; b/ viket data vi avände
Vad det gäller buggar så skall de dessutom efter avslutat test överföras till ett riktigt buggrapporteringssystem för planering och uppföljning. Att bara ha dem liggande löst i ett dokument håller inte i ett något sånär stort projekt.
Men som sagt. Såväl utforskande tester som skriptade tester har sin plats i testvärlden
Att säga att man hellre kan lägga tid på att faktiskt utföra testen istället för att skriva testfall rimmar illa i mitt tycke. Bör inte testfallen vara skrivna innan testning påbörjas? Dvs. skrivandet av testfallen bör inte, kan inte, "stjäla" tid från test. Likaså hoppas jag att ingen använder testfallen för att "modellera" ett system! Testfallen skrivs utifrån krav och användningsfall men det är fortfarande kraven och användningsfallen som styr "modelleringen" av systemet.
Nisse: Jag håller med om det du skriver och förstår inte varför du utgår från att man inte gör de saker som du skriver?
Självklart planerar man i förväg hur man skall testa, självklart skriver man ner under tiden hur man testade.
Jag försökte inte i detta inlägg beskriva exakt hur man utför utforskande testning, jag ville belysa ett problem som jag ser i att man tror att så länge vi skapar testfall så är allt bra.
Robert N: Självklart testar man bl.a. utifrån krav, det har jag inte sagt något om i denna text. Förklara gärna mer VARFÖR du tycker att ett test blir bättre för att man skriver ned det innan, det är det jag vänder mig emot i just denna text.
Jag är inne på samma tankegångar som dig Magnus och vill poängtera att det inte lämpar sig för testare som man plockar in från gatan. MEN hur ofta gör man egentligen detta? Domänkunskap (kan byggas upp med t ex parvis testning) och att Testrollen är en profession med en stolt yrkesgrupp som gillar sitt jobb är utgångspunkt när jag som testledare rekryterar folk. Skulle också vilja komplettera dina 1.Förberedelser och 2.Test med följande som kanske lugnar(?) en del som förordar skriptade testfall:
1a.Förberedelser för Testanalytiker: gå igenom vad ev tidigare tester råkat ut för, komplettera med områden där tidigare tester kanske inte hunnit med (dålig kravtäckning), tryck på områden där du vet att utvecklarna gjort förändringar eller där det är komplexa affärsregler, Föreslå specifik testdata där det är relevant, bygg upp checklista som är relevant för t ex GUI och andra systemuppträdanden
1b: Förberedelser för Testdesigner/Testare: Scripta in/Återställ relevant testdata
2. Test - använd checklistan eller ha den iallafall i bakhuvudet när du testar. När man hittar buggar bör man naturligtvis föra in det i defekthanteringsverktyget med angivande av buildnr, hur man kom fram till buggen för att utvecklaren ska kunna återskapa (spela gärna in detta, finns t ex bra möjligheter i VSTS), severity, etc, d v s allt som man normalt gör när man hittar en defekt oavvsett om man kör skriptad test eller inte.