Ketentests bij systeemimplementatie:
een aantal valkuilen

Controle op datakwaliteit voor pensioenfonds

Het is bekend bij iedereen in de pensioen- en levenbranche die ooit betrokken is geweest bij testtrajecten: testen gebeurt niet voor niets. Testprocedures leveren altijd informatie op over zaken die nog niet in orde zijn, zoals een verkeerd lettertype op een automatisch geprinte brief, een verkeerde berekening of een blokkerend issue voor een groot aantal polissen. Zonder uitvoerige tests voorafgaand aan systeemimplementaties, migraties of bijvoorbeeld de inrichting van nieuwe processen, is het ondenkbaar dat het nieuwe onderdeel live gaat. In dit artikel belichten wij een aantal belangrijke valkuilen met betrekking tot ketentests.

Voorbeeld: Een fiasco door te beperkte ketentests

Bij een grote verzekeraar vond een systeemimplementatie plaats voor een omvangrijk portefeuille. Omdat het de verzekeringstechnische administratie betrof, had dit impact op alle operationele processen en op het gehele applicatielandschap. Door diverse tegenvallers in de analyse- en ontwikkelfase, ontstond een flinke uitloop in de planning. Deze uitloop werd grotendeels opgevangen door het inkorten van de gereserveerde tijd voor de ketentests. Ook werd de scope steeds verder beperkt voor de eerste Golive. De deadline moest kostte wat kost behaald worden.

Doordat de tijd voor de ketentests was ingekort, was er geen tijd gereserveerd voor het oplossen van grote bugs in de laatste fase voor de livegang. Men was ervan overtuigd dat deze bugs allang aan het licht gekomen zouden zijn voor de start van de ketentests. De ketentests werden gezien als formaliteit: Alle applicaties en procesonderdelen waren al uitvoerig getest in unit-, systeem- en gebruikerstests, wat zou er dan nog mis kunnen gaan?

Helaas, er ging heel veel mis.

Valkuil 1: Te weinig tijd voor debugging na ketentests

De interfaces waarmee de applicaties met elkaar communiceerden, bleken niet op het juiste moment de juiste data door te geven. Hierdoor werden premies voor een enkele polis meermaals geïncasseerd. Om deze bug op te lossen moest de programmatuur van diverse systemen aangepast worden. Dit zou minstens twee weken extra tijd kosten, tijd die de verzekeraar niet had.

Valkuil 2: Alleen happy flow getest in ketentests

Daarnaast bleek er een probleem te zijn met het printen van de klantcommunicatie. In elk betrokken systeem verliep dit proces naar behoren, maar bij het testen van de keten bleken de adresgegevens overschreven te worden door lege velden indien een kopie van de klantcommunicatie naar de adviseur gestuurd moest worden. De klantcommunicatie was inhoudelijk getest voor alle voorkomende gevallen, als onderdeel van de functionele tests van de nieuwe applicatie. In de latere ketentests waren echter alleen de meest simpele gevallen opgenomen in de testscenario’s.

Valkuil 3: Overhaaste acceptatie van laatste fix

Er werden extra resources ingezet om de problemen op te lossen. Na een aantal avonden overwerk leken de bugs opgelost, een korte test toonde positieve resultaten. De fix voor de problemen was net op tijd gereed voordat de implementatie live zou gaan. De goedkeuring van deze fix zorgde samen met de rap naderende deadline voor een definitieve “Go” vanuit het projectmanagement.

Tip: plan voldoende tijd in voor ketentests en debugging

Gevolg

Bij de eerste premie-incasso leek alles voorspoedig te verlopen. Tot duidelijk werd dat de premie voor polissen met een halfjaarlijkse premie-incasso nog steeds meerdere malen werd geïncasseerd. Vanwege tijdgebrek waren deze polissen niet meegenomen in de laatste test na het oplossen van de bug. Ook de klantcommunicatie verliep nog niet correct: in plaats van een lege adressering bleek alle klantcommunicatie nu telkens naar dezelfde adviseur verstuurd te worden.

Gaandeweg in het project waren steeds meer mutaties en polissen uitgesloten voor de eerste Golive, voornamelijk door tijdsdruk. Dit had tot gevolg dat er uiteindelijk tijdelijke workarounds in productie nodig waren. Er ontstond een vergrote foutgevoeligheid bij mutaties. Daarnaast kwamen extra issues in productie aan het licht vanwege deze workarounds. De doorlooptijden liepen hierdoor op tot ver boven de norm.

Resultaat

De verzekeraar was genoodzaakt om een deel van de migratie naar het nieuwe systeem terug te draaien en reparatiewerkzaamheden uit te voeren voor de getroffen polissen. Dit kostte de verzekeraar meer tijd, geld en imagoschade dan wanneer de deadline voor de Golive drie maanden zou zijn opgeschoven.

Tips

Hoe kunt u dergelijke fiasco’s in uw organisatie voorkomen? Hieronder leest u enkele tips:

  • Plan voldoende tijd in voor ketentests en debugging in de laatste fase van het traject. Offer deze tijd niet op als de planning onder druk komt te staan: reparatiewerkzaamheden achteraf kosten doorgaans veel meer tijd en geld.
  • Test niet alleen de “happy flow”: Complexe gevallen moeten ook getest worden bij de ketentests. Het belangrijkste in de ketentests is om compleet te zijn en alle voorkomende scenario’s te testen.
  • Betrek ketenpartijen op tijd in de analyse, zodat zij een duidelijk beeld hebben van de wederzijdse verwachtingen en bij kunnen dragen aan een compleet testtraject. Ze kunnen dan bijvoorbeeld in een vroeg stadium al belangrijke aandachtspunten benoemen.
  • Zorg voor relevante testscenario’s: betrek ontwikkelaars en medewerkers die betrokken zijn geweest bij de implementatie in het voorbereiden van de ketentests. Zij weten welke testgevallen onderscheiden moeten worden om alle situaties te testen.
  • Plan ook voldoende tijd en iteraties in voor regressietests en debugging daarvan. Hoe meer bugs er geïdentificeerd en opgelost zijn voor de start van de ketentests, hoe beter.
  • Zorg voor doorlopende coördinatie tussen alle teams, ondersteund door heldere documentatie, zodat altijd inzichtelijk is wat er op welke plek (niet) is ontwikkeld, gewijzigd en getest.
  • Zorg voor een strak releasemanagement en versiebeheer van omgevingen, zodat er geen tijd verloren gaat door verwarring over de installatie van een bepaalde versie of fix.

Wilt u meer tips?
Wij denken graag met u mee over hoe u uw ketentests het beste kunt organiseren!

Opdrachtgevers

  • Centraal Beheer
  • ASR
  • Delta Loyd
  • Robeco
  • Rabobank
  • Achmea
  • Hibin
  • Centraal Beheer
  • ASR
  • Delta Loyd
  • Robeco
  • Rabobank
  • Achmea
  • Hibin
  • Centraal Beheer
  • ASR
  • Delta Loyd
  • Robeco
  • Rabobank
  • Achmea
  • Hibin
  • Centraal Beheer
  • ASR
  • Delta Loyd
  • Robeco
  • Rabobank
  • Achmea
  • Hibin
  • Centraal Beheer
  • ASR
  • Delta Loyd
  • Robeco
  • Rabobank
  • Achmea
  • Hibin
  • Centraal Beheer
  • ASR
  • Delta Loyd
  • Robeco
  • Rabobank
  • Achmea
  • Hibin
  • Centraal Beheer
  • ASR
  • Delta Loyd
  • Robeco
  • Rabobank
  • Achmea
  • Hibin
  • Centraal Beheer
  • ASR
  • Delta Loyd
  • Robeco
  • Rabobank
  • Achmea
  • Hibin
  • Centraal Beheer
  • ASR
  • Delta Loyd
  • Robeco
  • Rabobank
  • Achmea
  • Hibin
  • Centraal Beheer
  • ASR
  • Delta Loyd
  • Robeco
  • Rabobank
  • Achmea
  • Hibin
  • Centraal Beheer
  • ASR
  • Delta Loyd
  • Robeco
  • Rabobank
  • Achmea
  • Hibin
  • Centraal Beheer
  • ASR
  • Delta Loyd
  • Robeco
  • Rabobank
  • Achmea
  • Hibin
  • Centraal Beheer
  • ASR
  • Delta Loyd
  • Robeco
  • Rabobank
  • Achmea
  • Hibin
  • Centraal Beheer
  • ASR
  • Delta Loyd
  • Robeco
  • Rabobank
  • Achmea
  • Hibin
  • Centraal Beheer
  • ASR
  • Delta Loyd
  • Robeco
  • Rabobank
  • Achmea
  • Hibin
  • Centraal Beheer
  • ASR
  • Delta Loyd
  • Robeco
  • Rabobank
  • Achmea
  • Hibin
  • Centraal Beheer
  • ASR
  • Delta Loyd
  • Robeco
  • Rabobank
  • Achmea
  • Hibin
  • Centraal Beheer
  • ASR
  • Delta Loyd
  • Robeco
  • Rabobank
  • Achmea
  • Hibin
  • Centraal Beheer
  • ASR
  • Delta Loyd
  • Robeco
  • Rabobank
  • Achmea
  • Hibin
  • Centraal Beheer
  • ASR
  • Delta Loyd
  • Robeco
  • Rabobank
  • Achmea
  • Hibin
  • Centraal Beheer
  • ASR
  • Delta Loyd
  • Robeco
  • Rabobank
  • Achmea
  • Hibin