Testen: mag het een uurtje minder zijn?

Testen is na vijftien jaar nog steeds 'hot'. Bedrijven investeren veel geld in het goed getest krijgen van software. Falende software betekent financiële schade, maar vaak ook imagoschade. Het belang van goed testen wordt dan ook door iedereen erkend. Carlo van Driel en Mario van Os van de A-Groep vinden echter dat het testen een stuk efficiënter en daarmee goedkoper kan worden uitgevoerd zonder daarbij de gewenste kwaliteit te verliezen. Dit kan volgens de senior adviseurs door af te stappen van het idee dat een testmethodiek generiek moet zijn.

Testen wordt al meer dan vijftien jaar als volwaardige activiteit binnen de systeemontwikkeling onderkend. In deze jaren zijn er met wisselend succes testmethodieken ontwikkeld. Algemeen kenmerk van de meeste methodieken is dat ze generiek van aard zijn. Dat wil zeggen dat de methodieken zodanig van opzet zijn dat het altijd mogelijk moet zijn om een testtraject volgens deze methodiek in te richten en uit te voeren. De vraag is: kan dit nog wel in de steeds complexer wordende omgevingen?

Nee. Deze methodieken werken prima in een standaard in-house systeemontwikkelomgeving, maar in een complexe omgeving van bijvoorbeeld uitbesteding, pakketten en infrastructuur zijn deze generieke methodieken niet geschikt. Een specifieke omgeving vraagt ook om een specifieke testaanpak die gericht is op die omgeving. In dit artikel worden de belangrijkste voordelen van een specifieke testaanpak nader toegelicht.

Voortraject

Het voortraject is de belangrijkste fase uit het testtraject. Dit is namelijk de fase waarin de testmanager in de positie is om ervoor te zorgen dat fouten worden voorkomen.

Afhankelijk van het soort ontwikkeltraject zal in het voortraject een specifieke invulling van het testen moeten plaatsvinden. Betreft het een ontwikkeltraject met uitbesteding, dan zal door de testmanager een uitbestedinganalyse worden uitgevoerd waarmee inzicht verschaft wordt hoe alle zaken die relevant zijn in een uitbesteding al dan niet zijn ingericht. Denk daarbij aan releasemanagement, bevindingenbeheer, acceptatieproces, gebruikte terminologie en afbakening van taken en verantwoordelijkheden. Betreft het ontwikkeltraject een wijziging in de infrastructuur, dan zal de testmanager een change- en impactanalyse uitvoeren om te bepalen wat er precies gewijzigd is en waar in het applicatielandschap dit zijn impact heeft.

Daar de enige verstandige aanpak voor het testtraject een risicogerichte aanpak is, zullen vervolgens in een door de testmanager georganiseerde risicosessie met alle stakeholders zoveel mogelijk relevante risico's worden samengebracht en geprioriteerd. Deze risico's worden ingebracht door de stakeholders zelf en onder begeleiding van de testmanager verzameld. De risico's zijn afhankelijk van de wijziging, de omgeving en de ontwikkelmethodiek.

Het is belangrijk dat de specifieke testmethodiek hierin concrete voorbeelden geeft om de stakeholders op weg te helpen en dat voor de testmanager de juiste vragen in die situatie zijn uitgewerkt. Het uiteindelijke doel van de risicosessie is om te bepalen wat de stakeholders gezamenlijk belangrijk vinden zodat daar tijdens de test voldoende aandacht aan kan worden besteed. Het andere doel is om discussies over- en hiaten in de inhoud, verantwoordelijkheden en acceptatiecriteria vroegtijdig inzichtelijk te maken. De resultaten van bovenstaande activiteiten leiden uiteindelijk tot een testplan met bijbehorende teststrategie.

Het is van groot belang dat de specifieke testmethodiek de testmanager en stakeholders bij deze stappen begeleidt en ondersteund. Een generieke testmethodiek kan hieraan geen invulling geven en kostbare tijd gaat verloren in het zodanig plooien van de generieke aanpak dat deze past op het onderhanden traject. Dit gaat ten koste van de tijd die gestoken moet worden in het contact met de stakeholders om te komen tot een weloverwogen risicoanalyse en daaruit voortvloeiende teststrategie. Een specifieke aanpak leidt tot een betere risicoanalyse en teststrategie, geeft meer inzicht in hiaten voordat ontwerp en bouw starten en wordt ondersteund door de stakeholders omdat zij er actief in zijn betrokken. De testmanager bepaalt niet langer de teststrategie, maar de stakeholders zelf! De specifieke aanpak leidt hiermee zelden achteraf tot discussies over de te volgen of gevolgde aanpak omdat deze door de stakeholders zelf is bepaald.

Uitvoering

De winst in uren en daarmee geld zit vooral in de testuitvoering. De traditionele generieke methodieken zijn voornamelijk krachtig in het uitwerken van functionele ontwerpen tot een 100 procent dekkingsgraad. Probleem hierbij is echter dat dit niet langer gewenst is. In plaats daarvan moeten testgevallen worden afgeleid uit de eerder bepaalde risico's en in de bedrijfsprocessen worden geplaatst om te komen tot een test. Dit heeft een aantal voordelen. Ten eerste wordt tijd gewonnen omdat niet het hele ontwerp hoeft te worden overgeschreven naar een testbaar formaat (in bijvoorbeeld beslissingstabellen). Ten tweede wordt door de verdeling van de risico's over de testsoorten voorkomen dat functionaliteit dubbel wordt getest. Ten derde wordt de test beheersbaar omdat de risico's geprioriteerd zijn en vooraf bepaald is wat wel en niet gedaan moet worden om te komen tot de minimaal gewenste kwaliteit. Ten slotte geven de risico's de testanalist geen ruimte om op eigen initiatief tijd te stoppen in zaken waarvan hij vindt dat ze belangrijk zijn. Het zijn de stakeholders die bepalen wat belangrijk is. De testanalist is hierin uitvoerend!

Verdere winst in de uitvoering zit in het beter verlopen en planbaar maken van de testuitvoering. Reden hiervoor is dat eventuele discussies over de te volgen aanpak al in het voortraject gevoerd zijn. Tevens zijn daar eventuele hiaten bekend geworden en is daarop al actie ondernomen. Dit betekent dat in de uitvoering hieraan geen tijd meer verloren gaat. Denk daarbij aan bijvoorbeeld het gezamenlijke releasemanagement of bevindingenbeheer.

Testorganisatie

Een specifieke aanpak betekent ook dat er een verschuiving mogelijk is in de traditionele rolverdeling en wirwar van testfuncties die momenteel gebruikt wordt. Er kan worden volstaan met een testmanager die het voortraject organiseert en begeleidt en de uitvoering aanstuurt. De rol van testmanager kan worden ingevuld door een projectmanager met testervaring of door een testmanager. De uitvoering kan worden gedaan door een testanalist. De rol van testanalist kan worden ingevuld door een beheerder, gebruiker, testanalist, performance-pecialist of testtool-pecialist.

Voordeel is een overzichtelijke platte testorganisatie waarin meer interne medewerkers uit het eigen bedrijf betrokken worden en minder afhankelijkheid van dure extern ingehuurde testcapaciteit. Dit bevordert tevens het kennisbehoud in de organisatie.

Conclusie

Testen is nodig en zal ook nodig blijven in de toekomst. De gebruikte methodieken zullen echter specifiek worden om een efficiënter en goedkoper testtraject te bewerkstelligen. De testmanager kan en zal meer en meer een spil worden in het ontwikkeltraject en de juiste mensen op het goede moment samenbrengen. Tevens zal hij op het juiste moment aan de juiste mensen de goede vragen stellen waardoor testen zich meer en meer gaat richten op het voorkomen van fouten in plaats van het constateren van fouten.

Carlo van Driel en Mario van Os, A-Groep