Denna artikel skickade jag in till Computer Sweden för några veckor sedan men har inte hört något mer sen dess. Vissa delar kommer ni att känna igen från övriga inlägg men det kan ändå vara intressant att se artikeln som helhet.
Testa inte mer - testa rätt!
Ofta kräver vi från testsidan att få vara med tidigt i projektet, men hur använder vi då vår tid när vi får vara med? Påfallande ofta ses testgruppen som ett gäng gnällspikar som hackar på det material resten av deltagarna producerar. Med rätta skulle jag vilja påstå! Vårt angreppssätt är ofta inte speciellt produktivt och attityden att vi ska få alla krav serverade på silverbricka leder ofta bara en kort bit på vägen mot bra kvalitet. Om vi som testare vill ha respekt måste vårt främsta mål vara att tillföra nytta. Jag gillar W-modellen som säger att oavsett vad nån annan tar fram så kan vi testa det. Jag vill därför presentera ett sätt som jag med mycket lyckat resultat använt i de projekt jag deltagit i de senaste åren.
Kunskap och komunikation är en nödvändig start
Det finns en alltför spridd tro att vem som helst kan jobba med test. Sanningen är att vem som helst kan jobba med test men för att göra ett riktig bra jobb krävs det en hel del kunskap. Nummer ett är alltså utbildning. Vi har kört en variant där vi sätter samtliga projektdeltagare på en tvådagars kurs i testdesign där vi inte bara lär ut vilka tekniker vi använder utan även vilka problem vi som testare råkar ut för. På det sättet skapar vi ett samförstånd bland deltagarna. En riktigt bra kursomgång innebär att vi knappt hinner gå igenom allt material därför att dialogen mellan kravställare, utvecklare och testare blir så intressant att den tar mer tid. Nu har vi kommit inte bara ett utan två steg framåt: dels har alla en ökad kunskap om test, dels har vi inom projektet börjat diskutera med varandra vilket är en förutsättning för det arbetssätt jag kommer att beskriva.
Fyra steg till effektiv testdesign
För att vår test ska bli riktigt bra krävs att vi är duktiga på testdesign. Det arbetssätt jag har kvalitetssäkring som en viktig del. Det övergripande kvalitetsansvaret ligger dock på projektledaren så länge denna inte väljer att delegera det till någon annan. De fyra stegen i testdesignprocessen är:
1. analysera underlaget och skapa modeller
2. täck modellerna med testfall
3. jobba med testdata för att få en djupare test
4. testa det övergripande och det mer avancerade
Jag väljer att fokusera på det första steget som är att analysera underlaget och skapa modeller. Det gäller för oss testare att leta reda på all information vi kan hitta sen läsa, analysera, modellera och inte minst ställa frågor. Vårt angreppssätt måste vara att aktivt ska svar på det vi inte förstår och på ett bra sätt ifrågasätta både underlagen och svaren på frågorna. Ska jag exempelvis testa ett flöde så börjar jag att fråga efter flödesgrafen. För användningsfall finns det ofta en sådan i form av ett aktivitetdiagram. Om det inte finns en flödesgraf gör jag en egen. Men är det mitt jobb? Ja det tycker jag faktiskt, ska jag kunna bygga bra testfall måste dessa utgå från ett bra underlag i form av någon sorts modell. Mina modeller är dessutom samtidigt en alldeles utmärkt kvalitetssäkring av underlaget. Jag skulle till och med vilja påstå att modelleringsarbetet är den insats som ger mest valuta för pengarna. Jag kan hålla med om att det till viss del är kravställarnas, arkitekternas och analytikernas roll att skapa modeller. Men så länge de inte gör det så faller det på min lott som testare om jag vill lyckas. Vill jag bestämma hur projektet ska drivas får jag istället axla rollen som projektledare. I samtliga fall i verkligheten där jag skapat flödesgrafer har jag hittat tankefel och saknade krav. Alternativet (eller rättare sagt komplementet) till att skapa modellen är granskning som kan fungera okej om den görs korrekt men så är sällan fallet.
Steg två är att utifrån min modell skapa testfall som täcker in det jag vill verifiera. För aktivtetsdiagrammet börjar jag med att täcka in huvudflödet och fortsätter med alternativflödena, beroende på hur avancerat det är kan jag även kombinera olika flöden i samma testfall för att se att detta fungerar. Det är en gåta för mig hur man som testare kan få bra testtäckning utan att skapa en modell först. Det är vanligt att mäta testtäckning genom att spåra testfallen till kraven men eftersom vi testare alltid säger att kraven är otillräckliga borde det betyda att även testerna blir otillräckliga - eller hur?
Steg tre är att analysera de variabler som finns och ta fram lämpligt testdata. På så sätt får vi en djupare och mer detaljerad test. Även detta ingår i testtäckningen.
Sista steget är att knyta ihop testfall som hör ihop samt den mer avancerade testningen som beror på exempelvis samtidiga händelser eller speciella förutsättningar. Här kommer den viktiga valideringen av att systemet fyller sitt syfte in.
En solskenshistoria
För att exemplifiera hur test i ett lyckat projekt kan gå till har jag denna solskenshistoria. Jag kom in i projekt X som testdesigner ungefär samtdigt som kraven höll på att bli klara. Min uppgift var att testa ett jättelikt regelverk på drygt hundra regler som tillsammans skulle täcka in kreditvärderingen för alla de kunder som har eller vill ha ett lån hos banken. Trots försäkran om att kraven var korrekta skapade jag först en beslutstabell och sedan ett beslutsträd. Dessa två modeller hjälper mig både att analysera och grafiskt kontrollera om regelverket var korrekt uppbyggt samtidigt som det är ett nödvändigt steg för att jag ska kunna skriva mina testfall. Resultatet blev att vi bland annat hittade fem saknade regler. Nästa steg var att granska den programspecifikation som tagits fram. Här gjorde jag en punktgranskning i detalj av variabler och siffror i varje regel. Inte jättespännande men ganska tidseffektivt, jag hittade ytterligare några fel både vad gäller specifika värden och variabelnamn. Samtliga testfall jag tagit fram inklusive förväntat resultat levererades till utvecklarna som information om vad test tyckte var viktigt att testa. Vi hittade under systemtestets utförande endast ett enda fel som berodde på en felaktigt översatt variabel, resten var fel i testdata som snabbt gick att identifiera och åtgärda. Vi hittade ett par fel i acceptanstest och produktion som berodde på miljövariabler, dessa kunde ha hittats tidigt med en enkel granskning av rätt personer. Projektet levererade i tid trots sen leverans till systemtest tack vare tidigt engagemang av test på rätt sätt! Självklart fungerar detta inte lika bra utan utvecklarnas eget engagemang i de tidiga testerna, men ändå, ett ganska bra resultat, eller hur.
Slutsats
Test kan inte ta över allt ansvar för kvaliteten men vi kan komma en bra bit på vägen genom effektiv testdesign och rätt inställning. Vi testare måste ha rätt kunskaper och inställningen att tillföra nytta. Att skapa modeller är ett nödvändigt steg för bra testdesign och samtidigt ett utmärkt sätt att kvalitetssäkra underlagen.