Kategori: Uncategorized

Här recenserar jag ett antal böcker som jag läst och funnit användbara för min karriär inom test. Tyvärr så finns det väldigt få riktigt bra böcker inom test men en hel del böcker inom andra områden som du
som testare kan ha nytta av. Jag har delat upp recensionerna på ämnesområden. Inspirerad av bland annat James Bach har jag valt att läsa en hel del utanför testområdet.
För att bli en riktigt bra testare tycker jag det är viktigt att bredda sig. Dessutom är det användbart oavsett
vilken karriär du väljer att ha en viss bredd i din egen utbildning.

Test

Lessons Learned in Software Testing: Kaner, Bach, Pettichord (betyg 5) ISBN 0-471-08112-4

Det som är mest spännande med boken är att det känns som att ha ett samtal med världens bästa testare där de tar upp olika problem som de dykt på under sin verksamma tid. Nej det är ingen lärobok för nybörjare. För den som verkligen vill lära sig om test är den ovärderlig. Ju mer jag läser boken - desto bättre blir den! 293 tips på 263 sidor – det säger sig själv att de flesta tipsen är rätt korta. Det är en blandning av kortare och längre lektioner där vissa kan tillämpas i verkligheten och en del är rätt banala tips. Exempelvis Lektion 67: Rapportera felen direkt. Vänta inte tills imorgon, då glömmer du bort detaljerna. Dessutom så tror din testledare att det inte finns några fel om du inte rapporterar dem. Simpelt men ändå viktigt att tänka på. Striden om exploratory testing (stödd av författarna) vs. scripted testing tas upp. Boken bygger helt på författarnas egna upplevelser och alla lektioner stämmer inte alltid – vissa av dem talar till och med emot varandra - men det är också syftet att visa att sanningen beror på sammanhanget! Jag använder den som allmän inspirationskälla då jag skriver kursmaterial.

Testdesign för programvara: Ryber (betyg 5) ISBN 91-976062-1-9

Äntligen en testbok på svenska som går lite mer på djupet. Boken är genomarbetad och lättläst och en fröjd att läsa både i de avsnitt som är generella och de som är mer specifika. Som titeln utlovar har boken ett tydligt fokus på testdesignen men den ger även dig som läsare en heltäckande bild av test av programvara. Boken känns fräsch och aktuell och det finns till och med ett kapitel om utforskande testning (exploratory testing) skrivet av den amerikanska testgurun James Bach. Det finns gott om tips och exempel samt även en del övningar vilket gör att boken bör lämpa sig ypperligt för undervisning i test, något som saknas i branschen. Köp den och använd den som ett stöd i det dagliga arbetet. Jag har redan tillämpat en del av det jag lärt mig ur boken. (OBS: Denna recension skriven av Gun Ström, testledare på AMS IT-enhet.)

TPI (betyg 5) ISBN 0-201-59624-5

Ett måste i varje seriös testspecialists bokhylla. En praktisk steg för steg beskrivning av hur du förbättrar testprocessen. Själv har jag den som inspirationskälla till nästa aktivitet på företaget och samtidigt min egen utbildningsplan. Observera att boken innehåller en beskrivning av olika testområden och vad som måste uppfyllas inom varje område för att nå en viss nivå. Däremot så är det ingen lärobok inom test, då hänvisas istället till boken TMAP som stödjer TPI fullt ut. Ett tips är att köpa båda böckerna – ibland finns det paketpris på Amazon.

Software Testing in the Real World: Ed Kit (betyg 4) ISBN 0-201-87756-2

En liten nätt bok på 240 sidor som handlar om förbättring av testprocessen. Den är lättläst och översiktlig och utgår från en variant av V-modellen som kallas ”The Dotted-U Model”. Modellen går ut på att visa hur varje del i kravställning och utveckling har en motsvarande aktivitet i test. Boken passar bra som introduktion för dig som vill lära grunderna inom test men är även ett bra uppslagsverk för den mer erfarne testaren. Rekommenderas till ditt personliga referensbibliotek.

Testing Computer Software: Cem Kaner et al. (betyg 4) ISBN 0-471-35846-0

Denna bok marknadsförs med devisen ” Mest sålda testbok genom tiderna”. Det är uppenbart att författarna har en gedigen erfarenhet av test, de har fyllt boken med en massa smått och gott. På dryga 500 sidor beskrivs ett brett spektrum av test från detaljer i testdesign till felhantering och testledning. Det är naturligtvis svårt att täcka in allt i en enda bok och det kan ibland kännas lite ostrukturerat då de försöker få in så mycket som möjligt. Men köp den gärna och ha som uppslagsbok, läs ett nytt avsnitt för att få idéer.

Systemutveckling

Effektstyrning av IT: Ottersten, Balic
En liten bok med mycket information. I samma anda som boken Användbarhet i praktiken tar författarna upp problemet att den mesta systemutvecklingen glömmer bort det verkliga syftet nämligen att lösa någon sorts problem. Utgå från de effekter du vill uppnå, funderar på vem (målgrupp) som kan se till att effekterna uppnås och hur detta ska ske. Först därefter funderar vi mer konkret på lösningen som tas fram genom storyboarding, prototyper och användartester. Ett vanligt systemutvecklingsprojekt fokuserar ofta på enskilda funktioner och ger ogenomtänkta lösningar som är mer eller mindre omöjliga att använda i praktiken. Projektledare fokuserar på tid och pengar men sällan på slutanvändarens nytta. Vi behöver komplettera med en efektledare och en användbarhetsexpert som driver den färdiga produkten mot det verkliga målet! Köp och läs omedelbert.   

Agile Modeling: Scott Ambler
Agil utveckling är här för att stanna. Inom test finns det ett flertal kända profiler som hätskt angriper nytänkande i form av utforskande testing. Om de hade orkat lyfta näsan från sina överdokumenterade
teststrategier och detaljerade testfallsbeskrivningar hade de kanske insett att det är tests svar på agila metoder. Jag som testare får leva med att olika projekt tar fram olika bakgrundsmaterial, för att bli riktigt duktig måste jag därför veta vad "de andra" pratar om. Agil modellering handlar om att dokumentera när det behövs, inte annars. vissa modeller är temporära andra centrala delar beskrivs i detalj och sparas till eftervärlden. En bra introduktion till dig som vill lära dig mer om agila metoder och dess arbetssätt och dokumentation.

Övrigt inom problemlösning, ledarskap, psykologi och filosofi

The Secrets of Consulting: Weinberg

Mycket underhållande bok om hur det är att vara konsult. Handlar om hur du visar upp för kunden att du kan något och att de har stor nytta av det du gör. Riktar sig främst till den som är egen snarare än en dussinkonsult på ett större företag. Lättläst men ändå innehållsrik. rekommenderas varmt.Presentationsteknik: Lundén, RosellBoken handlar både om hur du bygger upp ett material som hänger ihop och hur du sen presenterar det i olika situationer. Föredömligt kort på drygt 100 sidor men kärnfullt berättat ger den dig säkert många aha-upplevelser. Jag önskar att jag hade en låda av denna bok hemma så att jag varje gång jag lyssnat på en riktigt dålig presentation kunde ge ett exemplar till talaren med hopp om att han eller hon läste, förstod och ändrade sig. 100 sidor powerpoint med mycket text och liten font presenterat av en ointresserad talare som mumlar fram budskapet, om det nu finns något, borde förbjudas i lag!

Lateral Thinking: de Bono

För en tekniktok som jag själv som är expert på logiskt tänkande är det befriande att få ett alternativt kompletterande tankesätt presenterat. Lateralt tänkande handlar om att släppa på sina egna begränsningar och använda sin inneboende kreativitet för att hitta helt nya lösningar
och möjligheter. En rolig och lättläst bok med tips om hur du hittar enkla lösningar på till sysnes
komplicerade problem.

Thinking and Deciding: Baron

I en enda bok finns ett koncentrat av fakta om hur vi tänker och på vilka grunder vi tar beslut. Jag ryser ibland till när jag inser hur lätt det är att luras i sina slutsatser om man inte tänker efter vilka fakta som finns och hur de ska behandlas. Bayes teorem kan appliceras på juridik, medicin och flertalet andra områden. En liten tankeväckare: Av de taxibilar som finns i staden är 85% Gröna och 15% blå. En natt sker det en krock med en taxibil som smiter från platsen. Ett vittne identifiera bilen som blå. Domstolen bedömer sannolikheten att vittnet har identifierat rätt färg som 80%. Utifrån detta, hur stor är sannolikheten att det var en blå bil som krockade? Svaret tas fram genom att beakta sanna positiva och falska positiva möjligheter enligt en enkel formel: sannolikheten att det är en sann identifikation är 15*80/ (15*80 + 85*20) = 41%  Där 85*20 är sannolikheten att en grön bil felaktigt identifierats som en blå och 15*80 sannolikheten att en blå bil korrekt identifierats som en blå. Otroligt intressant tycker jag hur förutsättningarna påverkar sannolikheten.

Thinkertoys: Michalko

Beskriver ett antal tekniker för problemlösning och beslutsfattande. Några av dem känner du redan till, som exempelvis brainstorming, andra mer originella varianter är Think Bubbles och Murder Board. En idé kan vara att då ni kört fast i ett problem
leta upp en lämplig teknik och därigenom hitta ett alternativt angreppssätt.

Acceptanskriterier och acceptanstestkriterier - vi reder ut begreppen
Fick en fråga på mejlen om vad som skiljer de båda begreppen åt och känner igen frågeställningen från egna projekt. Det verkar finnas en stor osäkerhet om vem som ansvarar för att godkänna leverans av en beställd produkt. Något jag tycker är lite märkligt. Jag har en egen uppfattning om vad som gäller, men kan inte på rak arm berätta om något ställe man kan hitta mer information på. det finns säkert men jag har inte tid att leta just nu. Kanske någon av de som läser bloggen har tips?

Min egen uppfattning är att vi som testare har som uppgift att genom vårt arbete ta fram så mycket information som möjligt om det vi testar. Denna information presenterar vi sedan till projekt eller liknande eventuellt med vår åsikt om hur det ska tolkas. var försiktig med rekommendationer då du kan få skulden om något inte fungerar som det ska. Testerna bygger ju på det VI vet och vi vet sällan allt. Ofta får jag som testledare frågan - rekommenderar du produktionssätning. Jag försöker då beskriva att det enda jag vet är hur bra mina egna tester har gått och vilka öppna fel som finns kvar. beslut om produktionssättning är däremot ett AFFÄRSBESLUT. Det behöver inte alls bygga på hur testerna har gått utan kan ha helt andra kriterier. Nya modeller/versioner av exempelvis telefoner och websajter produktionssätts ofta med ganska mycket kvarvarande fel och bristade tester då det viktigaste inte är att ha noll fel utan att vara först ute på marknaden.

Acceptanstestkriterierna är det vi i testgruppen sätter upp för oss själva för att säga att - "Nu är vi färdiga med testerna till den grad att vi kan ge er en bra bild av situationen" Det är altså vårt interna arbetssätt som de gäller. På samma sätt kan vi ha kriterier för de andra nivåerna som system och integrationstest, dessa kriterier ansvarar testledaren för.

Acceptanskriterierna är det som en beställare sätter upp för att godkänna att de fått levererat vad som beställts. Det är ofta en del av eller en bilaga ett skrivet kontrakt. Dessa ska tas fram av den som beställer och som ska godkänna leveransen. Sen kan det mycket väl vara så att godkännandet i praktiken innebär att vi utför en acceptanstest och resultatet från denna ligger till grund för acceptans av leveransen.

Men det är viktigt att skilja mellan testarnas roll och beställaren/mottagarens roll. Vi måste lära beställaren att ta sitt ansvar! Har skrivit mer om detta i min bok "testdesign för programvara". (kap 5 angreppssätt och kap 24 när är vi klara med testerna.)

//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

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