Frågan om man ska använda utforskande testning ”Exploratory Testing” eller fördefinierade testfall ”scripted testing” är något som jag funderat över, tyvärr eller kanske är det bra att det inte finns något svar för det skapar en möjlighet till diskussion. En del vill ha ”scripted testing” medan andra föredrar ”exploratory testing”. Ställs frågan till någon som har erfarenhet inom test är för det mesta svaret, att det beror på situationen eller organisationen, och visst är det så. Likafullt anser jag att utforskande testning är mycket mer än ett komplement till ”scripted testing”, metoden kan på rätt sätt används för att motivera och utveckla testare som brinner för sitt yrke.
Tyvärr har jag redan under min korta karriär insett att det finns testare/organisationer som ser testprocessen som något enkelt. Tyvärr har jag även redan träffat testare/organisationer som vill ha det enkelt, där test innebär exekverig av fördefinierade testfall. Det är inget fel på enkelhet likväl handlar inte test om att det endast ska vara enkelt. Testfall som exempelvis regressionstester bör i de fall där det går, automatiseras för att sedan låta den mänskliga kognitiva processen få utrymme att ”testa”.
Mina studier inom beteendevetenskap har givit mig en inblick i hur människan införskaffar sig kunskap och utvecklas. En klassisk pedagogisk term är Learning by Doing, exempelvis så lär sig barn och utvecklas genom att försöka och testa sig fram, jag tycker mig finna likheter mellan begreppen Learning by Doing och Exploratory testing.
Strävan att lära sig bör vara en av de drivande faktorerna för att bli en ”bra” testare, och det gäller alla yrken. Att upptäcka och motivera testare till att vilja lära sig kan måhända inte alltid vara det lättaste, men en attitydförändring eller en upplysning om det livslånga lärandet är en början, dvs. att lärandet är en fortgående process.
Genom att tidigt lära ut exploratory testing bland juniora testare så tror jag att man kan skapa ett kreativt sätt att fundera och angripa frågeställningar om testprocessen. Visst det krävs erfarenhet för att lyckas, jag tror dock inte att det är till skada att forma kunskapen under ett tidigt skedde. Vad brukar man säga? Det är svårare att lära en gammal hund att sitta.
Jag skulle tro att desto tidigare man lär sig metoder som inriktar sig mot utforskning av artefakter samt vikten av att förstå vad systemet har för funktion och användningsområde så skapas en bra grund för att kunna utveckla sin egen testskicklighet.
Exploratory testing is simultaneous learning, test design, and test execution. James Bach
Testyrket är ett utmärkt sätt att lära sig organisationen, systemen, människorna och arbetsprocessen, det är viktigt att man lär sig ta tillvara på möjligheterna inom testyrket.
Jagannath, du beskriver dig själv som en junior testare. När jag läser ditt inlägg så framstår du som mer senior än många som jag stöter på med fler år i branschen än vad du har. Kom ihåg att senior eller junior har inte med antalet år i branschen att göra utan hur väl du utövar ditt yrke.
Det är väldigt tråkigt att höra att du tidigt i din karriär redan ”slagits ned” vad de konservativa och bakåtstävande testorganisationer, processer och människor som finns ibland oss. Det finns hopp, vi är redan en ansenlig mängd personer ( och vi blir fler och fler) som aktivt jobbar för att bryta ner dessa barriärer som finns för att kunna utöva vårt yrke, test, på ett sätt som vi kan vara stolta över. Vill du skapa en förändring så behöver du inte göra det ensammen.
Test processer som utgår från scriptad test där man mäter testningen med metrics som antal exekverade testfall, Pass/Fail förhållande och antal hittade fel (eller varför inte kvalité i % 🙂 ). Dessa är djupt rotade i vår industri och förespråkarna för dessa har verkligen lyckats sälja in sin bluff (alså att de pratar om testing). Tyvärr har vi ISTQB, Tmap och liknande att tacka för att göra vårt yrke till en pest och pina. Glädjande nog så när man fundera lite närmre på det så förespråkar dom inte Testning utan Checking. Jag hänvisar här till Michael Boltons beskrivning av skillnaden mellan Test och Checks ( http://www.developsense.com/2009/08/testing-vs-checking.html ). Detta här är kanske inget nytt men det är skrivet på ett tydligt sätt och gör att vi som faktiskt vill arbeta med testning kan undvika roller som efterfrågar checks. Alså har vi en skillnad på roller i hur dagens testorganisationer, är du en testare eller en checker?
Är det så att du är en checker så fundera en gång till på ditt yrke. Risken är då mycket stor att det du idag gör kommer att antingen automatiseras eller flyttas till ett lågkostnads land. Du tillför ju ingen utöver armar och fingrar.
”Likafullt anser jag att utforskande testning är mycket mer än ett komplement till ”scripted testing””
Precis det är kanske dags att vända på steken och utgå från ET och sedan addera checks där dom behövs och gör nytta.
Det är kanske dags att släppa sargen och våga utmana och stimulera våra hjärnor och sinnen när vi är på jobbet.
Precis som du skriver så handlar testning väldigt mycket om att lära sig för att utvecklas. De flesta scriptade testfall lär sig aldrig mer hur många gånger den än körs.
Testning är så mycket mer än att läsa en testbok om testtekniker eller gå en kurs i testmanagment. Beteendevetenskap som du läst är en stor tillgång lika så är filosofi, general system thinking, kognition, psykologi, ekonomi, beslutsfattande, problem lösning, heuristics, m.m. Lär er mer om det ni tycker är intressant så kommer ni upptäcka att ni kan använda dessa lärdomar när ni testar.
Själv läser jag en boken The Satir Model, av Virginia Satir som var en av pionjärerna inom familjeterapi. Vad har det med test att göra? Läs så upptäcker ni det!
När ska ISTQB ta upp dessa aspekter och faktiskt börja lära ut testning?
Testning är inte enkelt och det finns ingen anledning att förhålla sig till det på det sättet. Jag vill i alla fall inte ha ett jobb som en maskin kan göra minst lika bra.
Härligt att höra att man inte är ensam om att vilja starta en förändring:) och bryta ner gamla barriärer.
Som sagt så är test ett perfekt tillfälle att lära sig och utvecklas, tycker även som Henrik A att ET borde få större utrymme inom testmetodik än vad det har idag.
När jag första gången läste James Bach artiklar och framför allt om ET fick jag direkt en annan syn på test och kände att detta måste spridas. Nu är det kanske så att många testare känner till James Bach och ET men det är aldrig fel att försöka och varför inte föra diskursen på olika testforum, för att sedan ta med diskursen till arbetsplatsen.
Det finns så mycket mer runt test att lära sig om man bara vill och vet hur.
Jag gillar den lite längre definitionen av utforskande testning:
“Exploratory software testing is a style of software testing that emphasizes the personal freedom and responsibility of the individual tester to continually optimize the value of her work by treating test-related learning, test design, test execution, and test result interpretation as mutually supportive activities that run in parallel throughout the project.” (Kaner m.fl.)
Det fina med den är att den kan innefatta detaljerade testfall man förfinar och grundar sin testning i, eller enradstester man improviserar kring, och allehanda andra metoder.
Motsatsen till exekvering av testskript är egentligen ad hoc-testning, vars rykte borde höjas.
Det var när vi på beställning av Microsoft gjorde ad hoc-testning som jag insåg att testning var nåt för mig.
Jagannath, vilken lysande debut på testzonen! Din fråge ställning, “Frågan om man ska använda utforskande testning ”Exploratory Testing” eller fördefinierade testfall ”scripted testing” är något som jag funderat över” är någonting som även jag funderat över, mycket och länge. De två angreps sätten kompletterar varandra, men det som fick att inse att utforskande test bör vara normal fallet och skriptad testning ett komplement, var när vi i testade ett system som hanterade analysresultat på ett medicinska provtagningslabb. Vi hade god kravtäckning och välskrivna krav som vi tyckte vi verifierat med skriptade testfall och betraktade systemtesterna som avslutade.
Efter de avslutade systemtesterna låg det en två veckors UAT period inplanerad, men beställaren valde att inte bidra med ämneskunniga resurser, då de inte hade tid tyckte de. Jag lade då in 2 veckor utforskande test med personas för att om möjligt täcka denna kunskapsbrist. Resultatet var häpnadsveckande, vi hittade massor, massor med fel och kanske framförallt så identifierade vi att arbetsflödet i gränssnittet inte alls var optimalt utan snarare ologiskt och improduktivt.
Sen den dagen så prioriteras utforskande tester betydligt höge än skriptande, även om även de behövs för att verifiera en del juridiska bitar, beräkningar m.m.
Sedan tycker James Wittakers Test tours gör utforskande testning ännu kraftfullare och tror det kommer omvända många av motståndarna idag.
Och till sist, det går i min värld utmärkt att kombinera utforskande testning och metrics.
Rikard, Ett förtydligande så jag inte missförstår dig.
”detaljerade testfall man förfinar och grundar sin testning ”
Med det menar du inte att man sätter upp ett antal fördefinierade test script som man sen exekverar i en förutbestämd ordning oavsett vad den testade mjukvaran ger dig för information, eller? För jag tolkar inte in det i Cems beskrivning av ET.
Kan dock tänka mig ett par andra tolkningar av din rad som kan passa in, men det är ändå undantagsfall. Bör ju ändå tillägga att jag ser Exploratory test och scriptad testning som sina motpoler.
Ja dom kan leva tillsammans men då adderar jag scriptade tester till min ET testning där dom tillför ett värde. För mig är det viktigt att skilja på dessa olika förhållningssätt till test då dom har helt olika syften.
Jonas – Javisst självkart funkar metrics och exploratory test tillammans. Inget motstridigt i det. Jag ställer samma krav på metrics oavsett vilken metod man använder.
Angående Wittakers tours så är dom underhållande och säljande, kan nog funka som en inkörsport till att börja prova på exploratory test. Dock är dom ganska innehållslösa och man blir inte vass på exploratory test genom att endast köra dom som Wittaker vill framhålla. ”every session must end in a tour” låter inte så context drivet i mina öron. Kika även gärna på Mike Kellys FCCCUTSVIDS heuristics som jag känner som mer ”rätt fram”.
Henrik; det jag menar är att om man ser Exploratory Testing som en approach (inte en teknik), så kan den innehålla både testskript, checklistor, odokumenterade scenarier, ren improvisation med mera.
Om man bara kör skript, och inte ändrar dem efterhand, så är det inte utforskande testning.
Men om man delvis använder detaljerade testfall skrivna i förväg, som ändras om det behövs, och prioriteras utifrån vad man lär sig, och som tillåter testaren att fritt välja testform; ja då är det utforskande testning.
Det är en grov förenkling att säga att utforskande och skriptad testning är motsatser, eftersom skriptad testning är mer ett samlingsnamn på en metod i många utföranden, och inte en approach.
Dock finns det många testsituationer där den enskilde testaren bara får utföra detaljerade testfall, och så snabbt som möjligt; och med så många Pass som möjligt.
Det är motsatsen till utforskande testning.
Min testsanning: Det är bra att testa på många olika sätt.
Rikard,
För mig det ett motsatts förhållande i utforskande och scriptad testning.
Jag tror att anledningten till att vi ser det lite olika är att jag just ser scriptad testning som en appoach precis som exploratory test.
Att man använer sig av test olika detaljerade script när det behövs innebär ju inte att man kör “scriptad testning”
detta kan naturligtvis också grunda sig i att vi menar lite olika när vi skriver “scripdad test”
Bra artikel Jagannath.
Cem Kaner har i sin presentation Introduction to Exploratory Testing (http://www.kaner.com/pdfs/QAIExploring.pdf) fler intressanta punkter. Han jämför skriptad testning och ET, se specifikt på “Areas of ongoing concern”. Han listar flera av de kontroverser som vi ofta diskuterar, och som dykt upp på detta forumet flera gånger.
Jag anser att synen på testning är det som påverkar oss mest. Har man idéen att vem som helst kan testa, dvs man kan låna in resurser från var som helst i organisationen utan att förbereda dem, där de sedan ska köra dessa så kallade testskript för att hitta möjliga fel. Eller ser man testning som ett yrke där det är ett hantverk att utföra testning, där varje testare har sina egna verktyg, tekniker och metoder de använder?
I det första fallet så behöver man testledare, testexperter eller testspecialister som skriver testfall åt testarna, som faktiskt “inte behöver” kunna någonting om testning. Att de har domänkunskap hjälper säkert, men att veta vad testning är spelar ingen roll. Många som hamnar på test ser detta som en bestraffning.
I det andra fallet så är det ju inte lika tydligt vad som gäller. Varje organisation, testgrupp beter sig då olika i och med att hantverket är olika.
Vid ett tillfälle i min testkarriär bestod testgruppen av några som såg sig ha yrket testare (och var stolta över detta) och andra delen såg sig som ha blivit degraderade till testare. Det var en konflikt i gruppen i flera år, innan vi insåg problemet.
När ska man då använda ET? Om du är i en situation som är första fallet så blir det svårare om själva testet planeras av någon annan, där du är exekverare av testet. I det andra fallet så är det ju enkelt.
Jag får nog hålla med Henrik att det finns ett motsatsförhållande mellan exploratory test och fördefinerade tester. Dock inte sagt att det ena utesluter det andra, jag behåller gärna en del regressions tester, helst då automatiserade, som vi kan använda för att se om något är värt att integrera.
Jagannath, att bryta ner barriärerna mot ET kan ta tid men det är väl värt att ge sig in den diskussionen, om inte annat så lär man sig en hel del om sin organisation.
Jag pratade med en läkare för ett tag sedan, det slog oss hur lika vårt arbete är på många punkter.
Vi söker bägge efter problem genom att ställa frågor. Vissa frågor krävs det att människor svarar på och vissa frågor får vi mäta oss till genom tester. Men det centrala är att vi utgår från våra erfarenheter för att finna problemen.
Tänk er hur en läkare skulle arbeta om de var en “checker”?
Jagannath, håller absolut med dig om att ET bör läras ut tidigt till juniora testare. Vill även ta det ett steg längre: Förhållningssättet i exploratory testing bör vara det första> vi lär ut till våra blivande kollegor, av just den anledningen du själv nämner, det skapar goda förutsättningar för ett fortsatt lärande genom att (bland annat) uppmuntra eget och kritiskt tänkande.
Att lära ut och ta till sig kunskap om exekverandet av verifierande testning eller checking är relativt enkelt (se bara på de låga kraven för att erhålla en ISEB/ISTQB-certifiering). Bättre då i min mening att börja med att lära sig att tänka utanför ramarna tidigt och inte fastna i den smala definitionen av testning. Glöm inte bort de implicita kraven!
Jag har försökt mig på en förklaring på de olika betydelserna av exploratory och scripted testing:
http://thetesteye.com/blog/2009/11/exploratory-testing-vs-scripted-testing-rich-terminology/