Eric Megens is test- en integratiearchitect bij Hightech Solutions in Apeldoorn.

4 May 2009

Testen lijkt suf, maar het is een belangrijk onderdeel van het ontwikkelproces. Volgens Eric Megens van Hightech Solutions gloort er licht aan de horizon door de oprukkende Agile-methodologieën. Hij doet aanbevelingen over het opzetten van een teststrategie.

Testen heeft een imagoprobleem: het is suf, saai en niet goed voor je carrière. Dat komt ook doordat testen een doel op zich is geworden, bijna een robotische handeling in een geïsoleerde omgeving. Het uiteindelijke doel, het leveren van een goed product, ligt maar al te vaak uit het zicht van het testvizier. Hierdoor is het aantal missers helaas groter dan het aantal voltreffers in testland: het feit dat je schiet, lijkt belangrijker dan dat je raak schiet.

Toolfabrikanten spelen handig in op de robothouding die is ontstaan door tools te beloven die tests automatisch kunnen maken en uitvoeren, op een efficiëntere en goedkopere manier dan voorheen. Dit vergroot het beeld dat testen het verrichten is van een kunstje dat weinig interactie en denkwerk vereist. Doordat de interactie met de andere softwaredisciplines vaak onvoldoende aanwezig is tijdens de projectuitvoering, neemt het onderlinge onbegrip toe. Daardoor blijft het testen onderbelicht en het suffige imago behouden.

De opkomst van Agile en risicogebaseerde testtechnieken hebben de focus echter verlegd naar de menselijke kant van het testen. Door deze ontwikkeling is er veel meer interactie tussen de verschillende softwaredisciplines in het algemeen en de engineers in het bijzonder. Vakmanschap en nauwe samenwerking met ontwikkeling zijn daarbij toch de nieuwe kernwaarden. Het blijkt dat slim testen en het vroegtijdig vaststellen van een teststrategie succesfactoren zijn geworden. Zeker doordat er na elke iteratie of sprint een evaluatie is, waardoor de tests of zelfs de teststrategieën tijdig zijn aan te passen aan de veranderende situatie.

Tijdens de QA&Test-conferentie afgelopen oktober in het Spaanse Bilbao werden deze aspecten nog eens benadrukt door de verschillende sprekers, onder wie opvallend veel mensen uit de Lage Landen: Derk-Jan de Grood van Collis gaf een dynamische Testgoal-masterclass, Roger Derksen van Transfer Solutions hield een heldere keynote over het testen van het T5-project bij Vanderlande Industries en Erik Boelen van QA Consult Services had een ervaringsverhaal over exploratory testing. Deze verhalen kenmerkten zich door een duidelijke teststrategie vanaf de projectstart, waarbij de tester als een spin in het projectweb zit.

 advertorial 

The waves of Agile

Derk-Jan de Grood has created a rich source of knowledge for Agile coaches and leaders. With practical tips to create a learning organization that delivers quality solutions with business value. Order The waves of Agile here.

Patchen

Binnen deze nieuwe ontwikkeling zetten we natuurlijk nog steeds testtools in, maar dan als hulpmiddel vanuit een gedefinieerde teststrategie en alleen gebruikmakend van de opties die daadwerkelijk nodig zijn. Denk hierbij bijvoorbeeld aan de selectie van code-coveragemeting, waarbij we niet alle soorten metingen doen die de tool biedt.

Voor tools is het lastig om zich in te leven in het te testen product, om te bepalen waar het bij een product echt om draait. Dat zijn voornamelijk de niet-functionele requirements. Deze kunnen we alleen maar testen in nauwe samenspraak met ontwikkelaars aan de ene kant en eindgebruikers aan de andere kant. De tijden dat we alleen maar testten om te testen, zijn wat dat betreft voorbij.

Testtools moeten ook kunnen samenwerken vanuit een geïntegreerd proces en in een hele set van ontwikkelgereedschappen. Deze ontwikkelsuite is vaak samengesteld uit producten van verschillende fabrikanten, met ieder een eigen productfilosofie. Toch moet het pakket een geïntegreerd geheel vormen om er fatsoenlijk mee te kunnen werken. Ook hier is het belangrijk dat testers meedenken en worden betrokken bij de integratie van de testtooling in de suite. Dus hoe makkelijk integreren we testmogelijkheden in onze ontwikkelomgeving? Hoe beïnvloedt het instrumenteren van onze code het gedrag, de prestaties en de footprint van onze code? In hoeverre komen testresultaten tot uitdrukking in het promotiemodel van het configuratiemanagementsysteem? Als dit soort multidisciplinaire vragen onvoldoende aan bod komt bij de start van een project, zullen we het gehele ontwikkelproces en het eventuele gebruik van tools meer als een last dan als een lust ervaren.

Hightech_Solution_Megens
Tijdens de QA&Test-conferentie afgelopen oktober in het Spaanse Bilbao won Eric Megens de best paper award met een presentatie over zijn ervaringen in test- en configuratiemanagement.

Het is mijn ervaring als test- en integratiearchitect dat we verder moeten kijken dan onze neus lang is om de teststrategie succesvol te kunnen implementeren in de projectorganisatie. In de wat grotere projecten is er een duidelijke en sterke koppeling tussen test- en configuratiemanagement, een combinatie die tooling vaak niet ondersteunt. Met Telelogic Change en Telelogic Synergy biedt IBM wel de mogelijkheid om change- en configuratiemanagement te combineren, maar door de uitgebreide functionaliteit moeten we deze tools met een duidelijke en uitgekiende configuratie- en teststrategie gebruiken. Een strategie die we tijdens het opstarten van de wat grotere projecten al moeten meenemen. De start van een project staat echter vaak in het teken van de technische haalbaarheid en de realisatieplanning van het eindproduct. Vandaar mijn pleidooi om in dit traject ook alvast aandacht te schenken aan ondersteunende processen en in het bijzonder test- en configuratiemanagement.

Ook deze processen bepalen of een project succesvol zal verlopen of niet, vooral in combinatie. Uit de gekozen test- en configuratiestrategie volgt namelijk de haalbaarheid en planning van de tussenproducten (of releases) tijdens de iteratieve ontwikkeling richting eindproduct. En uit deze context komen vaak risico‘s naar boven die we anders over het hoofd zien, zoals beschikbaarheid en leveringsvoorwaarden van toeleveranciers, samenwerkingsafspraken binnen de eigen organisatie als er meerdere afdelingen bij het project zijn betrokken en technische uitdagingen van tussenproducten die we moeten oplossen.

Ook klanten blijken vaak ineens eisen te hebben ten aanzien van de tussenproducten, waarmee we van tevoren rekening moeten houden. Als deze afstemming pas in een laat stadium gebeurt, is de kans groter dat het project tegen onverwachte problemen oploopt met eisen en planning. Hierbij is de manier van releasen, patchen en problemen afhandelen bij tussenproducten een belangrijk onderwerp van gesprek in een vroeg stadium. Niets is erger dan een releasestrategie uitdenken terwijl de release, of erger de patch, al wordt uitgebracht. Zeker omdat we in die situatie het testaspect wel eens uit het oog verliezen, en dat terwijl de tests toch uitkomst moeten bieden over de kwaliteit. Ongeteste of onvoldoende geteste releases zijn over het algemeen niet goed voor het vertrouwen van de klant in het product en dus ook in het bedrijf.

Standaard kunstje

Hieruit volgt ook automatisch de behoefte van een duidelijk promotiemodel. Dus wanneer en bij welk testresultaat komt de ontwikkelde code in een gedefinieerde en geplande baseline, in de releasekandidaat of in de uiteindelijke release? Procesvragen die meerdere disciplines vroegtijdig moeten beantwoorden.

Verder stelt de gekozen test- en configuratiestrategie eisen aan de ontwikkelomgeving. Denk bijvoorbeeld aan netwerksnelheid en -storage als we met daily builds of zelfs continuous builds aan de slag gaan, zeker als het een multisiteproject betreft. Indien we hier onvoldoende rekening mee houden, weegt dat zwaar op de prestaties van de ontwikkelomgeving. Het resultaat daarvan is dat ontwikkelaars hun code lokaal houden en niet testen tegen de laatste stand van zaken voordat ze hun code inchecken. Testers gaan dan achter de feiten aanlopen, doordat de code in de baseline oud en onvolledig is. Voor hen is het dus schier onmogelijk om relevante tests uit te voeren en daarbij een goede actuele kwaliteitsindicatie te geven. Een gedefinieerde en gevalideerde release maken in deze situatie is helemaal een crime. Van tevoren nadenken over de inrichting van de ontwikkelomgeving voorkomt verspilling van resources en tijd die nodig is voor het herstellen ervan tijdens een lopend project.

Zo blijkt dat succesvol testen meer is dan het gebruik van een tool of het doen van een standaard kunstje: het is een vak met heel wat interactie en ook overlap met de overige software- of systeemdisciplines. Deze synergie geeft een beter risicomanagement, een kortere doorlooptijd en een hogere productkwaliteit. Door Agile-methodes komt de synergie tussen de verschillende vakgebieden vaak nog beter tot uitdrukking. Ook het testen blijkt dan een onderdeel van de projectvoering te zijn, waarbij uiteindelijk de mens bepaalt hoe succesvol dit onderdeel wordt uitgevoerd. Dus testen blijft mensenwerk.