På wikipedias engelska version finns en beskrivning av vad ”Exploratory Testing” är. Jag vill redan från början nämna att jag är inte emot Exploratory Testing snarare ser jag det som ett steg i rätt riktning. Kanske är det så att pendeln slår tillbaka efter många är av alltför stereotyp testning. Det gäller här att hålla emot så att inte slår allt för långt tillbaka.
Min erfarenhet från utveckling av programvara under 80-talet var att vi gjorde exploratory testing i någon mening. Det pratades i min dåvarande domän, CAD/CAM system om att automatisera testerna men där jag arbetade fanns det i alla fall inte. Vi hade inte heller dedikerade testare på den tiden vilket gjorde att utvecklarna stod både för testningen under utvecklingstiden, och när det var dags att slipa bort de sista kanterna på systemet. Det jag känner idag för det sättet att testa var att det var positivt ur två aspekter. Dels för att utvecklarna verkligen kände sig ansvariga för att det skulle fungera. Vi var ju även ansvariga för att åtgärda de problem som kunderna rapporterade när det så småningom driftsattes på ett varv. Vi träffade också, ute på varven, de personer som körde systemen och såg vilka konsekvenser ett fel skulle kunna få. Vi blev väldigt känslomässigt engagerade i kundernas problem och dess konsekvenser det kunde få. Inte några quick fix var att tänka på. Dels testade vi utefter var vi trodde det skulle uppstå problem och vi dök djupare i de delar som hade varit skakiga tidigare.
Efter hand så har jag sett testavdelningar växa fram vars huvuduppgift blev allt mer att peka på fel i programvaran. Låter helt ok om man fortsatt att arbeta på samma sätt som utvecklarna men med ett fokus och tänk på att försöka hitta svagheterna i systemet. Tyvärr har jag sett att det ofta inte längre är kunden som står i centrum. Företagen sätter upp mål om att det skall hittas x-antal fel per timmer eller det premieras om testarna hittar många fel. Hur går det ihop med målet för företaget egentligen? Jag har sett att testarna letar efter de lätta felen och gärna skriver flera rapporter på ”samma” fel men man hittar olika sätt att påvisa samma fel.
Successivt har det också blivit viktigt att skriva automatiska tester för att snabbt kunna hitta regressioner i ett system. Att skriva tester som testar enskilda klasser eller motsvarande har mer eller mindre blivit standard. Likaså att skriva funktionella tester vilket ofta är svårare. Jag har många gånger fått känslan av att man varit överambitiös när man satt mål i vilka automatiska tester som skall skrivas. Det första testfallet tillför mycket men successivt minskar ROI. Det gäller att sluta innan det kostar mer än det smakar. När man sedan upptäcker att underhållet av dessa testfallen blir en börda så får man nog tänka sig för en gång till innan man fortsätter på en sådan väg.
De senaste åren känns det som att det blivit en hype med Exploratory Testing. Det skall certifieras och många vill tjäna pengar på något som egentligen är sunt förnuft. Allt skall lösas med Exploratory testing. Det känns hela tiden som det växer upp en industri kring olika sätt att arbeta med testning, och även andra idéer, och man försöker berättiga sin existens i företagen. Testning är viktigt men det gäller att göra den på ett intelligent sätt med kundens nytta för ögonen. Sätt in resurserna vid rätt tillfälle och se till att testare och utvecklare samarbetar så att det blir en effektiv testning genomförd på ett tidigt stadium i processen. I slutändan skall förstås en verifiering och validering ske av systemet men då skall det mer eller mindre vara felfritt. Fram tills dess finns det ingen anledning till att dela upp utveckling och test i olika organisationer.
Låt inte pendeln slå åt för långt åt andra hållet. Behåll de saker som är bra med automatiska tester och komplettera dem med Exploratory Testing eller som jag skulle kalla det intelligenta tester. Men framförallt samarbeta för företagets bästa och sätt inte egna intresse först.