Testen in kleine 
projecten: denkwerk

17 mei 2013

Het leveren van kwaliteit is voor projecten met een omvang van enkele weken tot enkele maanden en een beperkte projectbemensing net zo belangrijk als voor grote projecten. Over de noodzaak van testen om de systeemkwaliteit te borgen wordt bij grote en kleine projecten gelijk gedacht. Maar als je kijkt naar de testaanpak zélf zijn er grote verschillen waarneembaar. Grote projecten kiezen voor een gestandaardiseerde testaanpak en kleinere projecten kiezen vaker voor een aanpak die de nadruk legt op de zelfregulering van het team. Daar zijn goede redenen voor als we naar projectleiders luisteren. Maar we zien tegelijkertijd dat juist kleine projecten moeite hebben om grip te krijgen op de effectiviteit van softwaretesten. Vooral bij projecten van beperkte omvang zie je nog te vaak dat het acceptatieproces minder vlekkeloos en minder vlot verloopt dan gewenst. Waar moet verbetering komen om het tij te keren?

Net als grote projecten leggen veel kleine projecten de focus op procesverbetering en specialisatie als de succesratio (overschrijding van tijd, geld en teleurgestelde verwachtingen) tot testmaatregelen dwingt. Onjuist! Veel beter is het om testfasering, testorganisatie en automatiseringshulpmiddelen (efficiency) minder hoog op de prioriteitenlijst te plaatsen en meer aandacht aan de kwaliteit van het testen zelf te besteden. Het is verstandiger de effectiviteit van testen te verbeteren en je niet alleen op een efficiënter testproces te richten.

Niet leuk

Kleine projecten hebben niet de tijd en financiële middelen om specialisten in te zetten voor testen. Ontwikkelaars nemen daarom zelf de rol van tester op zich, maar beschikken niet over de juiste instelling en kennis om de zwakheden van een systeem boven tafel te krijgen. En laten we er niet omheen draaien: veel ontwikkelaars vinden testen gewoon niet leuk. Ontwikkelaars kijken liever of de software werkt dan dat zij zich richten op de onderdelen van de software die niet werken.

Businessvertegenwoordigers kijken vaak met eenzelfde blik naar de software tijdens de acceptatietest. En daar zit dus een belangrijk gevaar. Ook tijdens de acceptatietesten wordt bij kleine projecten vooral gekeken naar de ‘happy flows’ en raken de alternatieve paden buiten beeld. Hoe de programmatuur omgaat met de afhandeling van foute of onverwachte invoer is bij kleine projecten vaak nauwelijks bekeken. Men realiseert zich onvoldoende dat daarmee ook het grootste gedeelte van de opgeleverde software buiten het blikveld ligt en ongeveer tachtig procent van de software onkundig of niet getest in productie wordt gezet. Deze ‘Monte Carlo-testaanpak’ wordt afgestraft in de productiefase. De falende software leidt dan direct tot productiviteitsverlies en de softwareontwikkelaars zijn niet meer beschikbaar voor analyse- en herstelwerkzaamheden.

Maar hoe pak je testen aan als je niet meer dan twintig procent van het budget kan besteden aan testwerkzaamheden? Hoe richt je een evenwichtig testproces in voor kleinere projecten en zorg je ervoor dat er voldoende tijd en geld resteert voor de softwareontwikkeling en implementatie zelf?

Intuïtie

Succesvol testen is niet alleen afhankelijk van de testkennis. Technische kennis, materiekennis en sociaal-communicatieve vaardigheden zijn minstens zo bepalend voor een succesvol testtraject. Maar bij een klein team dat al jarenlang en vaker met elkaar samenwerkt speelt nog een andere succesfactor mee: intuïtie. Zo’n team kan daar tijdens het testen makkelijker op vertrouwen dan een omvangrijk team of een team dat sporadisch samen opereert.

Deskundige testers ontwikkelen een neus voor fouten. In kleinere teams is een intuïtieve testaanpak vaak ook erg effectief. Testers die al langere tijd in hetzelfde team meedraaien weten precies de vinger op de zere plek te leggen. Zo’n tester moet je niet voor de voeten lopen met een theoretische testaanpak en controleactiviteiten.

Controle op de juistheid van software is een belangrijk element van testen, maar is niet het enige wat belangrijk is. Ontdekken, onderzoeken, exploreren van de softwarekwaliteit is eveneens van belang. Een tester met de juiste intuïtie en een onderzoekende, analytische geest – die al jaren in het team zit – weet je soms meer over softwarekwaliteit te vertellen dan een tester die ‘koud binnenkomt’ en driftig aan de slag gaat met testtechnieken.

Denkwerk

Ook bij kleinere projecten moet tijd gereserveerd worden voor het echte denkwerk. Dat hoort bij testen. Een ontwikkelaar of businessvertegenwoordiger prikt makkelijk door vage en onduidelijke requirements, specificaties of acceptatiecriteria heen als hij over testen nadenkt. Nadenken over testen is een uitstekend middel om zaken helder te krijgen. Vroegtijdige signalering van onduidelijkheden en misvattingen is pure winst voor systeemkwaliteit en verdient zich later ruimschoots terug. De omvang van het project doet daarbij niet ter zake.

De afwezigheid van dit bewustzijn wordt bij een groter project vaak gecorrigeerd door een formele testaanpak. Maar bij kleinere projecten is dat meestal niet het geval. Testen zal dan nooit het niveau van plichtsgetrouw afvuren van listigheden aan het einde van het ontwikkeltraject overstijgen.

Kortom, neem dus ook bij kleine projecten de tijd om na te denken over wat en hoe er getest gaat worden. En laat het denkwerk en de tijd die voor testen gereserveerd wordt niet uitsluitend afhangen van de noodzaak en de (financiële) ruimte die in het project is overgebleven.

Eindspel

Kleinere projecten hebben de naam minder van belang te zijn, waardoor acceptatie bestaat uit het onvrijwillig uitvoeren van een test door een of meer businessmedewerkers die wat ruim in hun tijd zitten. Voor een deel is die redenering wel te volgen. Maar men moet zich realiseren dat als een klein project niet exact oplevert wat men heeft gevraagd, het resultaat ook weer snel aan de kant wordt gezet. Door vroegtijdig en gericht aandacht te geven aan zaken die doorgaans pas spelen op het einde van een project (acceptatie en implementatie), versoepelt men het verloop.

Bij aanvang van kleine projecten is de aandacht vooral gericht op de systeemfunctionaliteit en requirements en is niet duidelijk welke criteria gehanteerd worden bij de acceptatie door de business en de onderhoudsafdeling. Juist die acceptatiecriteria geven richting aan de acceptatietesten en voorkomen dat de acceptatietest een herhaling van zetten wordt ten opzichte van de testen die de ontwikkelaars – met kennis van testzaken – hebben uitgevoerd. De acceptatietest moet dekkend zijn ten opzichte van de acceptatiecriteria, zoals de ontwikkeltest dekkend moet zijn ten opzichte van het systeemontwerp. Maar daar moet het niet bij blijven. Ook de antwoorden op eventuele implementatievraagstukken moeten al vroegtijdig in beeld zijn. Want juist daar gaat het vaak mis. Zelfs bij projecten waar de realisatiefase vlekkeloos verloopt, zie je dat het enthousiasme ophoudt wanneer de implementatiefase langer duurt dan verwacht.

Daarom is het verstandig testen al in een vroeg stadium in te plannen. Zo krijg je tijdig inzicht in de mate waarin het systeem past in het bestaande landschap van apparatuur, client/server-componenten, licenties, diskruimtes, netwerk en systeemsoftware. Je voorkomt dat de implementatie zelf een klus wordt waar vooraf geen rekening mee was gehouden, en net zoveel tijd in beslag neemt als de ontwikkelfase zelf. Anticiperen, door infrastructurele vraagstukken al vanaf het begin in de scope van testen te betrekken, is juist bij kleinere projecten van groot belang.

Acceptatiecriteria

Ook in een klein project zijn acceptatiecriteria van groot belang. Zij geven – als er minder tijd en financiële ruimte is om de systeemeisen uit te werken – het houvast dat nodig is om het acceptatieproces niet te laten ontsporen. Acceptatiecriteria scheppen duidelijkheid. Er is aan voldaan of niet aan voldaan, er is geen grijs gebied. Acceptatiecriteria zijn nodig om:

  • richting te geven aan het bouw- en testproces en om het begrip te vergroten;
  • functionele en niet-functionele eisen te concretiseren;
  • de compleetheid, haalbaarheid en onderlinge consistentie van verwachtingen en eisen te borgen;
  • grenzen te stellen aan het kwaliteitsonderzoek.

Acceptatiecriteria mogen in kleine projecten niet vergeten worden. Zij leiden tot meer begrip, meer focus en meer controle bij alle projectmedewerkers.

 
Lees het hele artikel
Je kunt dit artikel lezen nadat je bent ingelogd. Ben je nieuw bij AG Connect, registreer je dan gratis!

Registreren

  • Direct toegang tot AGConnect.nl
  • Dagelijks een AGConnect nieuwsbrief
  • 30 dagen onbeperkte toegang tot AGConnect.nl

Ben je abonnee, maar heb je nog geen account? Laat de klantenservice je terugbellen!