Som nybörjare i test får man höra det betryggande rådet att ingen testare kommer att hitta alla fel – vilket är helt korrekt. Det gör att man som testare måste fokusera på kvalitet av buggar, snarare än kvantitet. Det finns dock alltid en liten naivitet hos novisen att buggen man hittar är av ett oproportionerligt stort värde. Därmed blir en naturlig reaktion hos den nya testaren att hastigt bli lycklig efter att ha identifierat en svaghet i systemet. I extasen av att skärmen skriker ERROR tar juniortestaren flitigt fram sitt testverktyg och dokumenterar buggen med reproducerande steg…
Det finns inget fel med att bli glad över att hitta en bugg, så länge det inte förblindar testaren från det riktiga målet – stödja utvecklarna att förbättra systemet. I scenariot från föregående stycke håller testaren på att begå misstaget att förhastat skriva ned ett oväntat beteende som en bugg. Med en dos bekräftelsebias antas det att buggen är av värde och att handlingarna som gjordes är anledningarna bakom buggen. Detta kommer att resultera i en oavsiktligt missvisande bugg till utvecklarna.
För att förhindra mig själv att begå detta misstag har jag tagit fram Den förmätna heuristiken (eng. The Presumptuous Heuristic): var skeptisk mot första antagandet av en bugg, gå tillbaka och identifiera brytpunkten för det oväntade beteendet i rätt kontext.
Oväntade beteenden är en avvikande konsekvens från den avsedda handlingen, därmed är det oväntade beteendet bara en bugg i bemärkelsen att den inte förväntades. Det är därför felaktigt att direkt anta att buggen är ett fel från ett systemperspektiv. Det oväntade beteendet hindrade möjligtvis ett felaktigt beteende. Ta till exempel en generisk e-handel. Det ska inte gå att ta sig vidare från varukorgen till betalning innan några varor är tillagda; men för juniortestaren som ivrigt vill verifiera att köpprocessen är korrekt kan enkelt missuppfatta detta. Så istället för att inse att ”Next”-knappen är avsiktligt inaktiverad, uppstår ett tunnelseende på att ett oväntat beteende måste vara en bugg. Ett banalt exempel får jag medge, men poängen framgår – det är essentiellt att identifiera den faktiska anledningen varför ett oväntat beteende uppstod, inte bara en anledning.
Det är centralt för en testare att få full förståelse varför ett särskilt fenomen har uppstått i systemet, och att ovedersägligt motivera varför detta är ett potentiellt fel. Testresultat ska precis som vetenskap styrkas av empiri, inte åsikter. Så istället för att utvecklarna får en bugg där de reproducerande stegen är totalt vilseledande då buggen upptäcktes i fel kontext, kommer de enkelt att kunna återskapa och lösa problemet.
Som alla heuristiker är detta inget annat än en tumregel som testare kan ta med sig för att undvika att förmätet anta att ett oväntat beteende är en faktisk bugg. Missta mig inte, det finns utan tvekan fall där den initiala upptäckten är helt korrekt, dock har jag upplevt denna förhastade ”Yes, jag hittade en bugg!” tillräckligt många gånger för att anse att du borde ta hänsyn till detta också. Det finns inget roligare än att hitta buggar, men kom ihåg: den oerfarne stöter på buggar, den erfarne identifierar buggar.
