Gå till innehåll

Det finns massor av information därute, problemet är att hitta rätt. Jag har listat de sajter jag själv anser som mest värdefulla för en testare att läsa.

www.kaner.com : Cem Kaner kan mycket om test och är villig att dela med sig av det mesta
www.model-based-testing.org : Harry Robinson - guru inom modellbaserad testning
www.sast.se : Sveriges största förening för testare
www.satisfice.com : James Bach om utforskande testning och mycket annat matnyttigt
www.stickyminds.com : Artiklar i massor, mycket är läsvärt

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.

Testgurun James Bach har skrivit en artikel med titeln "Testers light the way". Jag fastnade för den då jag tycker den belyser testarnas relation till övriga projektet på ett bra sätt. Som testare vet vi hela tiden vilken status projektet befinner sig i eftersom vi hela tiden bedriver någon sorts undersökande verksamhet. Det kan handla om att vi skriver en översiktlig strategi där vi försöker få allt att hänga ihop, eller tar fram detaljerade testfall för någon specifik funktion eller att vi utför testfall. Vårt arbete går helt enkelt ut på att undersöka aktuell status av underlag eller färdig kod. Varje duktig testare kan alltså vid varje givet tillfälle berätta om nuläget vilket är högst vital information för projektledaren och andra. En väl skriven kortfattad veckorpport från testsidan ökar övriga deltagares respekt för oss.

Jag motsätter mig starkt den attityd en del testare verkar ha att allt ska komma serverat på silverbricka. Det är en fin tanke att kompletta, korrekta, otvetydiga krav levereras i tid till test som sen enbart med dessa som underlag kan skriva sina testfall utan en dialog med kravställare och utvecklare. Jag har varit med om ett fåtal projekt där kravspecarna är riktigt bra men för det mesta är det halvbra om det nu finns alls. Du kanske har en annan situation på din arbetsplats men så här ser min verklighet ut. Att i detta läge ha som strategi att bygga alla testfall enbart utifrån kravspecen verkar vansinne.

Kolla in www.satisfice.com för en mängd intressanta artiklar.

//Tobbe

Allt oftare nuförtiden ser jag i jobbannonserna att man söker testare som är certifierade. Den vanligast förekommande certifieringen är ISEB foundation - nu på väg att ersättas av ISTQB foundation. Jag undrar vad man som arbetsgivare förväntar sig av en person som är certifierad på denna nivå.

I korthet går det till så här. Man anmäler sig till en tredagarskurs - ofta på engelska men den finns även på svenska - och får i slutet av kursen skriva en en timme lång tenta med flervalsfrågor på engelska. Om man tycker att det är för enkelt att gå kursen kan man välja att bara skriva tentan. Kursen och tentan innehåller en grundläggande utbilding inom test. Du får veta vilka testnivåer som finns, lite kort om testdesigntekniker, granskningar etc.

Jodå, bra att kunna men vad säger det egentligen om den som klarat provet? Att man är intresserad av test eller att någon chef bestämt att alla anställda ska gå kursen, eller att du fått gå kursen som belöning för väl utfört arbete eller substitut för löneförhöjning. Hallå - det är en tre dagar lång kurs med en enkel tentamen! Den största svårigheten är att förstå de engelska frågorna. Jag hävdar bestämt att det inte säger någonting alls om hur bra en person är. Du kan vara en usel testare och ändå klara certifieringen och du kan vara ett proffs och inte bry dig om att gå en så enkel kurs!

Viktigare isåfall borde vara utbildning på högskola, exempelvis systemvetare eller civilingenjör. Tre till fem år och inte tre futtiga dagar. Eller tio års erfarenhet av testning på ett bra sätt...vad det nu är. 

Du blir inte en bra testare på tre dagar! Det är ungefär som att banta 20 kilo på en vecka - en bluff (om man inte dyker med vithajar). Gå gärna en grundkurs i test - det är alltid bra att ha men dra inte för stora slutsater av det. Det är en kurs som alla andra...

 /Tobbe    

Det är väl lika bra att börja den här bloggen med det jag tycker är viktigast för att få bra resultat av testerna , nämligen tetdesignen. De flesta kurser och certifieringar fokuserar på standarder, dokument och vokubulär men ytterst få går igenom testdesign på ett bra sätt. Jag säger inte att detta är helt onyttigt att kunna men det är liten mening  med att ha bra dokumentation och snygga planer om vi har dåliga testfall. Oftast då test kommer på tal så vet "ALLA" hur man ska göra. Lite max- och min- och udda värden, så är det bra med det. Sanningen är att den som tycker att test är enkelt troligtvis inte har förstått alls. Test är oerhört komplicerat och innehåller en mängd olika aspekter.

Jag använder mig själv av en process i fyra steg för att ta fram bra testfall. Det första steget är att analysera alla den information som finns om produkten jag ska testa och sen skapa en eller flera modeller som beskriver funktionaliteten. Modellen är central för mig då den både hjälper miog att förstå och ställa frågor och är samtidigt en kvalitetssäkring av underlaget. Om vi tittar på en utvecklingsmodell som Unified Process - ofta känd som RUP - så är visuell modellering en av grndstenarna. Tyvärr så hoppas detta steg ofta över av kravskrivare, analytiker och utvecklare och jobbet att ta fram modellerna hamnar hos test. Hur många testare är duktiga på modellering? Ytterst få skulle jag vilja påstå utifrån vad jag sett.

Nåväl, efter att modellen är framme så täcker jag in den med testfall. Jag undrar hur man kan beskriva testtäckningen av ett system om man saknar en modell. Hur räknar man då, som test av alla krav? Men dom är u för det mesta rätt dåliga enligt oss testare. hmm...

Det tredje steget handlar om att komplettera mina testfall med testdata. Här kommer max, min, udda värden in. men det är ju bara en liten del av testerna!

Det fjärde och sista steget är att knyta ihop alla tester för att få en helhet. det kan handla om tids- eller datacykler, parallella testfall eller visa intressanta kombinationer. 

Först när du som testare behärskar testdesign kan du kalla dig proffstestare!

En bra start är att läsa min bok om testdesign som kommer ut nästa vecka. 

/Tobbe