• English
  • Nederlands
HOME
SEARCH
CONTACT
NEWSLETTER
 
 
 
CONTENT
About us
Call for contribution
Contributions
The CIO talks
Proceedings
Blogs
Master thesis
Forum
Wiki
Events calendar
Links
Login/Register
advertisements
Zoek je een baan?
Zoek je hulp?
Zoek je een opleiding?
Zoek je een boek?
Zoek je een tool?












 
 
BLOGS
De softwarerechercheur
Hans Bot   
Monday, 03 November 2008

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 mijn weblog ArchitectuurBedrijven gepubliceerd is.






Be the first to write a comment
RSS comments

Only registered users can write comments.
Please login or register.




Share / deel
Del.icio.us!Google!Technorati!Yahoo!
 

Via Nova Architectura is not responsible for the content of blogs, but authors and readers are asked to adhere the following guidelines. Authors are strongly encouraged to check facts, cite sources, present balanced views, acknowledge and correct errors. Respect copyright, fair use and financial disclosure laws. Please do not disparage organizations, or individuals. Being critical of someone's practice is acceptable, when it is done in a professional manner. Prevent usage of marketing statements. Comments should be relevant to the specific post they are attached to. Spam, flaming, personal attacks, and off-topic comments are not permitted. Readers are requested to notify This e-mail address is being protected from spam bots, you need JavaScript enabled to view it of any violations. The editor holds the right to remove any statements that, in the editors opinion, infringe the above guideline(s). The author receives a notification of this action.
feed image
ISSN: 1877-2994