Den kolde, hårde sandhed om software uden fejl

For mange år siden, den dag vi besluttede at udgive en større opgradering af vores produkt, en beslutning der naturligvis krævede min godkendelse som QA-direktør, gik jeg ned ad gangen, og den administrerende direktør passerede mig. 

Han stoppede mig og sagde: “Så jeg kan gå ud fra, at vi udgiver uden fejl?”

Uden at tænke så meget over det, som jeg nok burde have gjort, svarede jeg nonchalant: “Selvfølgelig ikke. Der findes ikke software uden fejl.” 

Han var chokeret og forfærdet over mit svar. Han blev så vred på mig, at han afsluttede vores samtale og stormede ned ad gangen.

Dengang tilskrev jeg det, at han var ny i softwarebranchen og ikke kendte til softwarelivscyklusser, da han kom fra forlagsbranchen (lang historie—en anden gang). Alle på udviklingsteamet vidste nemlig, at vi udgav med fejl. Men vi vidste fra begyndelsen, hvilke fejl der var tale om, og det gjorde hele forskellen i vores risikovurdering.

Jeg bemærker dog med bekymring, at denne misforståelse hos min tidligere administrerende direktør på det seneste er blevet udbredt i vores branche. Fejlfri, “software uden fejl” er et nyt praleri/mantra, som jeg ser og hører mere og mere. Og ikke kun fra uvidende administrerende direktører (jeg ved godt, at det er overflødigt sagt), men også fra folk i branchen, der burde vide bedre. Og som faktisk gør det. Det finder jeg meget foruroligende.

Der er en måde, hvorpå tankegangen om “ingen fejl” ikke blot er løgnagtigt, selvcentreret nonsens. I Vesten er det for det meste bare varm luft og poseren for syns skyld. Men i Japan er det faktisk meningsfuldt. Og det gælder i alle deres brancher. 

Jeg arbejdede i Japan i et år, og det slog benene væk under mig, men på en meget positiv måde. For deres definition af en “fejl” er meget anderledes end vores. Hvis der for eksempel ligger et tyggegummipapir på gulvet i fabrikken, betragtes det som en fejl, på samme måde som et problem med maskineriet eller resultatet af en proces. Hvis vi virkelig tog “ingen fejl” alvorligt, ville vi se på det problem på samme måde som japanerne. Men det gør vi ikke, så det kommer vi heller ikke til.

Det, jeg forsøgte at sige til den stakkels administrerende direktør, måske lidt for direkte, er, at ethvert stykke moderne kommerciel software er uendeligt komplekst, og at de måder, det kan interagere med sig selv eller sine omgivelser på, derfor også er uendelige. Det er kun muligt at finde enhver fejl, hvis man har uendelig tid til at teste. Men ingen af os er udødelige.

Selv hvis du kunne finde hver eneste fejl første gang, ville du ikke have tid til at rette dem alle og udgive et produkt i dette århundrede—tid til markedet er en reel faktor. Så selv hvis fejlene bliver fundet, er du nødt til at udgive med dem. 

Så hele forestillingen om “software uden fejl” er grundlæggende selvbedrag fra starten.

Hvor stammer forestillingen om software uden fejl fra?

Grundlaget for dette selvbedrag er, at QA's rolle er at “sikre” kvalitet. Det gør QA ikke. Det er produktledelsens og ingeniørafdelingens opgave. Rollen for kvalitetssikring er at *vurdere*, hvor succesfulde de har været med det.

Men der er endnu et skadeligt lag i dette problem. 

For nylig diskuterede jeg netop dette problem med en softwareudvikler. Han påpegede over for mig, at den måde, betydningen af “software uden fejl” var blevet forklaret for ham på, var det, jeg lige har beskrevet ovenfor. Det betyder, at man udgiver med alle de fejl rettet, som teamet besluttede var nødvendige at rette for at kunne udgive. Og derefter udgiver man med alle de fejl, som teamet besluttede ikke at rette. En definition, som min samtalepartner i øvrigt ikke var enig i.

Det er tydeligvis blot definitionsmæssig røgsløring og illusioner. Du udgiver faktisk med fejl, og du ved, at du gør det, men du bruger sloganet “ingen fejl” til at skjule dette faktum for jer selv—og naturligvis for ledelsen. Som vi alle ved, let lader sig hypnotisere af tomme slogans, der får dem til at føle sig succesfulde.

Det er selektiv reduktion af fejl, ikke mere end det.

Hvordan slipper vi væk fra bedraget om software uden fejl?

Og grundlaget for dette bedrag er selve sproget, et sprog, der former og binder vores tænkning, før vi overhovedet kan begynde at forholde os begrebsmæssigt til det, der bliver sagt. Det er dette falske sprog, der fra begyndelsen skaber situationen, hvor vi er nødt til at forklare, hvorfor det er forkert. Og dermed bliver vi gradvist trængt op i en krog af et slogans ordforråd.

Dette er så almindelig en praksis inden for softwareudvikling. Desværre er det ikke begrænset til, at vi lyver over for os selv om “ingen fejl”. Det inficerer alle niveauer af vores tænkning og handling som testere, i vores udviklingsproces, i vores metoder og i vores målinger.

Lad os begynde at se virkeligheden i øjnene omkring det, vi gør, og det, vi ikke gør. Og det første skridt i den bedring er at bruge et sprog, der ærligt beskriver, hvad vi gør, og hvad vi ikke gør. For hvis selve det sprog, vi bruger til at kommunikere disse realiteter, grundlæggende er bedragerisk, uærligt og selvbedragende, udvikler vi ikke software af høj kvalitet. Vi fremstiller propaganda. 

Det andet problem med diskursen om “software uden defekter” er, at selv hvis dette er et oprigtigt mål – i den forstand at folk oprigtigt tror, det er muligt, og ikke blot er en kynisk øvelse – er der et andet og mere alvorligt problem, som begrænser nyttigheden af denne idé. Problemet er dette: 

Hvordan skulle du overhovedet kunne vide og bevise, at du har fundet “alle” de defekter, der findes i den software, der testes? Og ikke blot det antal defekter, du har formået at finde inden for den afsatte tid? Hvordan skulle du kunne bevise over for jer selv, at det sæt af fejl, I har fundet, er det komplette sæt af fejl, som softwaren faktisk indeholder? 

Det kan du ikke. For det ville kræve en proces uden for selve QA, der kunne fastslå dette. Ellers er det blot et cirkulært argument. Og hvad skulle denne eksterne proces være? 

Og det er sandt, uanset hvor mange fejl I allerede har fundet. I kunne have fundet en million af dem. Det beviser ikke, at der ikke lurer fejl nummer en million og én derude i softwarets skygger.

Er der noget værdifuldt ved konceptet om nul defekter?

De åbenlyse logiske og erkendelsesteoretiske problemer ved at tale og tænke i termer af “software uden defekter” er ganske enkelt uoverstigelige. Selve betegnelsen kan ikke reddes, uanset hvordan vi omformulerer den. 

Men hvis vi ser forbi det vildledende slogan og på det, der fra begyndelsen gør det attraktivt og begrebsmæssigt gyldigt for ellers tænkende mennesker, vil vi finde noget værdifuldt at fokusere på.

Dette “noget” er et andet spørgsmål, men et spørgsmål, der imødekommer de praktiske og følelsesmæssige behov, som den falske diskurs om software uden defekter tilsyneladende adresserer – og på en mere sammenhængende og forsvarlig måde.

Det problem, som folk inden for software i virkeligheden forsøger at forholde sig til her ved at ty til selvbedrag, er i sig selv bedragerisk enkelt. Nemlig: “Hvornår ved vi, at vi kan stoppe med at teste?” 

Det er det eneste spørgsmål, jeg nogensinde stiller kandidater til QA-lederstillinger i min organisation. For i virkeligheden er det det eneste spørgsmål, QA skal besvare. Og hvis QA ikke kan det, er QA spild af tid. For at besvare det spørgsmål må vi først besvare et forudgående spørgsmål. 

Nul defekter kontra 100 % testdækning

Hvordan ved vi, om de defekter, vi allerede har fundet – uanset hvor mange de måtte være – på plausibel vis kan accepteres som repræsentative for den risikoramme, der er skabt af den måde, den software, der testes, blev specificeret og udviklet på? Så vi med tillid kan sige, at de resterende uopdagede defekter udgør en acceptabel risiko ved en beslutning om at frigive softwaren til offentligheden?

Stillet på denne måde kan vi se, at dette spørgsmål ikke er et spørgsmål om defekter overhovedet. Det er et spørgsmål om testdækning. Jeres analyse af fundne fejl, uanset hvor stort antallet er, betyder ingenting, hvis den ikke kan sammenholdes med og vurderes op imod en analytisk forståelse af den testdækning, som QA-indsatsen har opnået til dato, sammenholdt med den dækning, der endnu ikke er opnået. 

For hvis dette sæt af kendte defekter, uanset hvor meget tid der er brugt på test, kun repræsenterer 30 % faktisk testdækning – og det ved I ikke – så har I intet rationelt grundlag for at vide, hvad de betyder for en beslutning om at udgive softwaren.

Den egentlige diskussion om og det egentlige mål for virkelig effektive QA-indsatser kan ikke handle om “nul defekter”, men snarere om “100 % testdækning”. Af den grund, jeg angiver ovenfor. 

Den store fordel ved denne måde at tænke på softwarekvalitet er, at den bygger på en definition af tilstrækkelig testdækning, som QA selv fastlægger før testen. Derfor kan selve definitionen testes op imod specifikationer, krav, tidligere kundeproblemer og kundebehov osv. og ændres efter behov.

Fremadrettet: Testdækning uden huller

At tænke på dette problem i termer af defekter mislykkes netop, fordi det ikke er noget, der meningsfuldt kan defineres på forhånd, eftersom antallet og alvoren af problemerne først kan opdages efter testen. 

Derudover vurderes det ikke op imod en eksisterende (meningsfuld) definition af, hvad grænsen for “nul” faktisk kunne betyde. Det er spild af tid at definere succes ud fra en variabel, der selv er udefineret og ikke kan defineres.

Derfor er den eneste måde at redde idéen om software uden defekter på at lede denne tænkning og planlægning hen imod testdækning uden huller. Motivationen bag mantraet om nul defekter er ikke forkert i sig selv. Den er blot blevet rettet mod det forkerte mål i stedet for det egentlige. Foretag denne justering, og meningsfulde, målbare definitioner af acceptabel softwarekvalitet bliver mulige.

Hvis du er klar til at lære mere og alligevel lære af eksperter og administrerende direktører, er her en podcast, som vi tror, du vil kunne lide: TEAMARBEJDE, AI OG KONTAINERISERING (MED NASAS MICHAEL RITCHSON)

Relateret læsning: DE 10 BEDSTE VÆRKTØJER TIL FEJLSPORING I SOFTWARETEST