De keiharde waarheid over software zonder defecten
Jaren geleden, op de dag dat we besloten een belangrijke upgrade van ons product uit te brengen, een beslissing waarvoor uiteraard mijn goedkeuring als QA-directeur vereist was, liep ik door de gang en kwam ik de CEO tegen.
Hij hield me tegen en zei: “Dus ik mag ervan uitgaan dat we zonder defecten uitbrengen?”
Zonder er waarschijnlijk zo goed over na te denken als ik had moeten doen, antwoordde ik luchtig: “Natuurlijk niet. Software zonder defecten bestaat niet.”
Want more from The CTO Club?
Create a free account to finish this piece and join a community of CTOs and engineering leaders sharing real-world frameworks, tools, and insights for designing, deploying, and scaling AI-driven technology.
Have an account? Log In
Hij was verbijsterd en ontsteld door mijn antwoord. Hij was zo boos op me dat hij ons gesprek beëindigde en woedend de gang uit liep.
Destijds schreef ik dit toe aan het feit dat hij nieuw was in de softwarewereld en de levenscyclus daarvan, omdat hij uit de uitgeverswereld kwam (lang verhaal—voor een andere keer). Iedereen in het ontwikkelingsteam wist namelijk dat we met defecten zouden uitbrengen. Maar we wisten vanaf het begin welke defecten dat waren, en dat maakte al het verschil in onze risicobeoordeling.
Ik merk echter met bezorgdheid dat deze misvatting van mijn voormalige CEO zich de laatste tijd in onze sector heeft verspreid. Foutloze, “software zonder defecten” is een nieuwe opschepperij/mantra die ik steeds vaker zie en hoor. En niet alleen van onwetende CEO’s (overbodig, ik weet het), maar ook van mensen in de sector die beter zouden moeten weten. En dat in feite ook doen. Wat ik zeer verontrustend vind.
Er is een bepaalde betekenis waarin het denken in termen van "nul defecten" niet slechts bedrieglijke, eigenbelanggedreven onzin is. In het Westen is het meestal slechts gebakken lucht en vertoon om indruk te maken. Maar in Japan heeft het daadwerkelijk betekenis. En dat geldt voor al hun industrieën.
Ik heb een jaar in Japan gewerkt, en dit zette mijn wereld op zijn kop, maar dan op een heel goede manier. Omdat hun definitie van een "defect" heel anders is dan de onze. Als er bijvoorbeeld een kauwgomwikkel op de vloer van de fabriek ligt, wordt dat als een defect beschouwd, net zo goed als een probleem met de machines of de output van een proces. Als we echt serieus zouden zijn over "nul defecten", zouden we dat probleem bekijken zoals de Japanners dat doen. Maar dat doen we niet, dus zullen we dat ook niet doen.
Wat ik die ongelukkige CEO probeerde te zeggen, misschien iets te bot, is dat elk stuk moderne commerciële software oneindig complex is, en dat de manieren waarop het met zichzelf of zijn omgeving kan communiceren daarom ook oneindig zijn. Het is alleen mogelijk om elk defect te vinden als je oneindig veel tijd hebt om te testen. Maar niemand van ons is onsterfelijk.
Zelfs als je elk laatste defect de eerste keer zou kunnen vinden, zou je geen tijd hebben om ze allemaal te herstellen en deze eeuw nog een product uit te brengen—tijd tot de marktintroductie bestaat echt. Dus zelfs als je ze vindt, zul je ermee moeten uitbrengen.
Het hele idee van “software zonder defecten” is dus van meet af aan inherent waanzinnig.
Waar komt het idee van software zonder defecten vandaan?
De kern van dit waanidee is dat de rol van QA erin bestaat kwaliteit te "waarborgen". Dat doet QA helemaal niet. Dat is de taak van productbeheer en software-engineering. De rol van kwaliteitsborging is om te *beoordelen* hoe succesvol zij daarin zijn geweest.
Maar er zit nog een verderfelijke laag aan dit probleem.
Onlangs besprak ik dit specifieke probleem met een softwareontwikkelaar. Hij wees me erop dat de betekenis van “software zonder defecten”, zoals die aan hem was uitgelegd, precies was wat ik hierboven zei. Het betekent dat je uitbrengt met alle softwarefouten die het team heeft opgelost omdat het vond dat dit nodig was om uit te brengen. En vervolgens uitbrengt met alle defecten die het team besloot niet te herstellen. Een definitie waar mijn gesprekspartner het overigens niet mee eens was.
Dit is duidelijk slechts definitorische rook en spiegels. Je brengt echt uit met defecten, en je weet dat ook, maar je gebruikt de slogan "nul defecten" om dat feit voor jezelf te verbergen—en natuurlijk ook voor het management. Van wie we allemaal weten dat het gemakkelijk wordt gehypnotiseerd door lege slogans waardoor het zich succesvol voelt.
Het is niets meer dan selectieve defectreductie.
Hoe komen we af van de misleiding van nul defecten?
En de basis van deze misleiding is taal zelf, taal die ons denken vormt en verplicht voordat we conceptueel kunnen beginnen te reageren op wat ermee wordt gezegd. Het is deze valse taal die in de eerste plaats de situatie creëert waarin we moeten uitleggen waarom ze onjuist is. En zo worden we door de woordenschat van een slogan steeds verder in een hoek gedreven.
Dit is een veelvoorkomende praktijk in softwareontwikkeling. Helaas beperkt dit zich niet tot tegen onszelf liegen over "nul defecten". Het doordringt elk niveau van ons denken en handelen, als testers, in ons ontwikkelingsproces, in onze methodologieën en in onze meetgegevens.
Luister, laten we de realiteit onder ogen zien van wat we wel en niet doen. En de eerste stap in dat herstel is taal gebruiken die eerlijk beschrijft wat we wel en niet doen. Want als de taal die we gebruiken om die realiteiten te communiceren zelf fundamenteel frauduleus, oneerlijk en waanzinnig is, maken we geen software van hoge kwaliteit. We vervaardigen propaganda.
Het andere probleem met het discours over “software zonder defecten” is dat zelfs als dit een oprecht nagestreefd doel is—in de zin dat mensen oprecht geloven dat het mogelijk is en niet slechts een cynische oefening is—een ander, ernstiger probleem de bruikbaarheid van dit idee beperkt. Dat probleem is dit:
Hoe zou je ooit kunnen weten en bewijzen dat je “alle” defecten hebt gevonden die in de software onder test te vinden zijn? En niet alleen het aantal defecten dat je binnen de toegewezen tijd hebt weten te vinden? Hoe zou je jezelf kunnen bewijzen dat de set bugs die je hebt gevonden de volledige set bugs is die de software daadwerkelijk bevat?
Dat kun je niet. Want daarvoor zou een proces buiten QA zelf nodig zijn om dit vast te stellen. Anders is het slechts een cirkelredenering. En wat zou dat externe proces dan zijn?
En dit blijft waar, ongeacht hoeveel bugs je al hebt gevonden. Je zou er een miljoen kunnen hebben gevonden. Dat bewijst niet dat er niet ergens in de software-schaduwen nog bug nummer één miljoen en één op de loer ligt.
Is er iets waardevols aan het concept van nul defecten?
De overduidelijke logische en epistemologische problemen met spreken en denken in termen van “software zonder defecten” zijn eenvoudigweg onoverkomelijk. De benaming zelf valt niet te redden, hoe we haar ook herformuleren.
Maar als we verder kijken dan de misleidende slogan, naar wat haar in de eerste plaats aantrekkelijk en conceptueel geldig maakt voor mensen die verder wel nadenken, vinden we iets waardevols om ons op te richten.
Dat “iets” is een andere vraag, maar wel een vraag die voorziet in de praktische en emotionele behoeften die ogenschijnlijk worden aangesproken door het onjuiste discours over software zonder defecten, en dat op een meer coherente en verdedigbare manier.
Het probleem waarmee mensen in de softwarewereld hier werkelijk proberen af te rekenen door hun toevlucht te nemen tot zelfbedrog, is op zichzelf bedrieglijk eenvoudig. Namelijk: “Wanneer weten we dat we kunnen stoppen met testen?”
Het is de enige vraag die ik ooit stel aan kandidaten voor QA-leiderschapsfuncties in mijn organisatie. Want eigenlijk is dat de enige vraag die QA moet beantwoorden. En als QA dat niet kan, is het een complete verspilling van tijd. Om die vraag te beantwoorden, moeten we eerst een voorafgaande vraag beantwoorden.
Nul defecten versus % testdekking
Hoe weten we of de defecten die we al hebben gevonden—hoeveel het er ook mogen zijn—redelijkerwijs kunnen worden aanvaard als een weergave van de risicobandbreedte die is ontstaan door de manier waarop de software onder test is gespecificeerd en ontwikkeld? Zodat we met vertrouwen kunnen zeggen dat resterende, niet-gedetecteerde defecten een aanvaardbaar risico vormen voor de beslissing om de software voor het publiek beschikbaar te stellen?
Als we de vraag op deze manier stellen, zien we dat dit helemaal geen vraag over defecten is. Het is een vraag over testdekking. Je analyse van gevonden bugs, hoe groot hun aantal ook is, betekent niets als die niet kan worden gecorreleerd aan en afgezet tegen een analytisch inzicht in de testdekking die de QA-inspanning tot nu toe heeft bereikt, vergeleken met de dekking die nog moet worden bereikt.
Want als die verzameling bekende defecten, ongeacht hoeveel tijd er aan testen is besteed, slechts 30% werkelijke testdekking vertegenwoordigt—en je weet dit niet—dan heb je geen rationele basis om te weten wat ze betekenen voor een beslissing om de software uit te brengen.
De werkelijke discussie over, en het werkelijke doel van, echt effectieve QA-inspanningen kan niet draaien om “nul defecten”, maar veeleer om “100% testdekking”. Om de reden die ik hierboven geef.
Het grote voordeel van deze manier van denken over softwarekwaliteit is dat ze steunt op een definitie van toereikende testdekking die QA zelf voorafgaand aan het testen opstelt. Daarom kan die definitie zelf worden getoetst aan specificaties, vereisten, eerdere klantproblemen en klantbehoeften enzovoort, en waar nodig worden aangepast.
Vooruitgang boeken: testdekking zonder hiaten
Dit probleem in termen van defecten benaderen werkt niet, juist omdat het niet iets is dat vooraf zinvol kan worden gedefinieerd, aangezien het aantal en de ernst van problemen pas na het testen kunnen worden vastgesteld.
Bovendien wordt het niet beoordeeld aan de hand van een vooraf bestaande (zinvolle) definitie van wat de drempel van “nul” daadwerkelijk zou kunnen betekenen. Het is tijdverspilling om succes te definiëren in termen van een variabele die zelf ongedefinieerd en niet definieerbaar is.
Daarom is de enige manier om het idee van software zonder defecten te redden, dit denken en deze planning te richten op testdekking zonder hiaten. De motivatie achter de nul-defectenmantra is op zichzelf niet verkeerd. Ze is alleen afgeleid van haar werkelijke doel. Maak die aanpassing, en zinvolle, meetbare definities van aanvaardbare softwarekwaliteit worden mogelijk.
Als je klaar bent om meer te leren en desondanks van experts en CEO's te leren, is hier een podcast waarvan we denken dat je die leuk zult vinden: SAMENWERKING, AI EN CONTAINERISERING (MET MICHAEL RITCHSON VAN NASA)
Gerelateerd artikel: DE 10 BESTE TOOLS VOOR HET BIJHOUDEN VAN DEFECTEN BIJ SOFTWARETESTEN
