3.  Regel hulp van testers voor de doelapplicaties

Je kan niet alle testen zelf of met een eigen team uitvoeren omdat je daarvoor nooit alle kennis in huis hebt. Regel daarom via de backlogs hulp van scrum of DevOps teams. Organiseer een scrum of productowners om uit te leggen waarom een gezamenlijke test uitvoeren belangrijk is en wat het doel ervan is. Gebruik hierbij duidelijke user stories en maak van de gelegenheid gebruik om alle betrokken teamleden kennis met elkaar te laten maken; het werkt immers veel sneller en makkelijker als mensen elkaar een keer ontmoet hebben.

4.  Gebruik een testset; hoe kom je aan testdata vanuit productie?

Om aan te tonen dat de nieuwe systemen overweg kunnen met de gemigreerde[RF1]  data moeten de testers van de doelapplicaties testcases uitvoeren. Maar omdat de normale synthetische gevallen bij migratietesten niet beschikbaar zijn moet je vooraf de gewenste testdata inventariseren. Doe dat als volgt:

• selecteer samen met productowners, buniness analisten of product specialisten de testdata;
• gebruik queries vanuit productie of selecteer vanuit een bestaand datamanagement systeem;
• zorg voor meerdere gevallen per gewenste selectie. De data kan immers veranderen voordat de integratietest wordt uitgevoerd, een product kan uit de handel worden genomen, een contract kan worden beëindigd, etc.

5.  Meerdere testcycli om de testen uit te voeren

Zorg voor meerdere testcycli. Meerdere korte testcycli hebben de voorkeur omdat een team dat in de eerste cyclus nog niet gereed is of geen tijd heeft, dan kan aanhaken in één van de volgende cycli. Let er daarvoor wel op dat je de productiedata vaker kunt kopiëren, bijvoorbeeld via een bestaande productiekopie. Twee tot vijf cycli zijn meestal voldoende, maar dit hangt ook af van de kwaliteit van de opgeleverd software, de complexiteit van de doelapplicaties en de duur van de testcycli. Iedere testcyclus bestaat uit:

• installeren van de testomgeving,
• uitvoeren van de datamigratie,
• testen van de doel applicatie(s).

6.    Gesynchroniseerde testomgevingen

Als de testomgevingen van de verschillende doelapplicaties niet gesynchroniseerd zijn dan loopt een test eenvoudig in het honderd. Bijvoorbeeld wanneer de één op donderdag en de ander op vrijdag kopieert om er vervolgens achter te komen dat in de interfaces op datums gecontroleerd wordt. Of als de één gebruikmaakt van een standaard back-up van het systeem die na de batches wordt genomen, terwijl bij de ander die backup voor de batches wordt gemaakt. Daardoor loopt de batch van de tweede tester in een error. Zorg er om dit te voorkomen voor dat de doelaplicaties gesynchroniseerd zijn:

• Neem de activiteiten voor het kopiëren van de productieomgevingen gedetailleerd op in een draaiboek.
• Breng de verschillende partijen bij elkaar om het draaiboek door te spreken.
• Zorg voor een droogtest van het draaiboek.
• Voer dit draaiboek uit bij de intaketest.

7.  Houd rekening met defects door slechte datakwaliteit

Ook al heb je de data van tevoren geschoond, houd rekening met bevindingen door data vervuilingen die over het hoofd zijn gezien. Batches zijn daarbij kwetsbaarder omdat deze meestal alle data doorlopen; in het ergste geval klapt de belangrijkste batch van de doelapplicatie eruit en kan je niet verder met de testuitvoering. Bij online transacties kan je de niet geschoonde data omzeilen door een ander testgeval te kiezen. Zaken waarmee je defects door slechte data kwaliteit zoveel mogelijk kunt voorkomen:

• Pas de data direct aan in de testomgeving als de test niet verder kan worden uitgevoerd.
• Zorg dat er een schoningsteam stand-by staat om de data te schonen in de productie omgeving.
• Zorg dat het schonen van de data herhaald kan worden. Bij een nieuwe kopie van productie kan het immers weer nodig zijn.

8.  Wees voorbereid op onverwachte bevindingen

Zeker als je data migreert uit oude bronsystemen zonder goede documentatie, kan je onverwachte bevindingen tegenkomen. Denk aan euro’s die centen zijn geworden, onverwachte productypen, andere klantsoorten of onbekende factuur statussen. Dit is juist één van de redenen om met productiedata te testen! Denk aan het volgende:

• Zorg voor een goede bevindingenadministratie, toegankelijk voor alle betrokken teams. Wij gebruikten bij de migratietesten Defect Management van HP ALM.
• Zorg dat de business analisten aangehaakt zijn zodat zij deze soms lastige bevindingen uit kunnen zoeken.

9.  Gebruik een draaiboek dat groeit naar een migratie draaiboek

Veel migraties lopen schade op of mislukken omdat de acties niet vastlagen of niet in de juiste volgorde zijn getest. Zorg daarom dat alle uit te voeren acties van de teams in een draaiboek worden vastgelegd. In het begin zijn alleen de essentiële IT-acties voldoende, zoals: “Maak een extract van de klantdata”, “Verzend het klantenextract via XFB naar de Converter” of “Transformeer de transacties van bestanden X en Y naar bestand Z”. Zorg dat het draaiboek groeit naar een migratie draaiboek en dat dus ook alle validatie acties, handmatige acties, communicatie, besluitvormingsacties worden opgenomen. Enkele tips bij het opstellen van een draaiboek:

• Gebruik Excel of als het complexer is Microsoft® Project. Zeker als je veel afhankelijkheden wilt vastleggen is Project erg handig.
• Een uniek ID, een omschrijving, het uitvoerende team, de duur in minuten, de starttijd of afhankelijkheid zijn onmisbare attributen. Houd bij de doorlooptijd ook rekening met administratie en huishoudelijke zaken die worden uitgevoerd. Het zal niet de eerste keer zijn dat de collega die aan de beurt is, net een sigaretje is gaan roken.
• Let speciaal op de mate van centralisatie / decentralisatie van het draaiboek. Een paar tips:

1. Hanteer één draaiboek waarin je alle acties van de teams tot detail opneemt. Dat voorkomt problemen met versiebeheer en afstemming van draaiboeken. Ook is het voor iedereen duidelijk welke stappen uitgevoerd gaan worden en welke afhankelijkheden er tussen de detailstappen van de teams zijn.
2. Zijn teams gewend om hun eigen invoeringen met hun eigen draaiboek (template) uit te voeren? Dwing hen dan niet om alle acties op te nemen in een centraal draaiboek. Gebruik als alternatief een overall draaiboek en detail draaiboeken. Zorg wel dat overkoepelende stappen uit de detail draaiboeken worden opgenomen in het overall draaiboek. En ook alle acties die samenhangen met acties van andere teams. Natuurlijk kan je teams die wel willen integreren volledig opnemen in het overall draaiboek.

10.  Denk aan het eventueel testen van het oude bronsysteem

Als bij een volledige migratie het bronsysteem helemaal “leeg” getrokken wordt, dan is een eenvoudige test van het stilzetten van dat systeem vaak genoeg om vast te stellen dat systemen rondom het bronsysteem daar geen last van hebben. Je moet een bronsysteem wel uitvoeriger meenemen in de testcycli als:

• een deel van het bronsysteem nog wel gebruikt wordt;
• de migratie een zogenaamde close/open techniek bevat. De data wordt dan in de bron gesloten/beëindigd en in het doel systeem geopend/gestart;
• bij oudere mainframe systemen bestanden niet meer verstuurd worden vanuit het gemigreerde systeem. Een ander systeem verwacht zo’n bestand nog wel en trekt aan de noodrem.

De Dress Rehearsal als belangrijk toetje

In de integratietest is de focus vooral gericht op de data en de applicaties. Maar als een migratie langer dan een dagdeel duurt , moet er ook aan andere zaken gedacht worden. Bijvoorbeeld huishoudelijke zaken (het pand is niet open op het afwijkende tijdstip waarop de migratie plaatsvindt) en de besluitvorming (de Finance afdeling komt op de valreep nog met een extra eis). Met een zogenaamde Dress Rehearsal kan je al deze zaken beproeven. De Dress Rehearsal is de laatste repetitie waarbij je alles uitvoert zoals het straks bij de daadwerkelijke migratie gaat, maar dan in de testomgeving. Het organiseren van zo’n Dress Rehearsal is best pittig! Een paar aandachtspunten:

• Voer de Dress Rehearsal uit op een zelfde tijdstip als de echte migratie. Is de echte migratie op een zondag? Doe dan ook de Dress Rehearsal op een zondag. Anders bereik je je doel niet: je komt er dan niet achter dat de lichten niet automatisch aangaan in het weekend. Of dat de achterdeur voor de rokers niet opengaat. Of dat er in het weekend huishoudelijke batches draaien.
• Voer de Dress Rehearsal uit in een afgeschermde testomgeving.
• Zorg dat het draaiboek in een productiestaat is.
• Alle teamleden en betrokkenen draaien bij voorkeur tijdens de Dress Rehearsal dezelfde diensten zoals ze dat ook tijdens het migratie weekend gaan doen.
• Dit geldt overigens ook voor een directeur die in het echte migratieweekend het besluit neemt. Dan doet die directeur dat ook in de Dress Rehearsal. Ook als dat betekent dat hij daarvoor om drie uur in de ochtend moet opstaan.
• Zorg goed voor je collega’s! Vaak voer je een migratie op een incourant tijdstip uit. Waarbij je wel verwacht dat iedereen messcherp is. Regel het eten. Als het nodig is: ontbijt, lunch, diner en eten in de nacht. Zorg ook voor gezonde snacks. Breek door lastige procedures heen als het moet. Je wilt niet vijf afdelingen ver moeten lopen voor een hapje en een drankje. Regel daarom desnoods een koelkast en een magnetron op de werkvloer. En ook extra vuilniszakken en schoonmaakdoekjes.
• Zorg dat je de telefoonnummers van alle betrokken teamleden beschikbaar hebt. En natuurlijk ook alle nummers van beveiliging, logistiek en andere betrokkenen. Als het bij de toegang tot de parkeergarage al fout gaat, dan is het heel fijn wanneer je het nummer van de juiste afdeling of persoon bij de hand hebt.
• Bij een Dress Rehearsal mogen zaken misgaan. Je wilt er juist van leren. Gebruik een logboek waarin je alle bevindingen opneemt. En voer na de Dress Rehearsal een evaluatie met alle betrokkenen uit. Verwerk de geleerde lessen in het plan van aanpak voor de echte migratie.

Pilot in productie

Mochten de hiervoor genoemde maatregelen niet voldoende zijn om de zorgen van de besluitvormers weg te nemen, voer dan ook nog een migratie pilot uit. De keuze om dit te doen kan echter enorme impact hebben op de migratiesoftware en de doelsystemen. Zorg daarom dat de beslissing hierover al in het voortraject bij de test strategie wordt genomen. Een migratie pilot is een echte migratie van een deel van de totale populatie. Betreft de echte migratie 100.000 contracten van zakelijke en particuliere klanten, migreer bij de pilot dan vijf representatieve zakelijke en vijf particuliere contracten. Dit kunnen vrijwillige klanten zijn of personeel. Zijn de risico’s hiervan te groot? Dan kan je ook testklanten laten opvoeren via de normale wegen. Indien nodig geautoriseerd door de Finance of Risk afdeling. Maar denk eraan dat het opvoeren van test-objecten niet altijd zo eenvoudig is, bijvoorbeeld wanneer een burgerservicenummer een verplicht invoerveld is. Voer de migratie pilot exact hetzelfde uit als de echte migratie. Iedere afwijking geeft immers een extra risico voor de echte migratie. Na de migratie pilot voer je representatieve use cases uit met de gemigreerde data. Gebruik hiervoor ook weer een draaiboek dat afgestemd is met de stakeholders. Zorg dat de belangrijke business partijen of product owners input leveren voor de use cases. Zij zijn immers degenen die het beste gevoel hebben bij wat de klant denkt, vindt en doet met applicaties die gebruik maken van jouw gemigreerde data. Zorg dat alle teams op de hoogte zijn van deze use cases zodat zij bevindingen direct aan jou doorgeven.