Beheer

Software-ontwikkeling
Belastingdienst

Dit was de echte oorzaak van de aangifteproblematiek bij Belastingdienst

Hoe kon het zo mis gaan na zorgvuldig testen?

© CC BY 2.0 - Flickr mystic_mabel
29 april 2021

Hoe kon het zo mis gaan na zorgvuldig testen?

De Belastingdienst test webapplicaties met veel browsers en doet stresstests, ook al is de software zelf niet gewijzigd. Toch ging het goed mis, begin maart. De Belastingdienst geeft inzage hoe dat kon gebeuren.

Dagenlang konden mensen die begin maart hun aangifte wilden doen, de website van de Belastingdienst niet op. Als dat wel lukte waren vaak verkeerde gegevens ingevuld of stokte het proces ergens. Vorige week gaf staatssecretaris Hans Vijlbrief in zijn antwoorden op Kamervragen van SP-parlementariër Renske Leijten aan dat het probleem zat in de browserkeuze bij de tests die waren uitgevoerd. Maar test de Belastingdienst dan maar met één browser, was een vraag die waarschijnlijk bij veel IT'ers is blijven hangen.

Nee, geeft woordvoerder Jacco Neleman nu aan nadat hij vragen van AG Connect bij de betrokkenen had uitgezet. 

"In het algemeen voert de Belastingdienst meerdere functionele testen uit op de verschillende webapplicaties. Dat gebeurt met verschillende browsers en verschillende versies van onder meer Chrome, Edge, Firefox, Safari en Opera. Deze testen vinden gedurende het gehele jaar plaats op elke nieuwe release die de Belastingdienst uitbrengt."

Test op ongewijzigd systeem

Om piekbelasting in het aangiftesysteem te vermijden maakt de Belastingdienst gebruik van zogeheten toeritdosering, vergelijkbaar met wat bij opritten van de snelweg gebeurt. Er worden steeds zoveel nieuwe mensen toegelaten als het systeem aankan. Die toeritdosering werkte bij eerdere aangifterondes goed, en was eigenlijk niet gewijzigd. Toch is deze opnieuw aan een stresstest onderworpen.

"De toeritdosering in combinatie met de verschillende webapplicaties is onder ‘load’ getest. Dat betekent een test waarbij middels een loadtesttool wordt gekeken hoe deze toeritdosering functioneert bij een groot aantal mensen dat tegelijkertijd wil inloggen. Zo’n loadtesttool simuleert de browser en is gebruikelijk voor het loadtesten van webapplicaties. In het verleden is gebleken dat een loadtesttool even goed functioneert als het testen met meerdere browsers.  Zoals aangegeven in de Kamerbrief kwamen uit deze performancetesten geen problemen naar voren."

Naast het uitvoeren van de geautomatiseerde loadtesten zijn ook nog handmatige testen uitgevoerd, geeft Neleman aan. Zo kon de werking van de toeritdosering met een browser worden gecheckt. In dit geval is gekozen voor Chrome als meestgebruikte browser. De Belastingdienst doet namelijk aan risicogebaseerd testen, dus viel de keuze op de browser met de grootste kans op het optreden van problemen.

Chromium aangepast

Neleman: "Wat zich echter heeft voorgedaan is dat de verschillende browsers waren aangepast qua netwerkgedrag. Die wijziging in het netwerkgedrag zit in het zogenoemde Chromium-component van de browsers. Verschillende browserdiensten hebben het Chromium-component aangepast om de gebruiker sneller van dienst te kunnen zijn. Browserdiensten braken altijd een TCP-sessie af op het moment dat een URL niet bereikbaar was (‘Sorry’-pagina’). De gebruiker diende daarna opnieuw verbinding te leggen om naar de gewenste URL te gaan. Verschillende browserdiensten breken deze TCP-sessie nu niet meer af, waardoor een gebruiker mogelijk sneller de gewenste pagina weer bereikt. Maar doordat deze TCP-sessie niet werd afgebroken, herkende de toeritdosering van de Belastingdienst de gebruiker als iemand die al reeds toegang had. Daarom werd deze ook niet meer tegengehouden, zoals voorheen."

Het gevolg was dat de druk op de systemen groter werd dan waarop ze waren toegerust. Het ophalen van de gegevens van de gebruiker duurde langer dan gewenst en systemen raakten overbelast. Dat dit probleem niet naar boven kwam in de handmatige test, had twee oorzaken: voor de test is niet de allerlaatste versie van de Chromebrowser gebruikt en de handmatige testprocedure gaat niet zo ver dat dit probleem zou worden opgemerkt.

Alleen testen op eerste poging

"Het Chromium component van de specifieke browser was ten tijde van het handmatig testen nog niet aangepast, maar ook als dat wel het geval was geweest, dan hadden we het probleem daarmee niet vooraf kunnen detecteren. Het ging niet mis bij de eerste poging tot inloggen, maar bij een tweede poging (en de pogingen daarna). Bij handmatig testen doe je alleen die eerste poging om vervolgens (als de test goed verloopt) aangifte te kunnen gaan doen", aldus Neleman.

Inmiddels is de toeritdoseringssoftware aangepast zodat het probleem zich bij een volgend piekmoment niet meer kan voordoen. De eerste test was eind maart. Wie dit jaar voor 8 april aangifte deed, kreeg de garantie voor 1 juli uitsluitsel te krijgen over de belastingaanslag. Doorgaans is dat een deadline die veel mensen zichzelf stellen. Een volgend piekmoment is op de dagen voor 8 mei, het moment dit jaar dat iedereen zijn aangifte moet hebben ingediend of uitstel moet hebben aangevraagd.

 

Lees meer over
Lees meer over Beheer OP AG Intelligence
Reactie toevoegen
De inhoud van dit veld is privé en zal niet openbaar worden gemaakt.