Gå till innehåll

Fick idag mejl från våra irländska vänner som arrangerar EuroSTAR. Då jag ansökt om att tala men inte fått något besked läste jag med viss skepsis igenom årets program. När jag efter en stund dök på W7 blev jag glad då jag hittade (nästan) mitt eget namn Tobjorn - nåja man kan ju inte begära för mycket av dom stackars utlänningarna, svenska tecken är problem både inom och utanför Sveriges gränser, keff skulle man kunna säga på nysvenska.

Årets program är nedbantat sen förra året, endast fyra parallella sessioner ger 45 talare förutom de 7 heldags och 7 halvdagstutorials det bjuds på. För er som inte varit med förut är tutorials kurser som är tänkta att vara mer kända riktigt duktiga talare från hela världen som motiverar att deltagarna dyker upp en och halv dag i förväg. Utan att peka på någon särskild är jag lite besviken på att vi får se samma gamla kända ansikten med i stort sett samma teman som tidigare år. Kul att Scott Barber och Randall Rice tar sig hit från andra sidan Atlanten för att ge oss lite förnyelse. Jag saknar dock det utforskande gänget med James Bach, Cem Kaner, James Whittaker i spetsen. Som tur är plockar ENEA James Bach till Sverige med jämna mellanrum så att de som vill kan få chansen att uppleva honom. Förhoppningsvis får vi se även James Whittaker på hemmaplan under året. Jag marknadsför honom till alla konferensarrangörer som vill lyssna.

Så på måndagen skulle jag nog själv välja Scott Barbers : Explore Performance Testing in Context eller Stuart Rieds : Effective Test Case Design. Har du inte sett Lloyd Roden innan så är han en duktig kille som är bra på att underhålla publiken.

Tisdagens förmiddag innehåller en hel drös med intressanta föredrag, vet inte vem jag skulle välja riktigt. Julie Gardiner är hyperaktiv och underhållande på scen, Graham Freeburns föredrag låter visserligen intressant men hans föredrag förra året hade det missvisande namnet Agile Inspection - det känns lite som att det är samma föredrag igen men med ny titel och lite längre tid. John Fodeh hade exakt samma föredrag förra året så det är lite trist att det kommer i år igen. Nej jag väljer nog Julian Hartys bidrag då det känns som ett kul sätt att utgå från De sex tänkarhattarna. Hade förmånen att arbeta med Julian i förra årets EuroSTAR-kommitté och vet att han har koll på sina saker.

Tisdag eftermiddag bjuder på många talare som var med även året innan - lite tråkigt tycker jag. T3 och T7 är ett snabbt val utan att ha någon mer information om vad det handlar om än rubrikerna.

Onsdagen: W7 kommer jag definitivt at vara med på, sen vet jag inte riktigt - W18, W21 blir det nog - hade gärna sett en dubbel session med James Lyndsay. Ser att det i år som vissa andra år finns talare som har fler än ett föredrag vilket jag tycker är lite synd då det finns säkert ytterligare 500 ansökningar att välja mellan. Finns säkert de som kommer att reagera med sura miner på detta.

Torsdag: TH4, TH7, TH12, TH15 och sen är det party. Upptäcker att jag missat alla People-sessioner så jag kanske ändrar mig.

I det stora hela finns det en del att lyssna på, speciellt för den som inte var med förra året. Jag spår dock att många av de som var med i Köpenhamn kommer att vänta ett år till innan de återkommer till den här konferensen.

/Tobbe

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   Â