Den kalla, hårda sanningen om programvara utan defekter
För många år sedan, den dag vi beslutade att släppa en större uppgradering av vår produkt – ett beslut som naturligtvis krävde mitt godkännande som QA-chef – gick jag i korridoren när VD:n passerade mig.
Han stannade mig och sa: ”Så jag kan anta att vi levererar utan några defekter?”
Utan att tänka så mycket som jag förmodligen borde ha gjort svarade jag glatt: ”Självklart inte. Det finns inget sådant som programvara utan defekter.”
Continue Reading for Free
Create a free account to finish this article, plus get ongoing access to timely insights and practical resources.
Have an account? Log In
Han blev chockad och bestört över mitt svar. Han blev så upprörd på mig att han avslutade vårt samtal och stormade iväg längs korridoren.
Då skyllde jag detta på att han var ny i programvarubranschen och dess livscykel, eftersom han kom från förlagsbranschen (en lång historia – en annan gång). Alla i utvecklingsteamet visste nämligen att vi levererade med defekter. Men vi visste redan vilka dessa defekter var, och det gjorde hela skillnaden i vår riskbedömning.
Jag har dock med oro lagt märke till att denna missuppfattning hos min tidigare VD på senare tid har blivit utbredd i vår bransch. Felfri programvara, ”programvara utan defekter”, är ett nytt skryt/mantra som jag ser och hör allt oftare. Och inte bara från okunniga VD:ar (överflödigt, jag vet), utan från personer i branschen som borde veta bättre. Och som faktiskt gör det. Det tycker jag är mycket oroande.
Det finns en mening i vilken tänkandet kring ”noll fel” inte bara är lögnaktigt, självtjänande nonsens. I väst är det mest tomt prat och poserande för syns skull. Men i Japan är det faktiskt meningsfullt. Och inom alla deras branscher.
Jag arbetade i Japan i ett år, och detta vände upp och ner på min världsbild, men på ett mycket bra sätt. Deras definition av en ”defekt” skiljer sig nämligen mycket från vår. Om det till exempel ligger ett tuggummipapper kvar på fabriksgolvet betraktas det som en defekt, lika mycket som ett problem med maskineriet eller resultatet av en process. Om vi verkligen menade allvar med ”noll defekter” skulle vi tänka på den frågan på samma sätt som japanerna. Men det gör vi inte, så det kommer vi inte att göra.
Det jag försökte säga till den stackars VD:n, kanske lite väl rakt på sak, är att all modern kommersiell programvara är oändligt komplex, och att sätten på vilka den kan interagera med sig själv eller sin omgivning därför också är oändliga. Det är bara möjligt att hitta varje defekt om man har oändligt mycket tid att testa. Men ingen av oss är odödlig.
Även om du kunde hitta varenda defekt vid första försöket skulle du inte ha tid att åtgärda dem alla och leverera en produkt under detta århundrade – tiden till marknaden är en verklig faktor. Så även om de upptäcks måste du leverera med dem.
Så hela föreställningen om ”programvara utan defekter” är i grunden vanföreställd redan från början.
Varifrån kommer föreställningen om programvara utan defekter?
Grunden till denna vanföreställning är att QA:s roll är att ”säkerställa” kvalitet. Det gör den inte alls. Det är produktledningens och utvecklingens uppgift. Rollen för kvalitetssäkring är att *bedöma* hur framgångsrika de har varit med det.
Men det finns ytterligare ett skadligt lager i detta problem.
Nyligen diskuterade jag just denna fråga med en programvaruutvecklare. Han påpekade för mig att innebörden av ”programvara utan defekter”, så som den hade förklarats för honom, var det jag just beskrev ovan. Det innebär att man levererar med alla buggar åtgärdade som teamet ansåg behövde åtgärdas för att kunna leverera. Och sedan levererar man med alla defekter som man beslutade att inte åtgärda. En definition som min samtalspartner för övrigt inte höll med om.
Det här är uppenbarligen bara definitionsmässig dimridå och skenmanöver. Du levererar faktiskt med defekter, och du vet att du gör det, men du använder slagordet ”noll defekter” för att dölja detta faktum för dig själv – och för ledningen, förstås. Vi vet ju alla att den lätt hypnotiseras av tomma slagord som får den att känna sig framgångsrik.
Det är selektiv minskning av defekter, inget mer.
Hur tar vi oss bort från bluffen om noll defekter?
Och grunden för denna bluff är själva språket, ett språk som formar och binder vårt tänkande innan vi ens kan börja svara konceptuellt på vad det säger. Det är detta falska språk som från första början skapar situationen där vi måste förklara varför det är fel. Och därför börjar vi trängas in i ett hörn av ett slagords vokabulär.
Detta är en så vanlig praxis inom programvaruutveckling. Tyvärr är den inte begränsad till att vi ljuger för oss själva om ”noll defekter”. Den genomsyrar varje nivå av vårt tänkande och handlande, som testare, i vår utvecklingsprocess, i våra metoder och i våra mätvärden.
Lyssna, låt oss börja möta verkligheten kring vad vi gör och inte gör. Och det första steget i den återhämtningen är att använda ett språk som ärligt beskriver vad vi gör och inte gör. För om själva språket vi använder för att kommunicera dessa verkligheter i grunden är bedrägligt, oärligt och vanföreställt, skapar vi inte programvara av hög kvalitet. Vi tillverkar propaganda.
Det andra problemet med diskursen om ”nollfelsprogramvara” är att även om detta är ett uppriktigt mål – i den bemärkelsen att människor uppriktigt tror att det är möjligt och att det inte bara är ett cyniskt spel för gallerierna – så begränsar ytterligare ett, mer allvarligt, problem användbarheten hos denna idé. Det problemet är följande:
Hur skulle ni någonsin kunna veta, och bevisa, att ni har hittat ”alla” fel som finns att hitta i programvaran som testas? Och inte bara det antal fel som ni har lyckats hitta under den tilldelade tiden? Hur skulle ni kunna bevisa för er själva att mängden buggar ni har hittat är den fullständiga mängden buggar som programvaran faktiskt innehåller?
Det kan ni inte. Eftersom det skulle kräva någon process utanför själva QA-arbetet för att avgöra detta. Annars är det bara ett cirkelresonemang. Och vad skulle denna externa process vara?
Och detta gäller oavsett hur många buggar ni redan har hittat. Ni skulle kunna ha hittat en miljon av dem. Det bevisar inte att det inte finns en miljon och en bug som lurar där ute i programvarans skuggor.
Finns det något värdefullt i nollfelskonceptet?
De uppenbara logiska och kunskapsteoretiska problemen med att tala och tänka i termer av ”nollfelsprogramvara” är helt enkelt oöverstigliga. Själva benämningen går inte att rädda, oavsett hur vi omformulerar den.
Men om vi ser bortom den vilseledande sloganen, och undersöker vad som från början gör den attraktiv och begreppsmässigt giltig för annars tänkande människor, kommer vi att hitta något värdefullt att fokusera på.
Detta ”något” är en annan fråga, men en fråga som besvarar de praktiska och känslomässiga behov som tycks tillgodoses av den falska diskursen om nollfelsprogramvara, och dessutom på ett mer sammanhängande och försvarbart sätt.
Den fråga som människor inom programvaruutveckling egentligen försöker komma till rätta med här, genom att ta sin tillflykt till självbedrägeri, är i sig bedrägligt enkel. Nämligen: ”När vet vi att vi kan sluta testa?”
Det är den enda fråga jag någonsin ställer till kandidater för ledande QA-positioner i min organisation. För egentligen är det den enda fråga som QA behöver besvara. Och om QA inte kan göra det är QA ett fullständigt slöseri med tid. För att besvara den frågan måste vi först besvara en föregående fråga.
Noll fel kontra procentuell testtäckning
Hur vet vi om de fel vi redan har hittat – oavsett hur många de kan vara – på ett rimligt sätt kan anses representera det riskomfång som skapats av hur programvaran som testas har specificerats och utvecklats? Så att vi med tillförsikt kan säga att kvarvarande oupptäckta fel utgör en acceptabel risk för beslutet att släppa programvaran till allmänheten?
När frågan formuleras på detta sätt ser vi att den inte alls handlar om fel. Den handlar om testtäckning. Er analys av hittade buggar, oavsett hur omfattande deras antal är, betyder ingenting om de inte kan relateras till och bedömas mot en analytisk förståelse av den testtäckning som QA-arbetet hittills har uppnått, i förhållande till den täckning som återstår att uppnå.
För om mängden kända fel, oavsett hur mycket tid som har lagts på testning, endast representerar 30 % faktisk testtäckning – och ni inte vet det – har ni ingen rationell grund för att veta vad de betyder för ett beslut om att leverera programvaran.
Den verkliga diskussionen om, och det verkliga målet för, verkligt effektiva QA-insatser kan inte handla om ”noll fel”, utan snarare om ”100 % testtäckning”. Av det skäl jag anger ovan.
Den stora fördelen med detta sätt att tänka kring programvarukvalitet är att det bygger på en definition av tillräcklig testtäckning som QA tar fram innan testningen påbörjas. Därför kan själva definitionen testas mot specifikationer, krav, tidigare kundproblem och kundbehov med mera, och ändras vid behov.
Framåt: testtäckning utan luckor
Att tänka på detta problem i termer av fel misslyckas just eftersom det inte är något som på ett meningsfullt sätt kan definieras i förväg, eftersom antalet och allvaret hos problemen endast kan upptäckas efter testningen.
Dessutom bedöms det inte mot en befintlig (meningsfull) definition av vad tröskeln för ”noll” faktiskt skulle kunna innebära. Det är slöseri med tid att definiera framgång i termer av en variabel som själv är odefinierad och omöjlig att definiera.
Det är därför det enda sättet att rädda idén om nollfelsprogramvara är att styra detta tänkande och denna planering mot testtäckning utan luckor. Motivationen bakom nollfelsmantrat är inte fel i sig. Den har bara riktats bort från sitt egentliga mål. Gör den justeringen, så blir meningsfulla och mätbara definitioner av acceptabel programvarukvalitet möjliga.
Om du är redo att lära dig mer och ändå lära dig av experter och vd:ar är detta en podcast som vi tror att du kommer att uppskatta: TEAMARBETE, AI OCH KONTAINERISERING (MED NASA:S MICHAEL RITCHSON)
Relaterad läsning: DE 10 BÄSTA VERKTYGEN FÖR FELSPÅRNING VID PROGRAMVARUTESTNING
