För några år sedan var jag testledare i ett uppdrag/projekt där nya releaser släpptes till ett driftsatt system en till två gånger per år. Efter några år bestämde vi oss för att använda oss av så kallade skenfel under ett par releaser. Det innebar att utvecklarna avsiktligt lade in typiska fel i systemet. Dessa kunde sedan användas för att löpande under testperioderna uppmärksamma testtäckningen. Om inga skenfel hittats i ett visst område gav det en indikation på att testtäckningen troligtvis var bristfällig för det området. Ett annat användningsområde var att skenfelen gav en fingervisning om vilka kategorier av tester som behövde köras ytterligare.
Nedan visas ett exempel på skenfel uppdelade i fyra kategorier.
Informationen om antalet funna skenfel gav oss också en indikation på hur många fel som kunde tänkas finnas kvar i systemet.
Det krävdes en hel del planerande för att få det att fungera. Exempelvis var det utvecklingsledaren som ansvarade för inläggning av skenfel, löpande rapportering om funna skenfel samt borttagning av skenfel. Ett dokument skapades som beskrev hur skenfel skulle läggas in, kategoriseras och kommenteras i koden. Skenfel planterades endast i ny och förändrad kod. Skenfel skulle motsvara cirka 10-15 procent av totala antalet fel som brukade rapporteras på liknande områden eller områden med motsvarande storlek och komplexitet. Som referens fanns en befintlig feldatabas med över 9 000 felrapporter. Totalt brukade det bli ett 60-tal skenfel på ny och förändrad kod per release och vi uppskattade arbetsinsatsen till en mandag per utvecklare och release.
Varken testledaren eller testarna fick under releaserna reda på vilka skenfel som lagts in eller hur många. Löpande under testperioderna rapporterade utvecklingsledaren hur många procent av skenfelen som hittats, fördelat per kategori. Utöver att skenfelen användes som ett verktyg för att uppskatta testtäckningen och för att uppskatta hur många fel som kunde tänkas finnas kvar, användes skenfelen som en motivationshöjare för testarna. Inga planterade fel skulle minsann släppas över bron!
Fyra månader efter driftsättningarna genomfördes en uppföljning för att se hur väl resultatet med skenfelen stämde överens med verkligheten. Just tidsperioden fyra månader valdes för att vid den tidpunkten brukade antalet fel som rapporterades på releasen, både från test och från produktion, närma sig noll. Resultatet brukade förvånande väl stämma överens med prognosen. I en release hade 76 procent av skenfelen hittats innan de togs bort ur systemet. När systemet driftsattes hade totalt 1 540 fel rapporterats. Enligt skenfelen skulle det innebära att det fanns 486 fel kvar. En uppföljning fyra månader senare visade att 507 fel hade rapporterats efter driftsättning.
Skenfel passar nog inte i alla projekt men för oss var det intressant, givande och motiverande att prova på det här med skenfel. Vi var ett väl intrimmat gäng, vi arbetade i ett system som vi behärskade och vi hade en gedigen feldatabas att hämta erfarenheter från. Den extra arbetsinsatsen som krävdes kompenserades med höjd motivation. Sitter du i en liknande situation och känner att du vill prova något nytt så kan kanske skenfel vara något att prova på.
PS! I min och Mikael Ölunds bok Testledning – Inspirerande testerfarenheter, finns mer information om hur användandet gick till. DS
Mycket intressant. Jag har själv aldrig använt den här metoden. Finns det några risker enligt dig att t.ex. skenfelens implementation kan få bieffekter som man kanske inte hinner hitta efter att de har tagits bort (och man inte hinner köra en täckande regressionsrunda)?
Metoden kan ju också användas om utvecklingsavdelningen vill “mäta” hur duktiga testarna är att täcka de områden som är på förhand viktiga.
Jag kan t.ex. tänka mig att använda mig metoden när man “sourcar” ut testning för att få en bild över hur bra täckningen är.
En mycket ranglig bro att ge sig ut på tycker jag. Teorin är ju bra men det måste väl krävas en hel del planering av de inbyggda buggarna för att de ska täcka alla okända buggar?
507 fel efter fyra månader. Man undrar ju vad det innebär efter 1 år i produktion..
Jag har använt mig av skenfels tekniken vid ett tillfälle. Det var när vi hade ett förvaltningsläge på ett batchsystem. Anledningen till att vi provade att implementera skenfel var att jag var mycket osäker på hur effektiva regretionstesterna egentligen var. Vi hittade helt enkelt väldigt lite fel med hjälp av våra tesfall.
När vi provade att föra in skenfel i en release så fick vi bekräftat att våra regretionstester täckte de vanligaste flödena mycket bra. Men vi upptäckte samtidigt att vi hittade väldigt få fel som låg utanför de vanligaste flödena Det berode till stor del på att det var för svårt att fritesta och vara spontan. Denna upptäckt ledde till att vi automatiserade våra regretionstestfall, då vi nu visste att de hittade fel. Det ledde också till att vi tog ett stort grepp på testmiljöer och testdata för att underlätta och uppmuntra fritestning.
Så lång som att vi skulle kunna använda statistiken från skenfelen till att beräkna återstående antal fel det kom vi aldrig, då vi inte lag tillräckligt mycket energi på strategin vid implementerandet av skenbuggarna för att datat skulle bli rättvisande.
Jag har aldrig använt planterade fel, och kommer nog aldrig att göra det heller. För man kommer nog aldrig ha så gott om tid över att man hinner skapa felen, testa, rapportera dem, ta bort dem, testa om efter att de avsiktliga felen tagits bort, och säkert ytterligare merarbete runtomkring.
En intressant fråga är hur många av de 507 kundbuggarna som hittats och fixats om man inte behövt spendera tid på skenfelen…
Huvudsyftena känns lite missriktade också:
* borde inte testgruppen känna sig ännu mer motiverade av att hitta de “riktiga” felen?
* borde inte testarna ihop med utvecklarna kunna bedöma testtäckningen på andra, bättre sätt än med skenfel?
* varför så mycket fokus på att uppskatta hur många fel som finns kvar?
Det känns ju inte som att det hjälper kunderna speciellt mycket att kunna säga “åh vad bra, nu har det kommit in 500 kundproblem, precis vad vi förväntade oss!”
Nej, jag tror nog skenfel är bäst i teorin, i exempel där man vet allt om produkten, och har en ofelbar kategorisering av olika sorters buggar, all tid i världen, och inte behöver bry sig alltför mycket om hur bra produkten är för kunden…
Jonas: Intressant att höra att du också har använt skenfel. Det verkar också som att de fyllde sitt syfte.
Rikard: Bra frågeställningar och funderingar, de visar också att jag inte var tillräckligt tydlig. Som erfaren testledare använder man sig naturligtvis av flera olika metoder för att till exempel bedöma vilken testtäckning man har. I mitt exempel ovan hade vi efter flera releaser stagnerat något, vi kände att vi behövde hitta nya sätt för att i realtid kunna mäta vår testtäckning. Skenfel var just ett nytt, spännande och, som det visade sig, ett effektivt sätt. Och åter igen, den största vinsten var att det ökade motivationen bland testarna. En annan positiv effekt var att även personer utanför testteamet, exempelvis styrgruppsmedlemmar, blev nyfikna på testresultaten. Att sedan använda resultatet för att uppskatta hur många fel som kunde tänkas finnas kvar i systemet, det var bara en bonus, det gav inte speciellt mycket mervärde just då.
Summa summarum. Använd flera olika metoder och var inte rädd att tänka utanför boxen. Och kanske viktigaste ut av allt; glöm aldrig bort att motivera ditt testteam, ambition slår alltid klass!
Tack för förtydligandena, nu förstår jag mer, och som en metod av många, och som ett sätt att väcka liv i testningen verkar det helt rimligt.
Håller helt med om att ambition slår klass, men jag tror det är oerhört svårt att motivera andra (men man kan hjälpa dem att motivera sig själva); snarare är ett av testledare/chefers viktigaste uppdrag att inte de-motivera (vilket är nog så svårt!)
Jag har väldigt svårt att se en faktisk nytta med att använda sig av skenfel.
I mina ögon framstår detta mer som en liten lek som man skulle kunna roa sig med på fritiden än en seriös metod.
Lite som att gömma godispåsen på barnkalas.
Det är roligt att du såg att ni uppnådde positiv effekt när ni gjorde detta. Måste dock säga att det förvånar mig att det ökade motivationen och upplevdes som positivt bland testarna. Tänker mest på hur jag själv skulle reagerat. Jag skulle bli jäkligt förbannad om jag fick reda på att någon med flit lagt in fel i mjukvaran för att på det sättet bedöma min testning. Inte nog med att jag hade känt att det var respektlöst hanterande av min tid det hade också känts som att man inte litade på mitt sätt att utföra mitt jobb (som att någon annan vet bättre och att man försöker sätta dit mig) . Resultatet skulle sedan av okunniga personer enkelt kunna användas mot mig.
Jag tycker det är bra att du i din kommentar understryker att värdet av era beräkningar för att uppskatta hur många fel som finns kvar efter release var minimalt.
Hela den uträkningen är full av antaganden och gissningar som är väldigt svåra att styrka. Så att rapportera detta till någon av våra intressenter är som att ta en siffra ur luften och inget jag hoppas någon gör.
Ett grundproblem som gäller för ovan men även för totala resonemanget av skenfel är att man förutsätter att de fel som en person medvetet lägger in i koden representerar de fel som faktiskt finns i koden. I detta fallet så tror jag tyvärr inte på att det är så enkelt att det bara är att gå tillbaka och titta på gamla felrapporter.
När man ägnar sig åt trovärdig statistik så är ett av de absoluta grundkriterierna att det urval man bygger sina beräkningar på faktiskt representerar den totala populationen ur de aspekter som kan tänkas påverka resultatet. Detta är ofta väldigt komplext och kräver stor noggrannhet för att uppnå och det är således viktigt att men kan styrka detta samband. Det är avsaknandet av detta som gör tex aftonbladets nätundersökningar totalt värdelösa och högst tvivelaktiga. Det är också en av de främsta anledningarna till att de siffror som är vanligt förekommande i vår bransch även faller ihop.
Om det vore så att de fel som en utvecklare lägger in medvetet skulle avspegla fördelningen och mönstret av det totala antalet fel i mjukvaran. Varför rättar då inte utvecklaren alla sina fel, han vet ju hur de ser ut och var de ska ligga.
En annan aspekt är frånkopplingen till teststrategin, var vår avsikt att faktiskt fånga upp alla de felen som lades in? Avspeglar typen av buggar och balansen mellan olika typer av fel vår teststrategi? Om vi funderar lite på det, vilka slutsatser kan vi egentligen trovärdigt dra av vilka skenfel man hittar eller ej?
Men som sagt som en liten lek en tråkig lördagskväll kan det säkert funka (för vissa)!
Underbart med åsikter, så väl medhåll som mothugg. Det är precis det som det här forumet handlar om för mig, en möjlighet att få vända och vrida på testrelaterade frågor.
Fortsätter med förtydliganden. Vårt arbete med skenfel var ytterst seriöst. Det fanns en plan och strategi för hur det skulle gå till och alla inblandade parter var medvetna och involverade. Jag kan tycka att du Henrik krånglar till ditt resonemang, kanske för att vinna egna poänger. Men du har ju i och för sig bara teori att luta dig mot (du nämner i alla fall inte att du själv har använt skenfel).
Enkelt exempel: Lägg in skenfel så att ett par normalflöden inte fungerar, skenfel så att ett par alternativflöden inte fungerar, skenfel så att det står fel i utskriftstexter och skenfel så att några loggar inte fungerar som de ska. Om det sedan visar sig att alla skenfel är hittade bland normalflödena, bland utskrifterna och bland loggarna men inget i de alternativa flödena så kan man se det som en indikation på att man troligtvis inte har testat de alternativa flöden så mycket. Om det sedan är bra eller dåligt, det beror på vilken strategi man har. Krångligare än så behöver det inte vara. Sedan kunde vi ta ut svängarna ytterligare då vi kände till vårt system så pass bra.
Jag använder inte skenfel i alla mina uppdrag och försöker inte heller tvinga på någon den metoden. Men vid rätt omständigheter så är jag inte alls främmande för att göra det igen.
Roligt att du välkomnar andra åsikter och inte blir stött, då det inte är min mening!
Javisst du har helt rätt jag har aldrig haft något intresse av att använda mig av det. Så det är bara den teori du presenterar jag drar mina slutsatser från.
Jag betvivlar inte att ni hade ett seriöst arbetssätt. Det är metoden jag tycker passar för lek, tävlingar eller träning än att inkorperera i det dagliga arbetet. Då kan man också ha ett lättsammare förhållningssätt till utförandet.
Jag visste inte att era testare var med på att det fanns skenfel i mjukvaran. Då förstår jag varför dom inte kände sig lurade. Dock så uppkommer det då en hel del andra frågeställningar kring bias och liknande som andra redan kommenterat.
Möjligt att du tycker att jag krånglar till det men jag känner inget behov av att behandla något enkelt som inte är enkelt utan som är komplext? Jag tycker att ska man presentera statistik så ska den vara trovärdig och kunna genomgå en granskning utan att falla samman, annars är den i mina ögon inte värd mycket.
Man kan och bör absolut experimentera och prova olika sätt och metoder utan att på förhand veta om dom kommer vara representativa och värdefulla. Men när man sen som du beskriver att ni gjorde börjar presentera för utomstående personer ganska långtgående slutsattser om både testteckning (även om detta inte var ert enda mått) och utsago om hur många buggar som finns i systemet vid leverans då tycker jag verkligen att man ska ha ordning på sin källdata och kunna styrka sina estimeringar på ett korrekt sätt.
Ditt enkla exempel som du beskriver. Jo det behöver verkligen vara krångligare än så för värdet av informationen du får ut av det du beskriver kontra kostnaden att utföra detta är som att köpa en påse med luft väldigt dyrt. Det är ju bara att fråga testarna eller titta i testrapporten så bör du få ut samma information.
Jag vill inte heller tvinga dig till att inte använda dig av detta i framtiden. Det tycker jag helt är upp till dig att avgöra. Jag bara belyser ett par, ur en statistisk synvinkel, tvivelaktiga antaganden som jag anser riskerar trovärdigheten och integriteten i denna metod.