De softwarerechercheur

Testen van software is de laatste weken een populair onderwerp. Nadat onder andere Chris Verhoef en Daan Kalmeijer hun licht over de problematiek hebben laten schijnen kan ik natuurlijk niet achterblijven. Mijn oplossing is even simpel als cool…

De Kwestie

Testen is niet sexy. Hoe je het ook wendt of keert, het is maar voor weinig mensen duurzaam inspirerend om hun dagen te slijten met het vastleggen van “bevindingen”. Er zijn ongetwijfeld voorbeelden van toegewijde testers die van het zo grondig mogelijk doortesten van het werk van anderen hun levensvervulling hebben gemaakt. Mensen met een passie voor het testen van software. Jammer genoeg zijn dit er te weinig om te voorkomen dat er vaak veel, erg veel te verbeteren valt aan de kwaliteit van software – in het bijzonder als deze nog maar kort geleden gereleased is.

Er is in de loop van de jaren van alles aan gedaan om dit te verbeteren. Bijvoorbeeld door het werk van testers te professionaliseren via methodieken als TMap. Of door het testen vroeger in het ontwikkelproces een rol te laten spelen – test-driven development of zelfs test-driven design. Er is ook veel geïnvesteerd in test-tooling, om de productiviteit van testers te kunnen verhogen. Het resultaat? Er wordt meer getest dan ooit, er worden meer “bevindingen” gelogd dan ooit en de kwaliteit van de software is…? Tsja, daar is dus geen objectieve maatstaf voor. Misschien is die kwaliteit wel beter dan ooit, maar ervaren we dat op de een of andere manier anders.

Er zijn verschillende auteurs die erop hebben gewezen dat er wel degelijk voorbeelden van goede, robuuste software zijn. En dan gaat het niet eens in het bijzonder over de software van NASA – waarbij de gevolgen van een programmeerfoutje wel erg pijnlijk kunnen zijn – maar bijvoorbeeld over iets als Google Earth. Welke software engineer droomt er niet van om zoiets monumentaals op z’n naam te hebben? En als je nagaat hoe foutloos en snel dat werkt, zelfs terwijl het wereldwijd door misschien wel honderden miljoenen gebruikers wordt gebruikt, dan kun je alleen maar veel respect hebben voor de makers.

Steve Yegge werkt voor Google, en heeft in zijn beroemde artikel “Business Requirements are Bullshit” al eens onthuld wat het geheim is achter het succes van de software van Google: «ONLY BUILD STUFF FOR YOURSELF». Gewoon de beste mensen inhuren en ze de opdracht geven om dingen te bouwen die ze zelf leuk zouden vinden om te gebruiken. Just for Fun. Dat werkt blijkbaar. Maar ja. Wie vindt het nou “fun” om een magazijnvoorraadsysteem van een EDI-koppeling te voorzien? Of om een FTP-client te porten van WinXP naar Vista? Of om de belastingdiskette (ahum) aan te passen aan alweer gewijzigde belastingregels?

Kalmeijer snijdt dit aspect ook aan. Was het testen van businesssoftware maar net zo leuk als het is om een game te testen… Yegge heeft slecht nieuws voor de gedroomde gametesters: de ontwikkelaars zelf vinden het veel te leuk om hun eigen game te testen – ze laten dat echt niet aan een goedbetaalde tester over.

Maar als het dan onvermijdelijk is dat er “saaie” software gemaakt moet worden en het geen fun is om die te testen, hoe zouden we dan toch de kwaliteit van de software een boost kunnen geven?

Kunnen we het echt niet leuker maken?

Hoezo zou het niet leuk kunnen zijn om saaie software beter te maken? Ik ken een heleboel mensen die dol zijn op het oplossen van raadsels en cryptogrammen. Het schijnt dat Sudoku’s enorm populair zijn. House trekt wereldwijd miljoenen kijkers met zijn zoektochten naar medische mysteries. Sinds CSI en Numbers zijn er massa’s schoolkinderen die dromen van een carrière bij de misdaadbestrijding. En geef toe: het moet een kick zijn om met het slimme gebruik allerhande bewijsmateriaal een dader te vinden.

Waarom zou het dan niet leuk kunnen zijn om de oorzaak van een softwareprobleem te traceren? Dat is toch ook werk voor een soort detective? Verzamelen van bewijs, andere daders uitsluiten en de echte dader liefst op heterdaad betrappen?

Als we dan het werk van ‘testers’ eens zo zouden organiseren dat ze niet afgerekend zouden worden op het aantal “bevindingen” dat ze vastleggen, maar het aantal oorzaken van problemen die ze hebben blootgelegd? Dat ze daarbij ook de tools krijgen om sporenonderzoek te kunnen doen, om verdachten te kunnen ondervragen en om bewakingsbeelden te kunnen opnemen? Dat ze, kortom, een echte softwarerechercheur zouden worden? En dat de beste rechercheurs kunnen promoveren naar een heus SWAT-team?

Hmmm, dat zou wel eens kunnen werken. Bug hunting zou best eens cool kunnen worden. Als we met z’n allen nou eens serieus werk zouden maken van test-requirements en testware en een succesvolle softwarerechercheur ook navenant zouden belonen, dan heb ik er alle vertrouwen in dat het goed gaat komen met die softwarekwaliteit.

Nu moet er alleen nog iemand een script bedenken voor de volgende succesvolle tv-serie: the Bug Hunter. Een kerncentrale redden van een melt-down, voorkomen dat een ruimtevaartmissie op een ramp uitloopt, op het nippertje voorkomen dat de wereld ten onder gaat omdat het interbancaire geldverkeer niet meer werkt, een volkomen vastgelopen luchthaven weer op gang helpen, het lek in de CIA-systemen dichten en zo kan ik er nog wel meer bedenken. Wie tipt Hollywood?

In deze kwestie wordt een actueel thema op een scherpe manier geanalyseerd. Het is de 13de in een reeks die op dit weblog gepubliceerd zal worden.