Gå till innehåll

Författare: Anders Sandström

Publicerat den

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.

Publicerat den

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.

Publicerat den

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

Publicerat den

(Kommentar till artikel i Computer Sweden 16 juni 2006) Den rubriken fick mig att haja till. Liksom meningen "Det finns för många inkompetenta testare eftersom det främst är utvecklare som blivit över som får hålla på med sådant" Syftet var att den provocerade läsaren omdelbart skulle slå upp och läsa hela artikeln och det lyckades nog tror jag. Trist är nog det sista jag skulle säga om mitt eget jobb som jag tycker är otroligt spännande och givande, så spännande att jag under tiden jag är föräldraledig läser mer på egen hand och skriver den här bloggen. I artikeln finns frågan hur utvecklarorganisationen ska öka statusen för testning och därmed kompetensen för testare. Jag tror att det är tvärtom - om vi testare blir bättre på det vi gör så ökar vår status. Sen står det att ITIL garanterar att man tänker på kvaliteten, Jag uttryckte mig nog mer som att ITIL visar att man reflekterar över hur man arbetar och det är viktigt för kvalitetstänkandet. Jag har bara läst om ITIL i pressen och inte själv implementerat någon av processerna och vill inte framhäva mig själv som någon sorts expert. Jag inser hur svårt det är för mig att uttrycka vad jag tycker genom någon annans alster i form av en artikel. Inser att en artikel måste han någon sorts vinkling för att bli intressant, denna gång inkompetensen hos min egen yrkesgrupp. Inser efter att ha läst igenom artikeln en tredje gång att det säkert finns många som kommer att bli upprörda av vad som står där och säkert en hel del som kommer att nicka instämmande. Nu frågar ni er vad jag egentligen har sagt eftersom det i artikeln står att bara de sämsta utvecklarna hamnar hos test. Min åsikt är att det under lång tid varit så att nyanställda och personer som inte kommer från IT-sidan har tildelats rollen testare och att de sedan utan någon form av utbildning förväntas göra ett bra jobb Nej, jag tror inte att det finns speciella personer med medfödda talanger som utan vidare blir testproffs utan att anstränga sig. Utbildning, övning, teknisk kompetens och en vilja att lära sig är essentiella ingredienser för att bli en bra testare. Jag blir förvånad då många testare jag pratar med erkänner att de aldrig öppnat en bok eller läst en artikel om test. Vi måste dessutom för att bli riktigt bra känna till grunderna i utvecklingsprocesserna, modellering och helst lite databaser. Och självklart har jag en stor mängd mycket kompetenta kollegor både på och utanför min egen arbetsplats och tycker inte att alla utom jag själv är idioter. Det hoppas jag att min blogg och min bok visar.

/Torbjörn

Publicerat den

Alla kan vi göra fel, eller inte riktigt orka ända fram eller helt enkelt så misslyckas något fast vi gjort allt vi kan. Det första jag tänker på är min egen bok. Det var ju inte så svårt att se att vissa av bilderna i boken är suddiga och knappt läsbara. Vad beror det nu på efter alla timmars korrekturläsning och granskning av experter. Vem är syndabocken? Att jag själv inte hade tillräckligt bra koll på hur bilder måste behandlas för att de ska se bra ut i en tryckt bok sa jag redan från början till min förläggare. det löser sig sa han, vi tar in ett proffs som sätter boken. Hon kommer att säga till om dina bilder inte duger, trodde han ja! Antingen visste hon inte vad som dög eller så visste hon inte att hon skulle berätta det för mig eller så antog hon att det hon fick var det slutliga som inte gick att ändra. Resultatet blev följande:

1- Jag skapade bilderna i Visio eller Powerpoint och sparade dem sen som GIF eller JPG på ett som jag tyckte likvärdigt sätt - uppenbarligen inte tillräckligt bra i vissa fall, men helt OK i andra - märkligt!

2 - Dessa bilder fanns i början i ett Worddokument som jag tyckte såg helt OK ut vid utskrift

3 - Nästa steg var att all text separerades från bilderna och boken sattes i ett speciellt redigeringsprogram.

4 - Vid sättningen försvann tabellformat, rubriknumrering, fotnoter, innehållsförteckning, figurtexter, index och annat kul autoformatterat.

5 - Resultatet blev ett antal granskningar innan alla dessa detaljer var på plats. Gransknngen skedde på en PDF-version där jag fick uttryckliga instruktioner om att bildkvaliteten i pdf-filen var lägre än den slutliga så bilderna uppfattade jag att jag skulle strunta i

6. Slutligen då, en dag före tryckning, meddelar tryckeriet att vissa bilder - inga specifika nämnda utom ett par som byttes ut - hade för låg kvalitet och skulle bli dåliga. Hmm, lite väl sent att göra om allting då.

Slutsats: Tråkigt men sant, jag tyckte att jag gjort vad jag kunde. Vad tänker jag på inför nästa gång, nästa version? Ja då plockar vi in ett nytt proffs men den här gången träffas vi och kommer överens om vad vi förväntar oss av varandra. Så att jag vet vad som krävs av mig och han vet vad vi vill ha. Sen kräver jag att få en slutlig version att granska som är av samma kvalitet som det slutliga trycket. Om det lyckas bättre då, det får vi hoppas. Hade inte förstått alla komplikationer det innebar att ge ut en bok. Vem syndabocken är spelar mindre roll, det är jag som får lida för det och ni som irriterar er på de (som tur är ganska få) - bilder som inte är av perfekt kvalitet.