Faciliterend testen, dichter op de business logica

| Jan Eeftinck Schattenkerk: testcoördinator bij Royal Flora Holland

Jan Eeftinck Schattenkerk is werkzaam bij Immune-IT. Jan is ingehuurd als testcoördinator bij Royal Flora Holland, maar ziet hoe zijn rol zich heeft ontwikkeld door de komst van Agile en Scrum. “Vaak word je nog wel ingehuurd als testcoördinator, maar het old school coördineren van het testproces, dat bestaat bijna niet meer. Als testcoördinator in een Scrumteam ben je meer inhoudelijk betrokken. Je hebt een faciliterende rol en je test zelf ook mee. En dat is alleen maar goed.”

Er is op IT-gebied veel veranderd binnen Royal Flora Holland. Royal Flora Holland is ’s werelds grootste marktplaats voor de sierteelt en heeft een faciliterende rol voor onder andere kwekers. Niet alleen rondom veilingen, maar ook als het gaat om logistiek, betalingsverkeer en advies. Royal Flora Holland is een coöperatie zonder winstoogmerk die wordt gefinancierd door de kwekers die lid zijn. De leden hebben ook stemrecht en krijgen een winstuitkering. In alle opzichten een dynamische omgeving dus. Ook wat betreft IT.

Sinds de fusie tussen de veilingen in Naaldwijk en Aalsmeer, bestaan er verschillende IT-systemen binnen Royal Flora Holland. Het doel is nu om voor het hele concern één groot geïntegreerd IT-landschap te realiseren. Wij zitten nu in een proces waarin de dit landschap wordt vernieuwd en de IT grotendeels wordt geoutsourced. Er wordt daarbij zoveel mogelijk gebruikgemaakt van standaard software. De oude (vaak maatwerk-)systemen worden uitgefaseerd. De nieuwe systemen worden veelal verplaatst naar de cloud. Deze cloud hosting heeft in mijn ervaring het voordeel dat de stabiliteit van de testomgevingen vaak beter is dan bij lokale hosting.

Zelf zit ik op de implementatie van een nieuw CRM pakket. Royal Flora Holland werkt nu nog met een oud CRM systeem dat nauwelijks meer wordt ondersteund door de leverancier en niet goed aansluit bij de ambities van Royal Flora Holland. Het testen bestaat voornamelijk uit het valideren van de inrichting van het nieuwe CRM, het goed laten werken van de interfaces met bestaande systemen, datamigraties, etc. De uitdaging voor dit project ligt in het goed inrichten van het datamodel rondom de klokveiling, met een minimale hoeveelheid maatwerk - en op zo’n manier dat de achterliggende systemen goed blijven werken. Als er één proces bedrijfskritisch is voor Royal Flora Holland, dan is het wel de klokveiling waarmee fysiek (maar ook online) sierteeltproducten worden gekocht en verkocht. Dagelijks gaan daar vele miljoenen euro's in om – en aangezien het nieuwe CRM systeem hier een interface mee heeft, wil je dit onderdeel heel erg goed getest hebben voordat je live gaat.

Rolverschuiving

Wij werken nu in een Agile/Scrumteam waarbinnen ik het testen voor mijn rekening neem. In Scrum wordt van de testcoördinator/tester niet meer verwacht dat hij rapporteert, of dat hij zijn testcases helemaal uitschrijft. Wel geven wij per user story kort aan wat er is getest en wat de resultaten zijn, zodat de Product Owner en andere Development teamleden dit kunnen valideren. Het is soms een uitdaging om andere teamleden ook aan het testen te krijgen, maar als dat lukt zijn er in mijn ervaring goede resultaten te behalen.

Vaak word je nog wel ingehuurd als testcoördinator, maar het old school coördineren van het testproces, dat bestaat bijna niet meer. Als testcoördinator in een Scrumteam ben je meer inhoudelijk betrokken. Je hebt een faciliterende rol en je test zelf ook mee. En dat is alleen maar goed. In Agile/Scrum gaat het ontwikkelen soms zo snel, je mist soms een deel van het voortraject. En toch moet je als tester een oordeel geven over de refinements en user stories, soms met een beperkte documentatie. Dan is het juist heel fijn dat je als testcoördinator dicht op de dagelijkse praktijk zit.

Vanuit je testrol kijk je of er defects zitten in dat wat opgeleverd is. Maar dat is slechts een klein onderdeel van het totaalplaatje: je probeert ook meer vanuit een business oogpunt te kijken. Door een goede beschrijving van je test, kun je inzichtelijk maken hoe een opgeleverde user story in de praktijk uitwerkt (zodat de Product Owner iets gemakkelijk kan accepteren). Ook hier is de rolverschuiving van de testcoördinator in de richting van de dagelijkse testpraktijk een goede ontwikkeling. Je verbeteradviezen worden beter en je kunt sneller kijken naar hetgeen opgeleverd is. Product Owner en leden van het Development team zitten dichter op elkaar.

Automatisering

Ook tooling en het juiste gebruik daarvan worden steeds belangrijker. De bevindingen, het Scrum Board en de Product Backlog etc. worden meestal in één tool beheerd en dat werkt in de meeste gevallen prima. Werk je niet met een dergelijke tool, dan worden vragen en feedback vaak informeel, mondeling, of via de mail afgehandeld. Als je er dan niet bij was, of je hebt de mail niet ontvangen, dan mis je cruciale informatie. Om dat dat te voorkomen gebruiken wij in dit project Yammer – een microblogging-webdienst. De ervaringen hiermee zijn zeer positief: het is transparant en voor iedereen in het team toegankelijk. Iedereen kan op elkaar reageren en de informatie wordt zo vastgelegd dat alles gemakkelijk terug te vinden is. Een paar spelregels zijn hierbij wel aan te raden: stel concrete vragen en meld eindbeslissingen ook expliciet, zodat discussies duidelijk kunnen worden afgesloten. En ook: als een discussie te lang duurt, is een live overleg vaak beter. De uitkomst daarvan zet je dan kort op Yammer.

Testen verankerd

De verschuiving van rollen binnen Scrum breng met zich mee dat je als tester - maar ook als testcoördinator - minder in defects denkt, maar meer in termen van 'is dit wat de business nodig heeft?' De kwaliteit van testen is daarmee vooruitgegaan. Je krijgt ook meteen feedback uit de organisatie – en je test op hele kleine stukjes, waardoor je gerichter test. Je hoeft als tester ook niet meer een uitgebreide en gedetailleerde testanalyse te maken. En dat is tijdswinst want in Waterval trajecten kwam je er achteraf vaak achter dat de testbasis niet klopte, waardoor een groot deel van het voorwerk niet bruikbaar bleek. Dat kost geld.

In het verleden heb ik diverse Waterval projecten meegemaakt waarbij de IT-organisatie zelf al van tevoren aanvoelde dat de oplossing niet aan de verwachtingen van de business zou voldoen – maar het proces niet kon worden bijgestuurd. Uiteindelijk ging het project inderdaad niet in productie en was al het werk voor niets gedaan: niet echt motiverend. In een project met een goedlopende Scrum aanpak, waarbij er continu sprake is van een-tweetjes tussen de IT en de Business, is de kans hier op veel kleiner.

Ook het rapporteren van de testvoortgang staat niet meer op zichzelf zoals in Waterval, maar maakt nu deel uit van de totale ontwikkelsprint. Hierdoor kom je als tester minder snel in de kreukelzone. Wanneer de oplevering minder snel gaat dan gepland, dan is dat in Scrum meteen duidelijk voor iedereen. Er wordt hierdoor minder gezeurd als het testen uitloopt. Scrum heeft er voor gezorgd dat het testen een integraal onderdeel uitmaakt van het ontwikkelproces en niet meer wordt beschouwd als een aparte fase aan het einde van het traject. Het heeft het belang van testen dieper verankerd in de organisatie.