Overslaan en naar de inhoud gaan

Testen geen zaak van ‘blind kiezen’

Psychologische factoren verstoren testproces
Business
Shutterstock
Shutterstock

Rob Henzen zet in zijn artikel duidelijke vraagtekens bij de klassieke teststrategieën. Deze strategieën met grotere en fijnmazigere testsets drukken steeds meer op projectbudgetten. Als alternatieve strategie pleit hij voor het uitvoeren van testen aan de hand van steekproeven, een statistische benadering. Op zich is deze gedachte interessant. Er ontbreekt echter een goede onderbouwing. Onder welke condities is deze alternatieve aanpak geldig? Hiernaast is het interessant na te gaan welke psychologische factoren een rol spelen bij testen. Ten slotte wordt ingegaan op de hamvraag waar elke organisatie mee worstelt: Wanneer kan gestopt worden met testen? De vraag of een informatiesysteem middels steekproeven effectief en efficiënt kan worden getest is niet zomaar bevestigend te beantwoorden. Een aantal factoren is van belang, waarvan hier enkele voorbeelden gegeven worden. In de eerste plaats is het van belang dat de uitgevoerde testen zo representatief mogelijk zijn voor het latere gedrag van gebruikers. Indien dit gedrag niet bekend is, ontstaan twee problemen. De testen zijn niet representatief en dus niet effectief. Verder kan hierdoor later nooit een goede uitspraak over de verwachte betrouwbaarheid worden gedaan. In de tweede plaats zal de distributiekans van fouten in het algemeen niet willekeurig zijn. Neem bijvoorbeeld een rij getallen van 1 tot 100. Indien personen gevraagd wordt steekproefsgewijs getallen te kiezen, zal een concentratie ontstaan rondom het midden (50). Dit verschijnsel van subjectieve waarschijnlijkheid doet zich ook voor bij het implementeren van software. Programmeurs besteden minder aandacht aan het testen van hun software op grensgevallen. Bij latere testen moet dus expliciet aandacht worden gegeven aan de gevolgen van zulke verschijnselen. Het is waarschijnlijk dat zo meer fouten zullen worden gevonden. In de derde plaats moet de vraag gesteld worden wat te doen indien een fout in een bepaald gedeelte van de software is gevonden. Indien gevonden fouten onafhankelijk van elkaar bestaan, kunnen vervolgtesten inderdaad steekproefsgewijs plaatsvinden. Indien fouten echter afhankelijk zijn, zullen vervolgtesten gericht moeten zijn op de gebieden waar eerdere fouten zijn gevonden. Weinig projecten onderzoeken of er al of niet een sterke afhankelijkheid tussen gevonden fouten bestaat. Aan de andere kant doet men gewichtige voorspellingen over de betrouwbaarheid op basis van het aantal gevonden fouten. Dit kan echter alleen gedaan worden indien er sprake is van afhankelijkheid tussen de gevonden fouten. Verder zal het aantal uitgevoerde testen hoog en representatief genoeg moeten zijn om statistisch verantwoorde uitspraken te kunnen doen. Verstoring Ondanks het potentiële nut van de toepassing van statistische methoden dient gewaakt te worden voor een aantal verstorende, psychologische factoren. Testers kunnen statistisch onderbouwde uitspraken doen, de besluitvorming op tactisch en strategisch niveau wordt beïnvloed door tal van niet-rationele factoren. Wederom enige voorbeelden. In de eerste plaats is er sprake van een subjectieve kijk op de opbrengsten. Deze is afhankelijk van de verwachte hoogte van de opbrengst en het moment waarop deze wordt gerealiseerd. Uit onderzoek blijkt dat deze twee variabelen een negatieve correlatie hebben. Met andere woorden, een morgen ontvangen euro is gevoelsmatig meer waard dan een euro die volgende week wordt ontvangen. Dit fenomeen manifesteert zich op verschillende wijzen tijdens de testfase. Tijdens de ontwerp- en implementatiefase van een informatiesysteem heeft iedereen nog de indruk constructief bezig te zijn, tijdens het testen ervaart iedereen de psychologische druk om zo snel mogelijk klaar te zijn. Testen wordt niet gezien als een activiteit die bijdraagt aan hogere opbrengsten. Dit uit zich tevens in aspecten als veronachtzaming van een adequate testomgeving, personele onderbezetting van testteams en inzet van relatief onervaren mensen. Testen wordt ervaren als een noodzakelijke activiteit die projecten vertraagt. Er kan als testteam ook gebruik gemaakt worden van dit verschijnsel. Zorg dat bij aanvang van de testfase veel fouten worden gevonden, zodat iedereen versterkt wordt in de overtuiging dat testen wel zinvol is. Vrijgave De grote aandacht voor procesverbeteringen in het laatste decennium heeft geleid tot het benoemen, beschrijven en verbeteren van ontwikkelingsprocessen. Als beloning ontvingen organisaties ISO-certificaten en hogere CMM-niveaus. Er is echter een proces dat zelden of nooit aandacht heeft gekregen, namelijk het proces van besluitvorming. Dit uit zich sterk bij het bepalen van het moment van vrijgeven van een informatiesysteem. Of met andere woorden: wanneer kan er worden gestopt met testen? De totstandkoming van het besluit tot vrijgave is in de meeste organisaties niet formeel geregeld. Bewust of onbewust wordt een aantal criteria in beschouwing genomen. Voorbeelden hiervan zijn: de druk vanuit de markt of beoogde interne gebruikers, de reeds gemaakte kosten, de beschikbare functionaliteit en de verwachte kwaliteit. Het criterium kwaliteit wordt in de meeste gevallen vertaald naar betrouwbaarheid. In het hele besluitvormingsproces doen zich drie grote problemen voor. In de eerste plaats is vooraf niet vastgesteld welke criteria expliciet van belang zijn en wat hun onderlinge prioriteiten zijn. Dit bemoeilijkt niet alleen de besluitvorming zelf, maar betekent ook dat het project en het testteam geen duidelijke doelstellingen hadden. In de tweede plaats is de beschikbare informatie beperkt. Het niet of onjuist toepassen van statistische technieken betekent dat de betrouwbaarheid niet goed kan worden bepaald. In de derde plaats worden langetermijneffecten niet meegenomen. Kwaliteit is meer dan betrouwbaarheid en met name een aspect als onderhoudbaarheid bepaalt in hoge mate de kosten op lange termijn. Ook hier manifesteert het verschijnsel van een subjectieve kijk op opbrengsten zich weer, waardoor de kortetermijneffecten domineren. Stopcriteria Testen is nog altijd het onderschoven kindje van softwareontwikkeling. Het zoeken naar een verbeterde, op statistiek gebaseerde teststrategie is een belangrijk onderwerp om testen effectiever en efficiënter te laten verlopen. Voorwaarde bij het testen van informatiesystemen middels steekproeven is echter dat de steekproeven overeenkomen met de verwachte distributiekans van fouten. Een algemene voorwaarde om een verbeterde teststrategie te implementeren is echter dat de start- en stopcriteria van de testfase scherp vastgelegd worden. Deze afbakening komt niet alleen het testen zelf tegemoet, maar draagt met name bij aan het formaliseren van het besluitvormingsproces wanneer een informatiesysteem kan worden vrijgegeven. AUTEUR: Hans Sassenburg Hans Sassenburg (h.sassenburg@bluewin.ch) is zelfstandig adviseur. Hij voert tevens een promotieonderzoek uit, naar vrijgavecriteria, aan de Rijksuniversiteit Groningen.Testen is meer dan een kwaliteitsvoorspelling In het interessante artikel ‘Blind kiezen maakt testen goedkoper’ (Automatisering Gids 26-9) werpt Rob Henzen het idee op om voor testen eens een andere benadering te kiezen dan de min of meer traditionele manier: het op basis van productrisico’s testen met meer of minder testgevallen. De testgevallen worden hierbij (van tevoren) ontworpen volgens bepaalde testspecificatietechnieken. De auteur geeft de voordelen hiervan aan, maar signaleert ook dat dit arbeidsintensief is. Tot zover niets nieuws. Prikkelend wordt het hierna. In het artikel stelt Henzen voor testen te zien als het nemen van een steekproef, met als consequentie dat een beperkt aantal volkomen willekeurige testgevallen een statistisch onderbouwde kwaliteitsvoorspelling kan doen. Dit zou enorm veel geld en tijd aan testen besparen. De auteur maakt in zijn redering echter een belangrijke vergissing door te stellen dat het doel van testen enkel en alleen het doen van een kwaliteitsvoorspelling is. Want stel nu dat uit de steekproef blijkt dat er een substantieel aantal fouten in het systeem zit, hoe moeten we dan verder? Waar zitten die fouten, hoe lossen we dat op? Op zijn best kan de steekproef aanwijzen dat bepaalde delen van het informatiesysteem te veel fouten bevatten (bijvoorbeeld: ‘in deelsysteem A blijkt 15 procent van de steekproef-testgevallen niet het goede resultaat te geven, dit is te hoog’). Deze benadering werkt daarom hoogstens wanneer we een systeem vrijwel zonder fouten verwachten. De realiteit van alledag is echter dat informatiesystemen vóór het testen meestal van onvoldoende kwaliteit zijn om mee in productie te gaan. De schade die dit zou opleveren voor de organisatie is vele malen hoger dan de kosten van een goede test. We moeten na zo’n steekproef dan alsnog gerichte testgevallen gaan ontwerpen om een flinke hoeveelheid van de fouten te vinden, zodat de bouwers deze vervolgens kunnen oplossen. Echter, de programmatuur is al opgeleverd, er is nauwelijks nog tijd om dat te doen. Resultaat: alsnog arbeidsintensief testen en uitloop van het project. Testen is daarom méér dan alleen een kwaliteitsvoorspelling: de informatie die testen moet leveren, moet dusdanig specifiek zijn dat onvoldoende kwaliteit nog kan worden verholpen (weliswaar tegen relatief hoge kosten). Dit lijkt met de geschetste statistische benadering onmogelijk. Willekeurig Ook de kritiek op de testontwerper die de testgevallen maakt met behulp van technieken, is merkwaardig. Goede testgevallen zijn namelijk gericht op het vinden van fouten in het informatiesysteem. Moeten we dit dan vanuit het oogpunt van de statistiek vervangen door veel ineffectievere, randomgegenereerde testgevallen? Want volgens Henzen moeten de testgevallen voor de steekproef volkomen willekeurig worden gekozen, zonder hier verdere uitleg bij te geven of dit wel nodig is. En willekeurig ten opzichte van wat? Bij een steekproef denk je toch aan percentages. Moet 50 procent van de programmastatements worden doorlopen? Of moet een bepaald percentage van de mogelijke veldwaardes worden geraakt (bijvoorbeeld 10 procent van alle mogelijke waardes in ‘leeftijd’ bij personen). Henzen geeft hierover geen duidelijkheid. Ook wordt niet uitgelegd hoe je op basis van de statistieken de kwaliteitsvoorspelling kan doen. Heel jammer, want de manier van steekproef nemen is essentieel om een statistisch onderbouwde uitspraak over de kwaliteit te kunnen doen. Hoge kosten Rob Henzen gaat terecht in op het probleem dat testen steeds duurder wordt en dat we ons moeten afvragen of onze bestaande methodes nog wel voldoen. Het voorgestelde alternatief schetst echter een onterecht beeld, namelijk, dat statistisch testen voor veel minder geld en tijd dezelfde kwaliteit genereert als de huidige testmethoden. Degene die dit gaat toepassen in zijn project, zal vermoedelijk in een laat stadium onverwacht geconfronteerd worden met hoge kosten en uitloop, hét kenmerk van ongestructureerd testen. AUTEUR: Tim Koomen Tim Koomen is R&D-manager Testen bij Sogeti Nederland B.V.

Lees dit PRO artikel gratis

Maak een gratis account aan en geniet van alle voordelen:

  • Toegang tot 3 PRO artikelen per maand
  • Inclusief CTO interviews, podcasts, digitale specials en whitepapers
  • Blijf up-to-date over de laatste ontwikkelingen in en rond tech

Bevestig jouw e-mailadres

We hebben de bevestigingsmail naar %email% gestuurd.

Geen bevestigingsmail ontvangen? Controleer je spam folder. Niet in de spam, klik dan hier om een account aan te maken.

Er is iets mis gegaan

Helaas konden we op dit moment geen account voor je aanmaken. Probeer het later nog eens.

Maak een gratis account aan en geniet van alle voordelen:

Heb je al een account? Log in

Maak een gratis account aan en geniet van alle voordelen:

Heb je al een account? Log in