Testa migrerade flöden

Använd verklig meddelandevariation

Testdata som utvecklaren har skrivit själv innehåller de fall utvecklaren redan tänkt på. Produktionshistoriken innehåller de andra.

Plocka fram riktiga variationer:

• stora payloads, och det största meddelande som faktiskt har passerat
• saknade valfria fält, tomma element och oväntade teckenkodningar
• dubbletter och meddelanden som kommer i fel ordning
• en långsam eller nedkopplad motpart mitt i ett flöde
• de meddelanden som historiskt har fastnat — de är er kravspecifikation

Testa felvägarna, inte bara lyckade körningar

De flesta migreringsöverraskningar ligger i felhanteringen, eftersom det är den delen som sällan dokumenterades när flödet byggdes.

Verifiera timeout, retry med backoff, dead-letter, manuell återstart och — viktigast — att en återkörning inte skapar två affärshändelser. Kör samma meddelande två gånger med flit och se efter i mottagarsystemet, inte i loggen.

Jämför semantik, inte teknisk status

HTTP 200 och "workflow succeeded" betyder att plattformen är nöjd. Frågan är om ordern blev densamma.

Jämför utfallet i målsystemet: samma radantal, samma belopp, samma referenser, samma kvittens till partnern. Kör helst samma indata genom båda plattformarna och diffa resultatet maskinellt — en manuell stickprovskontroll hittar inte det som skiljer på en decimal.

Skriv acceptanskriterierna före migreringen

Kriterier som formuleras efteråt anpassas omedvetet till det resultat man fick. Bestäm före flytten vad som ska vara sant för att flödet ska få gå skarpt, och låt någon utanför teamet läsa listan.