Software Testing Club har i dag publicerat sin senaste e-bok ”A Tester Is For Life, Not Just For Christmas” där ett antal testare frÃ¥n hela Europa (däribland undertecknad) svarar pÃ¥ intervjufrÃ¥gor om livet i testbranschen.
E-boken är helt gratis att ladda ned. Den som vill göra en god gärning till julen uppmanas att skänka en slant till Oxfam, som arbetar för att minska fattigdom och orättvisor i världen.
I dag vill jag diskutera en artikel som min indiske testarkollega Inder P Singh tipsade om. Den fick mig att tänka till på hur man kan använda statistik för sina egna syften.
Artikeln i fråga är en pressrelease från Electric Cloud, ett amerikanskt företag som säljer mjukvara för automatisering av arbetsprocesser. Den handlar om en undersökning där Electric Cloud tillfrågat sammanlagt 144 personer inom IT-branschen om deras inställning till och erfarenhet av mjukvarutestning. Resultaten som presenteras är hyfsat nedslående:
Stopp! Ett ögonblick, läs sista punkten igen och begrunda den för ett ögonblick! Vad pressreleasen säger är alltså att buggen har orsakats av en dålig testprocess eller testmiljö snarare än något som hänt under utveckling. Kan det verkligen stämma? I min föreställningsvärld orsakar testningen inga buggar, oavsett hur dålig processen och miljön än må vara. Testningens uppgift är att hitta felen och som vi vet finns de redan där när vi börjar testa. De har tillkommit någon gång under systemets design. I mitt tycke är det mycket märkligt att så stor andel som 58% av de tillfrågade beskyller testningen för att orsaka felen.
Läser man vidare i artikeln upptäcker man flera spännande detaljer. Rubriken lyder som följer: ”Survey Finds 58% of Software Bugs Result from Test Infrastructure and Process, Not Design Defects”. Enligt rubriken beror alltsÃ¥ 58% av buggarna pÃ¥ problem i testprocessen och testmiljön. Det är ett helt annat pÃ¥stÃ¥ende än i sista punkten ovan. FrÃ¥gan är om bÃ¥da uppgifterna är korrekta resultat frÃ¥n undersökningen. Personligen misstänker jag snarare att skribenten har blandat ihop koncepten och formulerat sig fel, men det är omöjligt att veta säkert hur det förhÃ¥ller sig.
Vidare påstår sig 12% av de tillfrågade företagen använda helt automatiserade testsystem. Man kan fråga sig vad detta innebär i praktiken. Att ingen manuell testning görs över huvud taget? I sådana fall kommer genast två följdfrågor: Är detta ett mål att sträva efter? Och är det ens möjligt att uppnå?
Knappt 10% säger sig arbeta med enbart manuella tester. Andelen låter alldeles för låg i mina öron, förmodligen på grund av ett begränsat urval i undersökningen. Jag misstänker att andelen kan dubblas flera gånger om. Det är många företag som enbart testar manuellt.
Finns det då någon bra lösning på problemen som beskrivs? Electric Cloud anser att lösningen består i att införa automatisering för att spara både tid och pengar. Det är kanske inte så förvånande med tanke på deras affärsverksamhet. Kanske har de också rätt. Testautomatisering har både för- och nackdelar. Men är automatisering den enda lösningen eller kan man tänka sig alternativa lösningar? Vad anser du? Skriv en kommentar och berätta hur du ser på den här frågan!
SAST Väst inledde året på ett ambitiöst sätt med att bjuda in James Bach, en veteran i testsammanhang, som alltid är redo att dela med sig av sina tankar och åsikter.
Föredraget hade titeln ”Beyond Test Cases” och handlade om vilken ställning testfall bör ha i vÃ¥rt arbete. James menade att mÃ¥nga organisationer har en övertro pÃ¥ skriptade testfall som leder till att testarna blir begränsade alldeles i onödan. Han framhöll att testfall är helt rätt i somliga situationer, men efterlyste ett större urval av verktyg för testare.
James pÃ¥pekade att det inte ens finns nÃ¥gon entydig definition av vad ett testfall egentligen är. Säg att man skapar ett skript för automatiserad testning av ett inloggningsformulär och lÃ¥ter ett verktyg köra skriptet med 100 000 olika par användarnamn och lösenord frÃ¥n en databas – hur mÃ¥nga testfall är det dÃ¥? 1 testfall? 100 000 testfall? Man kan argumentera för bÃ¥da varianterna. Men säger det egentligen sÃ¥ mycket om testet? Nej, ansÃ¥g James, det finns ingen garanti att antalet testfall stÃ¥r i förhÃ¥llande till testtäckningen, sÃ¥ i praktiken är det en siffra som inte säger nÃ¥gonting alls. Antalet testfall kan variera rejält beroende pÃ¥ vem som skriver dem och vilken teknik som används. Det är väldigt enkelt att anpassa antalet beroende pÃ¥ om man vill ha mÃ¥nga eller fÃ¥ testfall.
Som ett alternativ till skriptade testfall föreslog James utforskande testning för att fÃ¥ en större variation och därigenom öka chansen att hitta fler fel. I samband med det tipsade han om fördelarna med att använda en ”testing playbook”. Det är ett dokument som innehÃ¥ller bra-att-ha-information om produkten som ska testas; listor, tabeller, flödesscheman och liknande. Allt för att förenkla testarbetet och fÃ¥ bort eventuella oklarheter.
Arbetar din organisation huvudsakligen med skriptade testfall, eller har ni tagit fram alternativ liknande de som James Bach talar om? Har du erfarenheter av testing playbooks eller andra hjälpmedel för att underlätta testarbetet? Skriv en kommentar och berätta!
Se mötesanteckningar och presentation på SAST:s webbplats.
Vissa anser att det är den mest meningslösa maskin som nÃ¥gonsin har uppfunnits. Andra tycker att det är en lysande idé i all sin enkelhet. Det handlar om en liten lÃ¥da med en spak pÃ¥ toppen. När användaren slÃ¥r pÃ¥ maskinen genom att föra spaken framÃ¥t, öppnas en lucka i lÃ¥dan och en mekanisk arm sträcker sig fram, petar tillbaka spaken till sitt ursprungliga läge, drar sig tillbaka och stänger till sist locket. NÃ¥got annat syfte än att stänga av sig själv har maskinen inte. Man fÃ¥r intrycket att lÃ¥dan helst av allt vill bli lämnad ifred. Därför kallas den ibland för ”leave me alone box”. Uppfinnaren Claude Shannon (1916 – 2001) kallade den dock för den ultimata maskinen.
Föreställ dig nu att du får en sådan maskin i din hand. Tänk dig också att jag ber dig testa den. Hur skulle du gå till väga? Vilka tester skulle du genomföra och varför?
FrÃ¥gan gÃ¥r till dig som besöker Happy Day 2.0 och utgör vÃ¥rens tävling där första priset – för det bästa svaret – är ett presentkort pÃ¥ 25 dollar hos ThinkGeek.
Skicka in ditt tävlingsbidrag i form av en kommentar på detta inlägg senast den 15 maj 2010. Glöm inte att fylla i din e-postadress så att jag kan nå dig om du vinner. Det är tillåtet att skicka in flera bidrag. Juryns beslut kommer att tillkännages efter tävlingstidens utgång och kan inte överklagas.
Lycka till!
NÃ¥gra av de testartyper som beskrivs i Rob Lamberts e-bok
I dag vill jag tipsa om en nyligen utkommen e-bok som du kan ladda ned och läsa alldeles gratis. Den heter ”Tester Types” och är utgiven av Rob Lambert frÃ¥n bloggen The Social Tester i samarbete med Rosie Sherry pÃ¥ Software Testing Club som jag har skrivit om tidigare.
Rob Lambert har under sina Ã¥r som mjukvarutestare lärt känna en hel del testarkollegor och alla deras olika personligheter. Dessa har fÃ¥tt bli utgÃ¥ngspunkten när han i sin bok beskriver 19 olika personlighetstyper bland testare, däribland magikern (som pÃ¥ ett närmast magiskt sätt lyckas hitta buggar), nätverkaren (som har järnkoll pÃ¥ alla pÃ¥ kontoret), dramadrottningen (som alltid överreagerar när hon hittar en ny bugg), checklistaren (som hÃ¥ller sig krampaktigt till testfallens beskrivningar) och utforskaren (som inte följer utstakade vägar och därigenom ofta hittar de riktigt knepiga buggarna). Det finns även en typ som kallas för Chuck Norris, urtypen för alla testare med en dÃ¥lig attityd…
Bokens texter är skrivna med glimten i ögat och gör alltså inga anspråk på att vara vetenskapliga. Ändå tycker jag mig känna igen några av mina egna kollegor i beskrivningarna. Vilken typ jag själv är har jag ännu inte lyckats bestämma. Kanske är jag en blandning av flera typer. Ladda ned e-boken från Software Testing Club och se om du kan ta reda på vilken typ av testare du själv är. Skriv i så fall gärna en kommentar till det här inlägget och berätta.
Illustrationerna ovan är återgivna med tillstånd av Rosie Sherry.
Lite testhumor i höstmörkret. Håll till godo!
En grupp utvecklare och testare var pÃ¥ väg till en mässa. Ombord pÃ¥ tÃ¥get visade det sig att alla utvecklarna hade köpt var sin biljett. Testarna hade däremot bara köpt EN biljett till hela gruppen. Utvecklarna skrattade och ropade skadeglatt: ”Nu kommer konduktören!”, varpÃ¥ alla testarna skyndade sig in sig pÃ¥ toaletten. Konduktören kom in i vagnen, knackade pÃ¥ toalettdörren och sade: ”Biljetten, tack!”. Testarna sköt ut biljetten under dörren och fick den stämplad. NÃ¥gra minuter senare kunde de smyga sig ut och Ã¥ter inta sina sittplatser.
Vid det här laget kände sig utvecklarna ganska fÃ¥niga. Inför hemresan sÃ¥g de därför ocksÃ¥ till att köpa EN biljett till hela gruppen. Den här gÃ¥ngen hade testarna inte köpt nÃ¥gon biljett alls. Utvecklarna fick sig ett gott skratt. SÃ¥ ropade den testare som utsetts till spejare att ”nu kommer konduktören”, varpÃ¥ bÃ¥da grupperna skyndade sig in pÃ¥ var sin toalett. Innan konduktören stigit in i vagnen smög sig en av testarna ut, knackade pÃ¥ utvecklarnas toalettdörr och sade: ”Biljetten, tack!”…
Vad lär vi oss av denna lilla historia? Jo, att ett test som går bra i integrationstest inte alltid fungerar i systemtest.
Ibland när man sitter och klurar över ett problem är det lätt att tro att man är den enda personen i världen som har just det problemet. Så är sällan fallet. Tvärtom finns det kollegor över hela världen som garanterat har löst identiska, eller åtminstone liknande, problem. Som testare är man aldrig ensam. Webben erbjuder goda möjligheter till diskussion i form av nätgemenskaper och forumstjänster.
Syftet med det här inlägget är att presentera några av de bästa forumen som jag känner till. Det finns naturligtvis en uppsjö av andra, liknande tjänster på nätet, men långt ifrån alla har det besökarantal och det engagemang som krävs för att bli användbara och intressanta. De sidor som presenteras här uppfyller båda dessa kriterier. Om du är nyfiken kan jag varmt rekommendera att du besöker sidorna och anmäler dig som medlem, något som i de flesta fall är helt utan kostnad.
1 QA Forums (www.qaforums.com)
QA Forums är kanske det mest kända forumet för testare på webben. Det drivs av företaget BetaSoft Inc och har varit igång i mer än tio år. Med åren har ett digert arkiv av diskussionsfrågor och svar vuxit fram. Här finns forum för en rad kända testverktyg, testtekniker, testmetoder med mera. Alla inlägg är direkt tillgängliga från sidan. För att skriva egna inlägg måste man registrera sig, vilket är gratis.
2 Software Testing Club (www.softwaretestingclub.com/forum)
För ett par Ã¥r sedan sÃ¥g den brittiska testaren och företagaren Rosie Sherry behovet av ett diskussionsforum med en ”quality approach” för mjukvarutestare. Hon startade därför Software Testing Club, en nätgemenskap som snabbt blev populär och för närvarande har drygt 3500 medlemmar. De flesta inläggen finns samlade i det generella forumet som har en stor spännvidd. Alla kan läsa de inlägg som är postade, men för att själv skriva inlägg mÃ¥ste man vara medlem. Det kostar $5 per mÃ¥nad alternativt $50 per Ã¥r.
3 uTest (forums.utest.com)
Företaget uTest Inc fungerar som förmedlare av testtjänster. Intresserade testare kan anmäla sig till uTests tjänst och får därefter möjligheten att hjälpa företag att testa mjukvara hemifrån. Provision utbetalas baserat på rapporterade fel. Till webbtjänsten hör även en nätgemenskap där forumet utgör navet. Det startades tidigare i år, men har redan fått en trogen besökarskara. De ansvariga bakom sidan går ibland in och stimulerar till diskussion genom att posta länkar till aktuella frågor, gärna med en twist, som sätter fart på meningsutbytet. Endast utvalda inlägg är direkt tillgängliga. För att få läsa samtliga samt skriva egna inlägg krävs en registrering, något som är helt gratis.
4 Test Republic (www.testrepublic.com/forum)
Test Republic är en nätgemenskap som drivs av Edista Testing Institute i Bangalore, Indien. Föga förvånande kan man finna en hel del indiska testare på medlemslistan, men även yrkesmän och kvinnor från åtskilliga andra länder. Bland de mer kända deltagarna kan nämnas Michael Bolton, Tom Gilb och Pradeep Soundararajan. Forumet fokuserar på allmänna testfrågor och innehåller också en del intressanta artiklar och intervjuer. Allt material är direkt åtkomligt. För att själv skriva inlägg i forumet fordras en kostnadsfri registrering.
Har du tips på andra bra testarforum som förtjänar att omnämnas? Skriv gärna en kommentar!
I dag vill jag göra dig uppmärksam på två böcker som publiceras i början av september och som jag personligen tror kommer att vara riktigt intressant läsning för testare. Hos Amazon.com finns redan nu möjlighet att förboka båda böckerna med leverans så snart de utkommit.
”Secrets of a Buccaneer-Scholar: How Self-Education and the Pursuit of Passion Can Lead to a Lifetime of Success” av James Bach
Den som vill hänga med i utvecklingen på dagens snabbt föränderliga arbetsmarknad måste hela tiden se till att utveckla sig. Att vila på gamla lagrar fungerar inte. Ständigt lärande är modellen. James Bach, välkänd profil inom testbranschen, har skrivit en bok som handlar om hur varje människa bör ansvara för sitt eget lärande och skapa sig en utbildning helt på sina egna villkor. För morgondagens stjärnor är de som aldrig upphör att lära sig nya saker.
”Exploratory Software Testing: Tips, Tricks, Tours, and Techniques to Guide Test Design” av James A. Whittaker
I våras skrev jag om James Whittakers testturer. I höst kommer boken som beskriver konceptet mer ingående och tipsar om hur man som testare gör för att upptäcka de där särskilt allvarliga men svårfunna felen som man sällan lyckas hitta med hjälp av vanliga skriptade testfall. James är en inspirerande testare och författare som kan förmedla sina erfarenheter på ett lättbegripligt och underhållande sätt.
”Secrets of a Buccaneer-Scholar: How Self-Education and the Pursuit of Passion Can Lead to a Lifetime of Success” av James Bach
Den som vill hänga med i utvecklingen på dagens snabbt föränderliga arbetsmarknad måste hela tiden se till att utveckla sig. Att vila på gamla lagrar fungerar inte. Ständigt lärande är modellen. James Bach, välkänd inom testbranschen, har skrivit en bok som handlar om hur varje människa bör ansvara för sitt eget lärande och skapa sig en personlig utbildning helt på sina egna villkor. För morgondagens stjärnor är de som aldrig upphör att lära sig nya saker.
Bokens sida hos Amazon.com (http://amzn.com/1439109087)
”Exploratory Software Testing: Tips, Tricks, Tours, and Techniques to Guide Test Design” av James A. Whittaker
I våras skrev jag om James Whittakers testturer. Här kommer boken som beskriver konceptet mer ingående och ger exempel på vad man som testare bör tänka på för att ha chansen att upptäcka de där särskilt allvarliga men svårfunna felen som man sällan lyckas hitta med hjälp av vanliga testfall.
Bokens sida hos Amazon.com (http://amzn.com/0321636414)
Sommaren är här och med den följer många lediga, lata semesterdagar. För den som vill ha tips på några intressanta böcker att läsa i hängmattan har jag liksom förra året sammanställt en läslista för mjukvarutestare:
1 Agile Testing. (Lisa Crispin & Janet Gregory, Addison-Wesley, 2009, ISBN 9780321534460) På senare år har agila metoder vunnit mark inom mjukvaruutveckling. I och med omställningen från traditionell utveckling förändras också testarens roll. Författarna beskriver i sin bok var test hör hemma i agila projekt, vilka kunskaper som krävs av testare, hur utvecklare och testare kan samarbeta samt hur projekt kan lyckas bättre med testautomatisering.
2 How We Test Software at Microsoft. (Alan Page m fl, Microsoft, 2008, ISBN 9780735624252) För Microsoft, en av världens största mjukvaruleverantörer, är test ett omfattande och viktigt verksamhetsområde. Faktum är att företaget har lika många testare som utvecklare anställda. Författarna, som är testledare, beskriver hur man inom företaget arbetar med olika aspekter av test för att framställa produkter som lever upp till kundernas högt ställda förväntningar.
3 Konsten att läsa tankar. (Henrik Fexeus, Månpocket, 2009, ISBN 9789172321403) Jag har tidigare skrivit om Henrik Fexeus och hans program Hjärnstorm. Nu har han utkommit med en bok i konsten att avläsa andra människor. Det är känt att kommunikation består av en liten, verbal del och en stor, icke-verbal del. Den som kan tyda och förstå vad andra människor menar med sina rörelser, kroppshållningar, röstlägen m m har en stor fördel. Det är kunskaper som kan användas i situationer där man vill påverka och övertyga andra. Och det är ju något som vi testare ofta vill göra, eller hur?
4 Tools of Critical Thinking. Metathoughts for Psychology. (David A. Levy, Pearson, 1997, ISBN 9780205260836) Den här boken handlar om olika aspekter kring tänkande; problemlösning, beslutsfattande och kreativitet. Författaren beskriver ett antal olika tankefällor som det är lätt att falla i samt hur man lär sig att känna igen dem.
5 I am a Bug. (Robert Sabourin, 1999, ISBN 9780968577400) Robert Sabourin undervisar i mjukvaruteknik och har skrivit den här boken för att lära barn hur det här med mjukvaruutveckling, test och buggar fungerar. Bilderna är ritade av Roberts 12-Ã¥riga dotter. Boken rekommenderas för läsare i Ã¥ldern 3 – 8 Ã¥r, men inget hindrar att även äldre personer läser den. Dessvärre är priset aningen högt hos svenska bokhandlare, men Amazon.com säljer begagnade exemplar till en rimlig penning.
Förra veckan deltog jag pÃ¥ en nätbaserad föreläsning med James A Whittaker pÃ¥ temat ”5 sätt att revolutionera din kvalitetssäkring”. James är mjukvaruarkitekt hos Microsoft och en inflytelserik person inom testvärlden, som under sin karriär som professor vid Florida Tech grundade ett framgÃ¥ngsrikt forskningsprogram inom mjukvarutestning och gav ut flera böcker med konkreta tips om hur man har sönder mjukvara – i testsyfte, givetvis!
Under föreläsningen talade James om vikten av att använda rätt verktyg, tekniker och tillvägagångssätt för att lyckas med testarbetet. Alla insikter som han presenterade var klart intressanta och jag kan varmt rekommendera att du viker en timma åt att se på den. Det var emellertid en av punkterna som särskilt fångade mitt intresse och som jag gärna vill återge.
James berättade om en ny testteknik som folket pÃ¥ Microsoft har utvecklat och använder i sitt dagliga arbete. Han kallar den för testturer. Ordet ”tur” används här i betydelsen ”resa, tripp” och den bakomliggande tanken är att en utforskande testares framfart i ett datorprogram kan liknas vid en turist som tar sig fram genom en främmande stad. För att hitta rätt behövs nÃ¥gon sorts stöd, till exempel kartor, vägskyltar, guider, bussar o.s.v. Och beroende pÃ¥ vad turisten (eller testaren) är intresserad av att se kommer turen att te sig olika. NÃ¥gra exempel pÃ¥ testturer som James nämner är
Som synes finns det testturer för de mest skilda syften. James berättade att han arbetar pÃ¥ en bok som ska komma ut senare i Ã¥r. Den kommer att beskriva konceptet med testturer närmare, men redan nu kan den intresserade besöka James’ blogg där han har börjat presentera nÃ¥gra av turerna under vinjetten ”tour of the month”.
Jag tror absolut att testturer har potential att bli ett värdefullt tillskott i testarens verktygslåda. Framför allt som inspiration för att hitta testfall som undersöker nya aspekter av ett program. Vad tror du själv? Kan du komma på några andra testturer som kan användas för vissa ändamål?