Den kalde, harde sannheten om programvare uten feil

For mange år siden, den dagen vi bestemte oss for å lansere en større oppgradering av produktet vårt – en beslutning som selvfølgelig krevde min godkjenning som QA-direktør – gikk jeg nedover gangen da administrerende direktør passerte meg. 

Han stoppet meg og sa: «Så jeg kan anta at vi lanserer uten feil?»

Uten å tenke så mye som jeg sannsynligvis burde ha gjort, svarte jeg ubekymret: «Selvfølgelig ikke. Det finnes ikke programvare uten feil.» 

Han ble lamslått og forferdet over svaret mitt. Han ble så opprørt på grunn av meg at han avsluttet samtalen og stormet nedover gangen.

Den gangen avskrev jeg dette som et resultat av at han var ny i programvarebransjen og i livssyklusen, siden han kom fra forlagsbransjen (lang historie – en annen gang). For alle på utviklingsteamet visste at vi lanserte med feil. Men vi visste hvilke feil det var snakk om fra begynnelsen, og det gjorde hele forskjellen i risikovurderingen vår.

Jeg legger imidlertid med bekymring merke til at denne misforståelsen hos min tidligere administrerende direktør nylig har blitt utbredt i bransjen vår. Feilfri, «programvare uten feil» er en ny skryteformulering eller et nytt mantra som jeg ser og hører stadig oftere. Og ikke bare fra uvitende administrerende direktører (overflødig, jeg vet), men fra folk i bransjen som burde vite bedre. Og som faktisk gjør det. Det synes jeg er svært urovekkende.

Det finnes en forstand der tankegangen om «ingen feil» ikke bare er løgnaktig, egennyttig tull. I Vesten er det stort sett bare tomt prat og posering for syns skyld. Men i Japan har det faktisk en betydning. Og det gjelder alle bransjene deres. 

Jeg jobbet i Japan i et år, og dette snudde opp ned på tankegangen min, men på en veldig god måte. For definisjonen deres av en «feil» er svært forskjellig fra vår. Hvis det for eksempel ligger en tyggegummipapirbit på gulvet i fabrikken, regnes det som en feil, på samme måte som et problem med maskineriet eller resultatet av en prosess. Hvis vi virkelig var seriøse med hensyn til «ingen feil», ville vi sett på dette problemet på samme måte som japanerne. Men det gjør vi ikke, så det kommer vi heller ikke til å gjøre.

Det jeg prøvde å si til den stakkars administrerende direktøren, kanskje litt for direkte, er at all moderne kommersiell programvare er uendelig kompleks, og at måtene den kan samhandle med seg selv eller omgivelsene på, derfor også er uendelige. Det er bare mulig å finne alle feil hvis du har uendelig lang tid til å teste. Men ingen av oss er udødelige.

Selv om du kunne finne hver eneste feil første gang, ville du ikke hatt tid til å rette dem alle og lansere et produkt i løpet av dette århundret – tid til markedet er en reell faktor. Så selv om feilene blir funnet, må du lansere med dem. 

Hele forestillingen om «programvare uten feil» er altså grunnleggende sett en villfarelse.

Hvor kom forestillingen om programvare uten feil fra?

Grunnlaget for denne villfarelsen er at QA-rollen er å «sikre» kvalitet. Det gjør den ikke. Det er produktledelsens og utviklingens oppgave. Rollen til kvalitetssikring er å *vurdere* hvor vellykkede de har vært med dette.

Men det finnes et annet skadelig lag i dette problemet. 

Nylig diskuterte jeg nettopp dette problemet med en programvareutvikler. Han påpekte overfor meg at betydningen av «programvare uten feil», slik den var blitt forklart for ham, var det jeg nettopp beskrev ovenfor. Det betyr å lansere med alle feilene som teamet besluttet at det måtte rette for å kunne lansere. Og deretter lansere med alle feilene de besluttet ikke å rette. En definisjon min samtalepartner for øvrig ikke var enig i.

Dette er tydeligvis bare definisjonstaktikk og røyktepper. Du lanserer faktisk med feil, og du vet at du gjør det, men du bruker slagordet «ingen feil» for å skjule dette faktum for dere selv – og for ledelsen, selvfølgelig. Som vi alle vet, lar ledelsen seg lett hypnotisere av tomme slagord som får dem til å føle seg vellykkede.

Det er selektiv reduksjon av feil, ikke noe mer.

Hvordan kommer vi oss bort fra påskuddet om ingen feil?

Og grunnlaget for dette påskuddet er selve språket – et språk som former og binder tankegangen vår før vi i det hele tatt kan begynne å svare begrepsmessig på det som blir sagt. Det er dette falske språket som i utgangspunktet skaper situasjonen der vi må forklare hvorfor det er galt. Og dermed begynner vi å bli trengt opp i et hjørne av slagordets vokabular.

Dette er en så vanlig praksis innen programvareutvikling. Dessverre begrenser det seg ikke til at vi lyver for oss selv om «ingen feil». Det infiserer alle nivåer av hvordan vi tenker og handler – som testere, i utviklingsprosessen vår, i metodene våre og i måleverdiene våre.

La oss begynne å forholde oss til virkeligheten om hva vi gjør og ikke gjør. Og det første steget i denne gjenopprettingen er å bruke et språk som ærlig beskriver hva vi gjør og ikke gjør. For hvis selve språket vi bruker til å kommunisere disse realitetene, i seg selv er grunnleggende falskt, uærlig og virkelighetsfjernt, lager vi ikke programvare av høy kvalitet. Vi produserer propaganda. 

Det andre problemet med diskursen om «programvare uten feil» er at selv om dette er et oppriktig mål – i den forstand at folk oppriktig tror det er mulig, og at det ikke bare er en kynisk øvelse – begrenser et annet, mer alvorlig problem nytten av denne ideen. Problemet er dette: 

Hvordan kan du overhodet vite, og bevise, at du har funnet «alle» feilene som finnes i programvaren som testes? Og ikke bare antallet feil du har klart å finne i den tildelte tiden? Hvordan kan du bevise overfor dere selv at settet med feil dere har funnet, er det komplette settet med feil som programvaren faktisk inneholder? 

Det kan du ikke. For det ville kreve en prosess utenfor QA selv for å fastslå dette. Ellers blir det bare et sirkelargument. Og hva skulle denne eksterne prosessen være? 

Og dette gjelder uansett hvor mange feil dere allerede har funnet. Dere kunne ha funnet en million av dem. Det beviser ikke at det ikke finnes en feil nummer én million og én som lurer der ute i programvarens skygger.

Finnes det noe verdifullt i konseptet om null feil?

De åpenbare logiske og erkjennelsesteoretiske problemene med å snakke og tenke i termer av «programvare uten feil» er ganske enkelt uoverkommelige. Selve betegnelsen kan ikke reddes, uansett hvordan vi omformulerer den. 

Men hvis vi ser forbi det villedende slagordet og undersøker hva som i utgangspunktet gjør det attraktivt og konseptuelt gyldig for ellers tenkende mennesker, vil vi finne noe verdifullt å fokusere på.

Dette «noe» er et annet spørsmål, men et spørsmål som besvarer de praktiske og følelsesmessige behovene som tilsynelatende adresseres av den falske diskursen om programvare uten feil, og på en mer sammenhengende og forsvarlig måte.

Problemet som folk innen programvare egentlig prøver å få grep om her ved å ty til selvbedrag, er i seg selv villedende enkelt. Nemlig: «Når vet vi at vi kan slutte å teste?» 

Det er det eneste spørsmålet jeg noen gang stiller kandidater til lederstillinger innen QA i organisasjonen min. For egentlig er det det eneste spørsmålet QA trenger å besvare. Og hvis QA ikke kan det, er QA fullstendig sløsing med tid. For å besvare dette spørsmålet må vi først besvare et foregående spørsmål. 

Null feil kontra % testdekning

Hvordan vet vi om feilene vi allerede har funnet – uansett hvor mange de måtte være – med rimelighet kan godtas som en representasjon av risikorammen som er skapt av hvordan programvaren som testes, ble spesifisert og utviklet? Slik at vi med sikkerhet kan si at gjenværende uoppdagede feil representerer en akseptabel risiko ved en beslutning om å lansere programvaren for offentligheten?

Stilt på denne måten ser vi at dette spørsmålet ikke handler om feil i det hele tatt. Det er et spørsmål om testdekning. Analysen av feilene dere har funnet, uansett hvor stort antallet er, betyr ingenting hvis de ikke kan korreleres med og vurderes opp mot en analytisk forståelse av testdekningen som QA-arbeidet har oppnådd til nå, sammenholdt med dekningen som gjenstår å oppnå. 

For hvis dette settet med kjente feil, uansett hvor mye tid som er brukt på testing, bare representerer 30 % faktisk testdekning – og dere ikke vet dette – har dere ikke noe rasjonelt grunnlag for å vite hva de betyr med tanke på en beslutning om å lansere programvaren.

Den reelle diskusjonen om, og det virkelige målet for, virkelig effektive QA-innsatser kan ikke handle om «null feil», men snarere om «100 % testdekning». Av grunnen jeg nevnte ovenfor. 

Den store fordelen med denne måten å tenke på programvarekvalitet på er at den bygger på en definisjon av tilstrekkelig testdekning som QA selv fastsetter før testingen. Derfor kan selve definisjonen testes mot spesifikasjoner, krav, tidligere kundeproblemer og kundebehov osv., og endres etter behov.

Veien videre: testdekning uten gap

Å tenke på dette problemet i termer av feil mislykkes nettopp fordi det ikke er noe som kan defineres meningsfullt på forhånd, siden antallet og alvorlighetsgraden av problemene først kan oppdages etter testingen. 

I tillegg vurderes det ikke opp mot en eksisterende (meningsfull) definisjon av hva terskelen for «null» faktisk kan bety. Det er bortkastet tid å definere suksess ut fra en variabel som selv er udefinert og umulig å definere.

Derfor er den eneste måten å redde ideen om programvare uten feil på, å kanalisere denne tankegangen og planleggingen mot testdekning uten gap. Motivasjonen bak mantraet om null feil er ikke feil i seg selv. Den har bare blitt rettet mot feil mål i stedet for det egentlige målet. Gjør denne justeringen, så blir meningsfulle, målbare definisjoner av akseptabel programvarekvalitet mulige.

Hvis du er klar til å lære mer og til å lære av eksperter og toppledere likevel, er dette en podkast vi tror du vil like: SAMARBEID, AI OG KONTAINERISERING (MED MICHAEL RITCHSON FRA NASA)

Relatert lesning: 10 BESTE VERKTØY FOR FEILSPORING I PROGRAMVARETESTING