Myt #5: Test måste ske oberoende av utveckling

En fråga som delar test-sverige och rör upp känslor på testkonferenser är huruvida test bör vara en separat, oberoende och objektiv aktivitet, skild från utvecklingen – eller ej. Vissa hävdar att test måste ske självständigt och rigoröst för att uppnå hög kvalitet. Men stämmer det verkligen att testarnas objektiva kritiska granskande påverkas om test och utveckling sker tillsammans?

Vad menar vi med ”oberoende”?

Med oberoende aktivitet syftar vi på att test utförs som en parallell och sekventiell aktivitet i förhållande till utveckling (eller själva programmeringen). Den utförs av någon annan än den person som skrivit koden, lämpligtvis någon som har test som specialistkunskap (så kallad testare). Praktiserar vi oberoende testning tar utveckling och test avstamp i samma kunskap, d v s de definierade kraven, men utförs sedan parallellt och påverkar inte varandra. Testarna genomför sina aktiviteter med kraven som utgångspunkt.

Ursprung 

Vi tror att denna myt har sitt ursprung i tradition. Man kan hävda att redan Bibeln var inne på oberoende testning: ”Varför ser du flisan i din broders öga men märker inte bjälken i ditt eget öga?” (Matt 7:1-5)

En modernare förklaring skulle kunna ges av creator’s bias, som är oförmågan att som skapare kunna se bortom sina antaganden och anamma kundens eller någon annans synvinkel. I produktutveckling slår denna bias på produktens anpassning till målgruppen och dess önskemål. I mjukvaruutveckling uttrycker den sig i utvecklarens oförmåga att kritisera sin egen kod och tänka utanför de ordinarie banor som är grunden i ett användnings- eller testscenario.

I boken ”The Psychology of Computer Programming”, av Jerry Weinberg, kopplas kognitiv dissonans och utveckling ihop: En programmerare ser sitt program som förlängningen av sig själv. I det fall att programmet är felaktigt kommer utvecklaren känna sig otillräcklig som person, vilket leder till dissonans. Utvecklaren reducerar dissonansen genom att försöka bevisa för sig själv att koden är korrekt, fastän den kan vara full av uppenbara fel.

Historiskt sett har testare utbildats i vad vi idag kan kalla den traditionella skolan, där aktiviteten test till största del syftar till att kritisera och verifiera ett systems eller en produkts kvalitet. Testare har tillkommit i utvecklingsprocessen på grund av hypotesen att det är svårt för utvecklare att kritisera sin egen kod. Detta beskrivs i ISTQB:s Foundation Syllabus i stycket ”The Psychology of Testing”, där fördelar med oberoende testning och olika mindsets, testarens/utvecklarens och diskuteras: Utvecklarnas huvudsakliga uppgift är att skapa, medan testarens är att vara kritisk, nyfiken, hitta sprickor och “ha sönder saker”. Traditionell testning betonar vikten av att verifiera att det som har utvecklats stämmer med det som står skrivet i kraven, som om utvecklare har svårt att tolka krav eller se till helheten. Detta har skapat en form av “vi och dem”-mentalitet mellan test och utveckling.

Resonemang

Det är svårt att argumentera mot att den som skapar någonting inte blir delvis subjektiv kring sin skapelse. Detta händer till en viss grad när utvecklare skriver kod. Det finns dock metoder som man kan använda sig av för att inte hamna i skaparens bias eller utsättas för kognitiv dissonans. Redan medvetenheten om dessa fenomen och insikten att man utsätts för dem utgör visst försvar. Parprogrammering och granskning (reviews) ett annat. Om man dessutom faktiskt låter testarna samarbeta med programmerarna under utvecklingen, åstadkommer man den externa granskning som verkar behövas.

Motsatsen till detta, den oberoende testningen, medför stora kostnader.

Om testning sker oberoende, och dessutom i en egen fas, ökar time to market. Om det inte skulle råka vara viktigt, kan man aldrig ducka för att den totala kostnaden ökar p g a ökad byråkrati, fler överlämningar och långsammare feedback. De fel som hittas kommer rapporteras sent, när de som skrev den felaktiga koden glömt den och börjat på något annat. Tidsförlusten i sig är en ringa kostnad i förhållande till det man går miste om i lärande och långsiktiga förbättringar.

Det är inget krav, men den oberoende testningen brukar åtföljas av bristfällig kommunikation. Istället för att prata med varandra, riskerar utvecklare och testare att kommunicera genom ett bugghanteringssystem, vilket inte bara medför merarbete med inmatning och en ineffektiv kommunikationskanal, utan bidrar också negativt till lärandet. Extremfallet är testning som utförs av någon annan i något annat land. Visst blir den oberoende, men den medför också administrativ overhead, och riskerar att inte resultera i större förändringar hos utvecklingsorganisationen än att de hittade buggarna rättas.

Vidare finns det inget som säger att testare blir dumma av att jobba i ett utvecklingsteam. Varför skulle de förlora sina kunskaper, sitt hantverk och sin förmåga att granska och inhämta information bara för att de arbetar med människor som skriver kod? Amplifiera nu detta med möjligheten att kunna erbjuda omedelbar feedback till alla inblandade, kunna gå till botten med systematiska problem sprungna ur dålig kravbild eller utveckling, samt lära samtliga i teamet hur fel uppstår, hur de kan hittas och hur de kan undvikas.

Eller låt oss se det så här: Vi har ett team bestående av tre utvecklare och tre testare. Hur använder vi deras tid bäst? Genom att låta dem samarbeta från dag ett, prata ihop sig tidigt och reda ut oklarheter i krav och implementation och verifiera det färdiga resultatet tillsammans? Eller, genom att låta utvecklarna sitta på sin kammare och knåpa ihop något, som sedan blir verifierat i efterhand?

Antalet exempel på tvärfunktionella team (i vilka testare ingår i teamet och som jobbar tillsammans med utvecklare) ökar stadigt. Ökar gör även antalet exempel på team som själva levererar rakt till produktion (utan testning utanför teamet). Det står uppenbart att test inte måste vara en oberoende aktivitet.

Alltså

Oberoende testning tar tid och resulterar i begränsat lärande, vilket leder till att kvaliteten även på sikt endast förbättras marginellt. Den medför administration och resulterar lätt i att utvecklare och testare leker viskleken och kommunicerar ineffektivt. Å andra sidan är den helt oberoende och kan hitta fel som såväl utvecklare som utvecklare och testare som arbetar i team kan missa p g a tunnelseende och bias.

Så, givet oändlig tid och oändliga resurser utgör den ett starkt komplement till testning som utförs av ett tvärfunktionellt team. Tyvärr har vi aldrig oändligt med vare sig tid eller resurser och därför måste vi välja det tillvägagångssätt och den strategi som ger mest värde.

Vi ser inget annat alternativ än att döma denna myt till…