‘Blind kiezen’ soms voordelig

Alvorens te bezien in hoeverre statistisch testen een oplossing kan bieden, is het belangrijk eerst een goede analyse te maken van de huidige situatie. Natuurlijk is het zo dat de testkosten toenemen. Een onderzoek van het NGGO uit 1991 geeft aan dat de testinspanning zo’n 20 procent van de totale ontwikkelingsinspanning bedraagt. Bij huidige projecten is dit percentage vaak 40 of zelfs 50 procent. Overigens zijn bij veel organisaties en projecten niet zo zeer de (test)kosten, maar veel meer de (test)doorlooptijd kritisch. Time-to-market is steeds vaker van essentieel belang voor het succes van een IT-project. Het toenemend belang en ook de toegenomen complexiteit van IT-producten hebben helaas niet geleid tot structureel betere IT-organisaties. Nog steeds dient het merendeel van de IT-organisaties te worden gekenmerkt als onvolwassen, en bevinden zij zich in termen van het Capability Maturity Model (CMM) op niveau 1: ‘Initial’. Recente cijfers laten zien dat slechts 25 procent van de IT-organisaties zich op CMM-niveau 2, ‘Defined’, of hoger bevindt (een overigens stijgend percentage), en dat terwijl inmiddels is aangetoond dat hogere volwassenheid leidt tot doorlooptijdreductie en minder fouten. Het probleem dat wordt behandeld is derhalve in eerste aanleg geen testprobleem. De diepere oorzaak ligt bij de IT-organisaties, waarvan het merendeel nog steeds niet in staat is op een goede manier requirements op te stellen en te managen, gedegen projectplannen op te stellen met realistische begrotingen, configuratiemanagement adequaat uit te voeren et cetera. Statistisch testen, of welke testaanpak dan ook, is derhalve niet meer (maar ook niet minder) dan een interessante detectieve maatregel, daar waar we ons zouden moeten richten op preventie. Niveau 1 In de praktijk worden we natuurlijk veelal geconfronteerd met zogenaamde ‘niveau 1’-organisaties, en zullen we het testproces zo moeten inrichten dat de productrisico’s op een verantwoorde manier worden afgedekt, terwijl de testkosten en doorlooptijd binnen bepaalde grenzen blijven. Een gestructureerde testaanpak, zoals de defacto Nederlandse standaard TMap, biedt hier een groot aantal mogelijkheden voor, die helaas vaak niet of niet adequaat worden benut. Het startpunt voor een goed testproces is de teststrategie, waarbij op basis van een productrisicoanalyse, de prioriteiten en diepgang van de diverse tests worden bepaald. In veel organisaties wordt tegenwoordig bij een project een teststrategie opgesteld. Men heeft echter vaak moeite om deze strategie te concretiseren in een gedifferentieerde testaanpak waarbij, afhankelijk van het risico, meer of minder testgevallen worden opgesteld. In de praktijk wordt gewoon het hele systeem met ongeveer dezelfde diepgang getest. Ook het management, een van de belanghebbenden bij het opstellen van de teststrategie, vindt het maken van keuzes waarbij sommige delen van het systeem niet of minder diepgaand worden getest, vaak lastig en soms zelfs onacceptabel. De uitspraak: ‘Het systeem moet gewoon goed en volledig worden getest’, is helaas nog steeds in gebruik. Als gevolg van de moeilijkheden bij het concretiseren van de teststrategie en het ontbreken van voldoende testawareness bij het management, worden er geen keiharde keuzes gemaakt om delen niet of niet volledig te testen. Achteraf komt dan wel de kritiek dat testen erg veel heeft gekost en te lang heeft geduurd. Met het goed toepassen, in samenspraak met alle belanghebbenden, van de teststrategie is nog heel veel (tijd)winst te behalen. Het maken van testontwerpen is een activiteit die vooralsnog erg arbeidsintensief is (ondersteunende tools zijn helaas niet of nauwelijks voorhanden). Het heeft echter naast de reeds genoemde voordelen (zie het artikel van Rob Henzen), minstens nog twee andere belangrijke voordelen. Ten eerste zorgt een goed en gedetailleerd testontwerp ervoor dat een fout reproduceerbaar is. Immers alle testacties die zijn uitgevoerd zijn gespecificeerd in het testontwerp. Een ieder die als softwareontwikkelaar werkt of heeft gewerkt, weet dat eigenlijk alleen fouten die goed reproduceerbaar zijn kunnen worden opgelost. Ten tweede is het maken van testontwerpen een vorm van statisch testen. Tijdens het opstellen ervan worden allerlei bevindingen gedaan in de uitgangsdocumentatie (functioneel ontwerp, requirementsspecificatie). Door deze serieus te behandelen, wordt in een vroeg stadium reeds een groot aantal bevindingen gedaan die ertoe zullen leiden dat er minder ‘dure fouten’ (zowel qua tijd als geld) worden gevonden tijdens de testuitvoeringsfase. Een gedegen georganiseerde en uitgevoerde fase testontwerp verdient zich op deze wijze al grotendeels of zelfs volledig terug. Ten slotte is het testontwerp geen activiteit die per definitie van invloed is op de doorlooptijd van het project, derhalve heeft het geen negatieve invloed op de time-to-market van het product. Iets wat zoals eerder is aangegeven, vaak veel belangrijker is dan de eenmalige ontwikkelingskosten. Kwaliteit Is er nog een rol voor statistisch testen? In het Testing Maturity Model komt statistisch testen nadrukkelijk aan bod op niveau 5, ‘Optimisation’, als onderdeel van het procesgebied ‘Quality Control’. Quality Control heeft zijn oorsprong in industriële productieprocessen waar aselecte steekproeven, metrieken, oorzaakanalyse en acceptatiesteekproeven technieken zijn om de kwaliteit van de geproduceerde eindproducten vast te stellen en te waarborgen. Statistisch testen is niet slechts het willekeurig nemen van een steekproef, maar het op basis van gebruiksprofielen een representatieve testset samenstellen om vervolgens door middel van metingen een uitspraak te kunnen doen over de kwaliteit van het totale product. Een essentieel onderdeel van statistiek is uiteraard dat door middel van de steekproef een betrouwbare uitspaak wordt gedaan over de totale populatie. Dit toegepast op softwareproducten betekent dat slechts een deel wordt getest en vervolgens een uitspraak wordt gedaan over de kwaliteit van het totale systeem. Deze werkwijze veronderstelt dat het product een min of meer homogeen kwaliteitsniveau heeft: overal bestaat dezelfde complexiteit, codeerstandaards zijn consequent toegepast, de ontwerpen zijn allemaal geïnspecteerd et cetera. Verantwoord statistisch testen vereist een gedefinieerd en reproduceerbaar ontwikkelingsproces (niet voor niets komt het pas op niveau 5 van het TMM aan bod), met andere woorden: een volwassen IT-organisatie, en dat is nu net waar het nog vaak aan schort. Statistisch testen en quality control zijn uitstekende werkwijzen, maar aan de voorwaarden voor een succesvolle toepassing wordt nog maar zelden voldaan. Kunnen we dan voorlopig niets doen met statistisch testen? Een aantal concepten is zeer wel bruikbaar op lagere volwassenheidsniveaus en kunnen uitstekend complementair zijn ten opzichte van het ‘traditionele’ gestructureerd testen. Met name de ideeën over testen op basis van gebruiksprofielen kunnen een bijdrage leveren aan onder andere acceptatietesten en performancetesten. Ook het opbouwen van statistische metrieken, zoals het ‘aantal fouten per testuur’ en het gebruik daarvan als acceptatiecriterium, is een welkome verrijking van de meer traditionele acceptatiecriteria zoals ‘het aantal openstaande fouten’. Een gedegen studie van statistisch testen door de testgemeenschap is iets wat een bijdrage aan het verbeteren van het hedendaagse testproces kan leveren. Delen ervan zullen toepasbaar zijn binnen gestructureerd testen. Voorlopig zijn we echter nog ver verwijderd van het volledig (en alleen) statistisch testen. Het zal nog wel even duren voordat we onder een XRAY-scanner gaan liggen waarvan de kwaliteit met een steekproef is bepaald. Erik van Veenendaal is directeur van Improve Quality Services BV en als universitair docent verbonden aan de TU-Eindhoven (www.improveqs.nl).