Yannick Osselaer over Agile-testen in België en inhouse tooling

| Agile-testen in België en inhouse tooling

Yannick rolde als Vlaamse eventmanager de testwereld in. Sinds 2011 is Yannick werkzaam bij de Belgische tak van Immune-IT. Momenteel test Yannick voor de Federale Pensioendienst (SFPD te Brussel) de website mypension.be, waarop mensen hun toekomstige pensioen kunnen berekenen. Over Agile-testen in België en inhouse tooling.

Eigenlijk heb ik in best wel wat branches getest. In de automobielsector, de telefonie, de spoorwegen, de post en bij drie banken. En dan nu bij de overheid, dat wil zeggen bij de Federale Pensioendienst (SFPD) in België. Ik heb een marketingachtergrond en belandde toevallig in het testen toen ik tevergeefs solliciteerde als eventmanager bij een van de grote ICT-bedrijven in Nederland en België. Door een fout bij HR was er een vacature uitgegaan, terwijl men al lang een eventmanager had gevonden. Maar ze hadden wel testers nodig. Het was 2007. Ik vond het interessant en na enkele analytische tests ben ik begonnen aan mijn opleiding TMap in Vianen.

In België, waar ik vandaan kom, was er destijds niet echt een grote markt voor testen. TMap en ISTQB stonden er nog in de kinderschoenen. Maar er is wel een inhaalslag gemaakt. Eigenlijk is inmiddels alles wel Agile in België, developers werken zij aan zij met testers en analisten. Ik heb ongeveer een half jaar in Nieuwegein gewerkt en gewoond, maar nadat Ribank fuseerde met Interbank mocht het volledige testteam opstappen en ben ik naar België teruggekeerd. Ik ben toen begonnen bij KBC, ook een bank.

Toen kwam er een mooi aanbod van Immune-IT, dat ook actief is in België. Ik wilde hoe dan ook bijleren en verder groeien. Dat wil ik trouwens nog steeds. Werken in Agile biedt voor de tester veel vrijheid tot zelfontplooiing. Ik ben testcoördinator geweest en testmanager, ik rapporteer zelfstandig – en ik heb ook met XML gewerkt. Maar ik ben van huis uit marketingman, heb dus niet de harde technische achtergrond. Daar zit mijn groei. Ik wil wel meer gaan uitschrijven. SQL-code wordt veel gebruikt, dus ik wil mijzelf daar wel in verdiepen.

Bij de Federale Pensioendienst test ik de frontend en de backend van de website mypension.be. Je kunt nu op de website zien op welke leeftijd je met pensioen mag, ongeacht de sectoren waarin je gewerkt hebt. Volgend jaar moet iedere Belg (werknemer, zelfstandige, ambtenaar) kunnen zien wat zijn toekomstige pensioenbedrag is. Niet alleen wat nu al opgebouwd is op basis van je voorbije loopbaan, maar ook doorberekend naar je pensioenleeftijd – waarbij de website er natuurlijk van uit gaat dat je tot je pensioen onder dezelfde voorwaarden blijft werken. Ik verdiep mij nu vooral in het uitgebreid testen van de complexe regels voor de pensioenberekening (hoe een brutopensioen – na afhouding van solidariteitsbijdrage, ziekte- en invaliditeitsbijdrage - een nettopensioen wordt bijvoorbeeld). De SFPD hecht groot belang aan de correctheid van de bekomen bedragen.

Als ik terugkijk naar mijn ervaring als tester tot nu toe, heb ik wel eens het idee dat er tegenwoordig heel veel tijd kruipt in overleg. Misschien is de grote rol die overleg hier speelt een fase, omdat Agile in België nog een beetje in de kinderschoenen staat. Het Belgische testlandschap ziet er sowieso anders uit dan in Nederland. In België kun je voor testers terecht bij minder partijen en alles speelt zich af binnen de driehoek Gent-Antwerpen-Brussel. Ook kom je soms de taalgrens tegen. Brussel bijvoorbeeld is een tweetalige stad, waar je werkt met veel Franstalige collega's. Dat bemoeilijkt wel eens samenwerking in een Agile-project, zeker als het echt gaat over complexe onderwerpen. Ook de omgangsvormen zijn wat anders. Minder direct. Feedback wordt bijvoorbeeld niet direct besproken met testers.

Verder is automatiseren hier een belangrijk agendapunt. In de pensioenwereld heb je doorlopend te maken met pensioenschalen die moeten worden aangepast in je scripts. Maar de achterliggende berekening blijft vaak hetzelfde, dus zijn er gewoon bepaalde parameters die moeten worden aangepast naar de hedendaagse reglementering. Meestal kan het script eenvoudigweg opnieuw worden gerund.

In ons team wordt eigenlijk alles geautomatiseerd, al ligt het gevaar op de loer dat er bij sommige scripts heel wat tijd kruipt in het aanpassen van de bestaande scripts. Maar aangezien er een gigantische load is, is er geen andere oplossing.

Wij werken met een inhouse tool GLUE. Dat is een automatiseringstool, waarbij input- en outputfiles in een folder worden geplaatst waar ze worden opgepikt. We hebben een XML met daarin informatie over iemands loopbaan, hoe lang iemand in welke bedrijfssector heeft gewerkt en voor welk loon. We hebben ook een XML waarin staat op welke datum deze persoon vervroegd op pensioen kan, effectief op pensioen kan, enz... Tenslotte hebben wij ook een XML per sector (ambtenaar, zelfstandige of werknemer).

Deze data weet Glue allemaal te vinden en hij berekent dan welk pensioen dit met zich meebrengt. GLUE checkt ook of de verwachte resultaten overeenkomen met de berekende resultaten. Wij rekenen soms ook manueel na of deze berekening wel klopt.

Er wordt een pak meer gebruik gemaakt van inhouse tooling; de kostprijs ligt lager en er kan meer specifiek worden geschreven voor een bepaalde test, of een bepaalde manier van werken. Zo heb ik onlangs zelf mijn eerste shell script geschreven om XML-files automatisch om te zetten naar Zipfiles en deze dan te verplaatsen van de éne folder naar de andere waar een ander script deze oppikt. Hier wil ik mij echt verder in verdiepen want een simpel script kunnen schrijven voorkomt dat je dezelfde handeling honderden keren moet uitvoeren. Dit is naast kostenbesparend ook gewoon frustratie vermijdend.