Gå till innehåll

Min upplevelse

Fick idag räkningen för ett trädgårdsarbete utfört av en trädgårdsfirma i Stockholm. Jag var lite sur redan från början för att det var ett högt pris på offerten och det visade sig ta väldigt kort tid att genomföra när det var fastpris som gällde. Ännu surare blev jag då på fakturan fanns priset på den ursprungliga offerten plus moms. Nu är det så att praxis är att alla prisuppgifter till en privatperson ska vara inklusive moms. Bestämde mig muttrande att aldrig mer anlita en svensk hantverkare som gör ett halvbra jobb till ett heltokigt pris. Konstaterar att det är så stor efterfrågan på hantverkstjänster i Stockholmsområdet att man inte behöver bry sig om en kund blir nöjd eller ej. Mitt förtroende för hantverkaren och för den butik som rekommenderade honom är mycket lågt och jag vill aldrig göra samma sak igen. Nästa gång försöker jag nog med en hårt arbetande men billigare resurs från Baltikum eller Polen.  Det absurda i situationen slog mig då grannen några hus bort som själv är byggare anlitade ett gäng från Estland för att renovera sitt eget hus. Inte ens inom samma bransch stöder man alltså varandra.

Kopplingen till vår egen bransch

Det är inte alltid den vi anställer eller anlitar som konsult vet vad de gör. Ofta har jag råkat ut för inhyrda konsulter som gett sig ut för att vara något annat än de är - speciellt inom test. Juniorkonsulter säljs in som specialister, gamlingar med sen länge slocknad gnista och intresse av att lära sig något nytt säljs som "Konsult med gedigen erfarenhet". Jag ser köparna sucka och betala - bara för att det inte finns något annat att få tag på. Och med det bristande intresse för IT-utbildningar som finns lär det inte bli bättre. Men finns det då inte nån i Polen eller Estland som kan göra ett lika bra jobb för halva priset...jooo. Outsourcing smyger sig på, flera större företag tittar utanför landets gränser. Baltiska företag flyttar till Sverige. Det värsta av allt är att jag ibland kan känna att vi förtjänar det. Vi har blivit för bortskämda och tror att hög lön och låg prestation kan hålla för evigt.

Slutsatsen då

Jag tror vi får passa oss även inom IT-branschen om vi ska kunna behålla våra fina jobb och bra löner. Det är oss själva det hänger på. Jag anlitar hellre en person i Sverige för lite mer pengar om jag vet att kvaliten är som en Volvo. Men blir jag besviken för ofta så tappar jag mina ideal. Jag har en egen karriärplan, i den ingår egen utbildning VARJE ÅR. det räcker inte med en dålig kurs som snabbt glöms bort. Testare - du har en lysande karriär framför dig - men bara om du själv är villig att satsa på den! Annars kommer Andrus från Tallinn att ta din plats (jobbade i et projekt i Estland en gång och alla deltagare hette Andrus och var både trevliga och duktiga)  Kom ihåg att en nöjd kund kontaktar dig igen.

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.

Hur kommer det sig att fokus för automatisering av tester ligger på användandet av dyra kommersiella verktyg som mycket sällan ger någon vinst åt andra än verktygsleverantörerna? Få är de som verkligen lyckats tjäna något i det långa loppet medan historierna om misslyckanden duggar tätt. Möjliga faktorer är en massiv marknadsföring samt en brist på alternativa synsätt hos oss testare. Jag vill därför presentera ett alternativt synsätt som kallas agil automatisering.

Agil automatisering handlar om att vi istället för synsättet att verktygen ska ersätta oss manuella testare genom att utföra samma tester automatiskt, så är verktygen ett sätt för oss att utföra tester som är svåra eller omöjliga att göra manuellt. Ett exempel är verktyg för prestandatest. Det är i princip omöjligt att simulera trafik utan någon sorts verktyg - där funkar faktiskt de kommersiella bra så länge det finns experter som sitter bakom spakarna. För mig som testare kan det handla om att jag vill lägga upp 200 användare i min testdatabas via det grafiska gränssnittet - här kan det passa bra med ett litet script. Det kan också handla om att analysera loggfiler med tusentals rader och markera det som verkar konstigt. Något jag skulle ha velat ha i ett nyligt projekt var ett sätt att själv ställa frågor till en komponent utan att ha det grafiska gränssnttet klart samt att få ut svaren och skriva dem på ett aptitligt format. Här behöver jag någon som kan hjälpa mig med det tekniska - troligen en utvecklare i projektet. James Bach pratar om Toolsmith - en verktygssmed - som kan hjälpa oss med den här typen av verktygsbyggande. Oftast löser vi problemen med hjälp av gratisverktyg eller hemmabyggen. Nyckelorden är snabbt, billigt och omedelbar användning.

Jag har bara nosat litegrann på detta otroligt intressanta ämne men hoppas att kunna förkovra mig vidare. Letar efter någon med programmerarbakgrund som gillar test och vill jobba med testautomatisering som INTE handlar om att använda dyra kommersiella verktyg. Jag efterlyser talare som jobbat med egna verktyg och vill prata om hur det lyckats.

För den som vill börja själv finns gratisverktygen Canned Heat och Holodeck Lite att hämta hem från James Whittakers sida. AllPairs och PerlScript är två verktyg skapade av James Bach. Allpairs skapar testfall för alla par av värden mellan variabler PerlScript hjälper dig att skapa testdata, exempelvis en sträng av ett visst antal tecken eller alla ASCII-tecken.

Läs en utmärkt artikel på engelska om Agile automation