"Onder andere vind ik de creativiteit die bij dit project komt kijken leuk. Je moet maar zien te verzinnen, wat een ander allemaal kan verzinnen."
Wat is jouw verantwoordelijkheid binnen dit project?
Het project bestaat uit een generieke backend en een front-end. De backend applicatie – die bestaat uit verschillende microservices – wordt ontwikkeld door een ander team. Doordat de backend generiek is en gebruik maakt van standaarden zoals SIVI AFD, kunnen producten daar relatief eenvoudig op aansluiten.
Binnen het project focus ik me – samen met mijn collega tester – op de front-end generator en alles wat daarmee te maken heeft. Bijvoorbeeld het opstellen van de conceptproducten, waarvan we er op dit moment twintig hebben. Hierin is het belangrijk om de producten niet te groot te maken, omdat dit je testen onnodig kan vertragen. Daarnaast is er binnen de bank een strikte scheiding tussen front-end applicaties en backend microservices, welke in de testomgevingen niet aan elkaar gekoppeld zijn. De interface tussen front-end en backend moet voor de testen dan ook vervangen worden door mocks. Op die manier kan een front-end applicatie los van de backend getest worden.
Wat voor een soort testen voer je uit?
Veruit de meeste testen zijn geautomatiseerd. Dit omvat unit testen, front-end applicatie testen en binnenkort ook contract-based testen om de interface tussen backend en front-end te valideren.
Je kunt je dan afvragen wat precies het verschil is tussen de testen die een productteam uitvoert en de testen die wij uitvoeren. Kort samengevat: het platformteam verifieert are we building the product right. En het productteam kijkt naar are we building the right product. In de praktijk komt dit erop neer dat wij moeten zorgen dat de conversie van een definitiebestand naar een applicatie goed gaat. Bijvoorbeeld: als het product een leeftijd veld specificeert waarbij de klant minimaal 18 jaar moet zijn, komt dat dan correct in de gegenereerde applicatie?
Het productteam kijkt vooral of het product juist gedefinieerd wordt in de definitiebestanden. Is de vertaling van business requirements naar definitie bestanden goed gedaan? Zij moeten erop kunnen vertrouwen dat het platform alles wat zij specificeren correct kan genereren.
Wat maakt dit project interessant?
- Allereerst dat het zo’n uniek project is. In mijn 16 werkjaren in deze sector, heb ik het nog niet eerder op deze manier meegemaakt. Eén repository met verschillende online bankierenomgevingen, waarin alleen frontend-applicaties zitten. Hiermee kan je eigenlijk een lokale versie van het complete online bankierenlandschap starten om je lokale testen op te doen.
- Van oudsher zijn testers gewend om een applicatie in zijn geheel te testen. Het testen van alleen de front-end vraagt om een heel andere gedachtegang. Het principe van Je stopt er voor iets in en achter komt er iets uit ging voor ons niet op, want er zat een ‘gat’ in het midden. Dat ‘gat’ – de interface tussen front-end en backend – moeten we zelf vullen door het schrijven van mocks. We doen dit met behulp van Wiremock. Dit betekent dat je diepe kennis nodig hebt van de interfaces, welke data er heen en weer moet gaan en hoe je tot een correcte set testdata komt.
- Daarnaast vind ik het interessant om nauw in verbinding te staan met de productteams en de broker. In mijn rol ben ik niet alleen bezig met het testen van het platform, maar vooral ook met ondersteuning bieden aan de teams die de producten afnemen. Dat betreft een stukje opleiding over hoe het platform werkt, maar ook het analyseren van problemen.
- Verder vind ik de creativiteit die bij dit project komt kijken leuk. Je moet maar zien te verzinnen, wat een ander allemaal kan verzinnen. We denken veel na over het type producten dat een productteam gaat bouwen en hoe ze ons platform inzetten. Uiteraard is er ook een ervaren business analist die samen met de productteams, broker en andere partijen bepaalt wat er gebouwd moet worden.
Tegen welke uitdagingen loop je aan en hoe ga je daarmee om?
De grootste uitdaging is dat we zelf geen producten hebben in de online bankieren omgeving. Wij bouwen immers alleen de generator om de productapplicaties te genereren. Om te kunnen testen, moeten we daarom een complete pseudo bankierenomgeving bouwen in de front-end repository inclusief applicaties als conceptproducten. Naast het daadwerkelijk testen en automatiseren van testen, zijn we dus ook veel bezig met het maken en onderhouden van conceptproducten.
Bovendien, het aantal testproducten en testen waarover we beschikken brengt ook uitdagingen mee. Veel testen betekent namelijk veel testdata. Daarbij is onderhoud altijd een zorg. Hiervoor hebben we een eigen testdata-generator geschreven waarmee we de testdata genereren. Deze testdata-generator werkt op basis van templates van de verschillende interfaces. In een JSON-input bestand kunnen we wijzigingen op het template beschrijven. Op deze manier hoeven we bij een wijziging van de interface alleen het template te veranderen en de testdata opnieuw te genereren.