Fel, fel, fel!
måndag, 28 juni, 2010
Under Agila Sverige 2010 höll Joakim Ohlrogge från Agical ett mycket uppskattat blixttal som handlar om hur vi ser på fel och hur vi hanterar dem. Titeln för blixttalen var ”Fel, fel, fel!”.
Mot slutet av sin presentation argumenterar han för att vi kanske borde betrakta och hantera fel och testning på ett radikalt annorlunda sätt…
Det hölls många intressanta, insiktsfulla och lärorika blixttal under Agila Sverige 2010. Jag var inte där själv men har fått möjlighet att kika igenom dem alla på video efteråt.
Joakims tal fokuserar kring fel, hur vi betraktar dem och hur vi hanterar dem. Dels har vi antalet fel, dels har varje fel en ”allvarlighetsgrad”. Bilden blir dock inte komplett om vi inte dessutom tar hänsyn till hur lång tid felet existerar. En litet fel som existerar under en lång tid kan göra större skada än ett kortvarigt allvarligt fel. Det riskerar sluta i irritaion, frustration, färre användare, färre sålda produkter, osv. Med andra ord…
Felyta = allvarlighet x tid.
Den totala felytan kan då minskas på tre olika sätt:
- ”Släppa igenom” färre fel (minskar antalet fel)
- ”Släppa igenom” mindre allvarliga fel (minskar allvarligheten)
- Reagera på och hantera fel så fort som möjligt (minskar tiden)
Han argumenterar för att om vi kan agera snabbt och reparera fel fort kanske vi inte behöver vara lika rädda för att ”släppa igenom” fel. Även om felet är allvarligt blir felytan liten om felen bara existerar en kort stund.
Felytan för ett mindre allvarligt fel kan vara större än för ett kritiskt…
.
Konsekvens = Ingen testning?
Om man godtar felyta som vårt mätetal och som en mer sann beskrivning (för systemets kvalité ur ett defekt-perspektiv) fullt ut får det stora konsekvenser för vår testprocess.
Att minska antalet fel som slinker igenom och felens allvarlighet med en allt rigorösare testprocess är både kostsamt och tidskrävande, och gör dessutom inget för att dra ner livslängden på de fel som faktiskt hittas. Det kan till och med vara kontraproduktivt, en tung testprocess kan göra så att våra fel lever längre innan de blir åtgärdade.
Om vi istället fokuserar på processen (dvs. att höja kvalitén genom test driven development, par programmering, continuous integration, m.m.) och att möjliggöra snabba fixar (genom t.ex. defensiv programmering, defect proofing, rigorös loggning, etc.) samt att stöda snabba deployer av nya versioner som metoder för att minska felytan kan detta visa sig vara både betydligt effektivare och betydligt billigare.
Kan det vara så att det absolut effektivaste är att inte ha något testning alls? Hmm…
.
Joakim Ohlrogge är konsult på Agical AB.
Hans blogg heter ”The Point is Missed”.
.
.
Videoupptagningar från Agila Sverige 2010 hittar du här:
http://www.webbtv.nu/5557.htmFör att se ”Fel, fel, fel!” klicka på ”Celsius 20100510”.
När videon väl har laddats klicka på sista passet ”Fel, fel, fel!”.
Jimmy Janlén "Den Scrummande Konsulten" 
Nu förstår jag att du lägger in sista frågan som en provokativ startpunkt för diskussion, men jag känner ändå att jag ska/bör/kan kommentera.
Jag börjar från grunden, så att vi inte pratar förbi varandra.
Vad definierar du som ”testning”?
Du har helt rätt, frågan är provokativt formulerad.
I detta sammanhang syftar jag egentligen enbart till manuell script-baserad testning.
Ok, om vi säger såhär. Teamet utvecklar en e-handelssite som ska sälja möbler. Ett av beställarens krav är att 50 personer ska kunna genomföra köp av en valfri produkt inom 10 minuter. Han vill se bevis på att detta är görbart innan han sätter systemet i produktion. Och det ska vara som han säger ”riktiga människor, inget maskintjafs”. En grupp betatestare har anmält sig frivilliga. Är inte manuell script-baserad testning i detta fall att föredra för att försäkra sig om att betatestarna inte ”går vilse”?
manuell scriptbaserad testning är användbar och effektiv, men bara i vissa begränsade situationer, och konsten är att kunna bedöma vilka för- och nackdelar som finns i den givna situationen och våga ta ett beslut grundat i den analysen. Att ta ett kategoriskt och generellt beslut att det ena är bättre än det andra kommer vi ingen vart med är jag rädd, det kommer alltid finnas exempel som visar att det andra alternativet är bättre, det handlar om en praktisk och kontinerlig ROI analys, där det som investeras är tid och det du måste optimera, det vi utvinner är information om testobjektet. Är informationen värdelös så är testet värdelöst.
…jag märker att min interpunktionsförmåga är långt ifrån på topp idag, sorry.
”Manuell scriptbaserad testning är användbar och effektiv, men bara i vissa begränsade situationer…” – håller självklart med!
Som alltid handlar det om att göra bästa möjliga med begränsade resurser. Visionen om ett felfritt system är självklart en fin vision men nyckeln att nå dit tror jag inte ligger i en tung manuell script-baserad testprocess. Har man problem med att buggar slinker igenom tror jag inte lösningen är att göra test-processen ännu tyngre utan då finns det betydligt effektivare sätt att använda tiden och pengarna på.
absolut! Hittar jag ett fel i en produkt i ett agilt team så sätter vi oss tillsammans ner och kollar, varför dök det upp? Kan det finnas på andra ställen? Dessutom, om jag ser att samma fel dyker upp på olika ställen i applikationen (t.ex en kalender-pop-up) skapar jag inte testfall som verifierar alla dessa ställen som kalendern används, utan kollar om det inte är så att vi kan bygga om kodstrukturen och skapa en global kalendermetod som erbjuder denna funktionalitet på ett enhetligt och korrekt sätt, detta allt i enlighet av att försöka undvika fel, inte hitta dem. På det sättet kan jag testa kalenderfunktionaliteten endast på ett enda ställe i systemet och känna mig trygg med att den fungerar precis likadant i resten av systemet.
Men ja, det är många organisationer som satsat tid och pengar på att angripa problemet genom att lägga till flera testfall, flera testare, flera automatiserade systemtester. Ofta till väldigt liten vinst.
Lite för enkelt och vinklat kan jag tycka. Jag har i första hand två invändningar. Hur skall man sätta skalan rätt för allvarliga fel ? Allvarliga fel räknas oftast i pengar eller tom människoliv, hur skall skalan se ut för att få plats, hur värderar man felytan av ett kosmetiskt fel i 20 dagar relativt alla lösenord ute på nätet/alla kunder kan handla gratis ?
Den andra tankevurpan är att alla fel upptäcks snabbt eller att de bara verkar räknas från det de upptäcks/rapporteras in. Fel som aldrig/sent upptäckts kan kosta otroligt mycket…
Visst uppstår nya frågetecken. Hur poängsätts allvarligheten i ett fel? Vilken tidsskala ska användas? Timmar, dagar eller veckor? Valen påverkar uppenbart felytan… Det enda svaret måste ju bli: Det beror på. Vad är lämpligt för denna applikation? Är poängskalan olika för olika riskområden? (Skala i illustrationen är tagen fritt ur luften och döljer inga djupare funderingar.)
Vad gäller tidsperspektivet är det enligt min mening endast meningsfullt om man räknar med felets hela livslängd, dvs. från och med den dagen det introducerades (och inte från det tillfälle då det upptäcktes) tills dess att det är löst.
Med denna definition så betyder det att om felet upptäcks sent blir felytan naturligtvis stor.
Men poängen kvarstår tycker jag, en tung testprocess som inkluderar tunga scriptade tester är troligtvis inte svaret på problemet (dvs. att reducera mängden fel och den potentiella kostnaden/skadan felen medför). Parprogrammering, TDD och defensiv programmering är alla tekniker för att förhindra att felen kommer in i koden över huvud taget. För att täcka upp luckorna och fånga upp fel som trots allt smyger sig in tycker jag Exploratory Testing är den bästa approachen. Session Based Testing är t.ex. en väldigt lättrörlig process som dessutom sätter den kreative och kritiske testaren i förarsätet.
Tills sist måste jag lite retsamt fråga: Om ett fel aldrig upptäcks kan det vara så att funktionen inte används… 😉
Kul att talet väckte intresse och intressant att se vilka poänger någon annan tar med sig från det. Först vill jag säga att jag sett felyta i första hand som en tankemodell i syfte att sätta fokus på det som oftast glöms bort då vi säkrar vår kvalité: hur fort vi lagar något som är trasigt har också betydelse.
Felyta är dock inte helt taget ur luften. Det är tydligen inte helt ovanligt att reglersystem använder fel x tid som input. Och på något sätt försöker vi ju reglera fram bra kvalité empiriskt med tex Scrum.
Det är lätt att göra tolkningen att vi pratar om att reagera istället för att verifiera. Det som är mer intressant är att hitta rätt balans mellan verifiering och reaktionssnabbhet (och ingen har sagt att det är lätt eller att det finns en formel som alltid funkar). Också att kunna reagera på den feedback man får från sin verifiering. Viss verifiering kanske vi gör mer för processens skull än för att vi erfarenhetsmässigt tror att den kommer att upptäcka några fel vi inte redan eliminerat på andra sätt. I så fall kan verifieringen som Jimmy skriver vara direkt skadlig (den nytta vi utvecklat kom användarna till gagn senare och om vi hade några felrättningar så innebar de att felen rättades senare en de skulle behövt rättas).
Ett företag jag hört talas om gjorde automatiska tillbakarullningar om försöljningen på deras sajt gick ner efter en release. Där mäter de på pengar in vilket är värdet de vill skapa och avgör empiriskt om senaste releasen var bra eller dålig.
Som någon sade så är det väldigt svårt att sätta siffror på allvarlighetsgrad. Allvarlighetsgrad är med allra största sannolikhet en flerdimensionell axel (som så mycket annat inom mjukvaruutveckling). Oavsett det så tycker jag att det är värt att ställa sig frågan om vi organiserat oss på bästa sätt för att reagera. Tiden är fortfarande betydelsefull oavset om vi kan värdera allvarlighetsgrad korrekt eller inte.
Som Jimmy är inne på så är väldigt mycket av det som ökar reaktionsförmågan relaterat till att höja kvalitén från det som utvecklas. Har man som utvecklare inställningen att ”test suger för de hittade inte alla allvarliga fel innan produktionssättning” så kommer man antagligen inte att att kunna bidra så possitivt till reaktionssnabbheten.
Det är också viktigt att förtydliga att vi pratar om FAKTISK felyta och inte bara KÄND felyta och där har vi paradoxen, hur vet man hur stor ytan är utan att titta? Tyvärr är det svårt att sätta hårda siffror på sånt här utan det kan få bli lite magkänsla vägledd av en tankemodell: Felyta.
Det som dessutom kan vara värt att poängtera är att om vi produktionssätter kod med alttför dålig kvalitet kommer vårt team med utvecklare vara fullt upptagna med att rätta buggar, och rättningarna kan till och med ta så lång tid att nyutveckling, funktioner som beställaren hade hoppats och sett fram emot mycket, blir försenade. Buggrättningarna kan dessutom bli försenate eftersom en utvecklare bara kan rätta en bugg åt gången.
Om däremot inte ett enda fel dyker upp i produktion ska vi kanske fundera på om vi har blivit alltför defensiva i våra kvalitetsmål, eller kan det vara så som du säger Jimmy, är det ingen som använder funktionerna? Eller ännu värre, är det ingen som kan använda funktionerna pga monstruösa buggar i produktion?
Visst är det så, precis som du skriver Fredrik, att teamet måste arbeta med att ha en process som ser till att man bygger in kvalité och aktivt förhindrar att fel uppstår över huvud taget med olika tekniker och verktyg, samt testar funktionalitet på lämpligt sätt innan den skeppas. Annars riskerar man uppenbart att hamna i den situationen du beskriver.
Men du touchar en annan verkligen intressant tanke.
Att uppnå 100% buggfria leveranser kanske inte är något vi ens vill uppnå eftersom vi då troligtvis plöjt ner enorma mängder energi, tid och pengar på en rigorös och defensiv process ackampanjerad av en tung, heltäckande och djup testning. Vi har troligtvis för länge sedan passerat ROI i våra ansträngningar… Att emellanåt ha enstaka buggar inrapporterade kanske är ett sundhetstecken på två saker:
1) Vi lägger ”lagom” mycket energi på test och kvalitet.
2) Funktionerna används.
Här är en presentation som visar det jag fikar efter lite (vad gäller reaktionssnabbhet) en kul liten del i presentationen är ”no QA-team”. Kontroversiellt kanske… men utveckling till release på 5-10 minuter och produktionssättning ett dussintal gånger om dagen gör att man får tänka lite annorlunda. Rätt mycket jag filosoferat om på senare år är implementerat som helhet här (dock utan att jag kan ta någon som helst cred för det. Dessutom finns det även gott om saker jag inte ännu filosoferat om :)). Men det ligger lite i tiden att tänka såhär om man erbjuder tjänster och inte säljer uppgraderingar av program: http://www.eishay.com/2010/07/continuous-deployment-at-kaching.html