Testautomation bij de Belastingdienst

Klant

De Belastingdienst wordt gezien als een van de, zo niet de grootste ICT omgeving van Nederland. Het is het overheidsorgaan, dat zich bezighoudt met de heffingen en inningen van belastingen, douanerechten en accijns voor de Nederlandse overheid. Er zijn honderden systemen en applicaties die met elkaar functioneren om er voor te zorgen dat geld geïnd wordt voor de overheid, zodat het verder gedistribueerd kan worden naar alle instanties die het nodig hebben. Denk hier bijvoorbeeld aan de ene kant aan het inwinnen van inkomstenbelastingen, en anderzijds aan de uitbetalingen die het rijk doet. Voor het onderdeel ‘inwinning’ ben ik ingeschakeld om alles met betrekking tot de WOZ (Wet Onroerende Zaak) correct op te slaan als er door ons om gevraagd wordt.

Opdracht

Gemeente software van alle gemeentes binnen Nederland sturen de informatie van de inwoners naar het kadaster. Denk hierbij vooral aan wie waar woont en welke WOZ-waarde het object heeft. De WOZ regelt de waardering van alle onroerende zaken in Nederland ten behoeve van onder meer belastingheffingen in het woningwaarderingsstelsel. Artikel 18 bepaalt dat de waardepeildatum één jaar voor het begin van het kalenderjaar ligt waarvoor de waarde wordt vastgesteld. De waarde van de onroerende zaak in het begin van een kalenderjaar moet dus niet verward worden met de WOZ-waarde voor dat kalenderjaar. Alle onroerende zaken moeten een WOZ waarde hebben. Denk hierbij aan een woning, appartement, boerderij, vakantiehuis, landhuis, schuur, alles wat op een stuk grond staat en geregistreerd is bij het kadaster. Zodra het daar binnen gekomen is, wordt het verwerkt en opgeslagen. Wanneer het nodig is, worden xml-bestanden van het kadaster verstuurd naar de Belastingdienst. Deze komen in een opvangbak, waarna het door onze applicatie wordt opgepakt en verwerkt.

Elk xml-bestand bestaat uit een aantal berichten. Elk bericht is een toevoeging in de database, of een wijziging op een bestaande record in de database. Een bericht kan bestaan uit een groot aantal regels die door onze applicatie worden gesplitst en verwerkt. Elke record komt vers in de database te staan, of er wordt een oude regel opgeslagen en een update komt over het oude record te staan. De belastingdienst kan op die manier altijd de historie van een bepaald object inzien om zo potentieel foutieve waarden met terugwerkende kracht aan te passen. Zodra dit allemaal in een van de twintig databases is opgeslagen en bevestigd met de verschillende andere applicaties, is het werk van onze applicaties klaar en kunnen andere programma’s binnen de belastingdienst de waarden uit de databases raadplegen als ze daar toestemming voor hebben. Als er bijvoorbeeld een inkomstenbelasting wordt gedaan, worden de databases geraadpleegd in de WOZ-waarde zodat deze op voorhand is ingevuld.

Doen

Vooral het verwerken van deze gegevens moet voldoen aan een groot aantal regels. Veld A mag maar een bepaald aantal karakters lang zijn, veld B mag alleen maar nummers bevatten, veld C mag alleen ingevuld worden als veld D is ingevuld met bepaalde waarden enzovoorts. Het testwerk, dat hierbij komt kijken, is vooral het aanleveren van aangepaste xml-bestanden, deze in een lege database schieten en automatisch controleren of de velden de informatie bevatten, die wij verwachten dat ze bevatten. Om dit te controleren gebruiken we Gherkin om de scenario’s vorm te geven, en aan de achterkant Cucumber en Java om de controles uit te voeren. Doorgaans zien onze Gherkin scenario’s er dan ook uit zoals de database, gevuld als data-tables die overeen moeten komen met wat er in de daadwerkelijke databases moet staan. Voor een project wat vooraf relatief eenvoudig klinkt, is het een complexe applicatie in een nog veel complexere omgeving. Maar dat maakt het als mijn eerste backend testsuite wel een mooie uitdaging om mijn vaardigheden verder uit te diepen.