I: Integrationerna - bästa teststrategin

Av Charlotta Carlsson 2020-06-07

Ingen större systemleverans sker väl i dagens IT-landskap utan systemintegrationer*)? Här ställs användarnas vardagliga behov på sin spets. Är integrationerna inte väl definierade och stabila så hjälper det föga hur bra funktionalitet det ena eller andra systemet har i sig självt. Som beställare ansvarar du för att helheten av alla dina integrerade system fungerar hos användarna, därför har du normalt huvudansvaret för systemintegrationstesterna. Därmed inte sagt att systemleverantörerna inte behöver medverka - tvärtom! De behöver också samarbeta med varandra.

Systemintegrationer kommer i så många former och syften så det går ju inte att fastställa EN teststrategi som alltid fungerar. Men jag rekommenderar tre huvudprinciper:

1) Att betrakta varje integration för sig i testplaneringen. När ska den testas, av vem, och hur? Förutsättningarna kan vara väldigt olika.
2) Att planera för mycket samarbete i testerna. Inte bara mellan en huvudsaklig systemleverantör och mottagande verksamhet, utan även med de intressenter som ansvarar för de kringliggande system som ska integreras.
3) Att tänka principiellt i tre typer, eller faser, av test - dessa kan sammanfalla eller vara åtskilda beroende på situation.

Att testa systemintegrationer brukar betraktas som en egen testnivå men jag tycker att det brukar vara svårt att skilja kategoriskt mellan systemintegrationstest och acceptanstest, ansvars- och kalendermässigt. Jag pratar då alltså om läget efter det att enskild systemleverantör redan har testat sitt eget integrationprogram på komponentnivå
(ett API, en filgenerering, en ETL etc). Dvs. när integrationsprogrammen är klara för test inom ramen för en leverans, kanske man kan säga.

Jag tycker istället vi kan definiera tre testfaser för systemintegrationer. Ibland kan de sammanfalla, men det är bra att ha koll på skillnaderna:

A. Test på "teknisk" nivå (inte att förväxla med C nedan, men det behövs oftast utvecklare eller utvecklingsnära testare för att utföra detta): Detta handlar om detaljerade tester utifrån integrationskontrakt eller motsvarande. En test på "fältnivå" - att sådant som datavalidering och felhantering fungerar, t.ex.

B. Test på verksamhetsnivå: Här testar användare att verksamhetsprocessen(-erna) stöds av systemen. Det kan vara en nyskapad process som spänner över flera system, eller kanske bara att ett integrerat system ska fortsätta att fungera precis som vanligt. Denna test kan för all del också innehålla en hel del detaljer i form av regler för datat, t.ex. hur värden ska aggregeras eller presenteras. Regler kan också testas inom ramen för A.

C. Teknisk infrastruktur: Det här är de integrationsplattformar, filytor osv. som behövs för automatisering av integrationerna. Jag har märkt att det är detta som många tänker på i första hand när man pratar om integrationer. Men ofta är test A och B oberoende av att C finns på plats. Man kan manuellt trigga att data förs över på olika sätt. En kollega cyklade till mottagarna med en fil på USB i en testomgång för inte så länge sen! Likväl behövs förr eller senare en test av infrastrukturen.

Med vetskap om testfaserna A, B och C så bör du utreda noga vad som är en smart planering och tillvägagångssätt för varje enskild integration. Ibland finns det redan upparbetade testrutiner för ett integrerat system, ibland är det frågan om helt ny teknisk och kommunikationsmässig mark att beträda.

Frågor att beakta i testplaneringen:
- Vem ska ha samordningsansvaret? (Någon i verksamheten eller hos IT? Eller testledaren?)
- Ska fas A,B,C delas upp eller sker det lämpligast allt i ett?
- Vem ska testa? (utvecklare, användare, tekniker eller alla tre?)
- När ska det ske? (Behöver integrationen testas klart innan vi kan göra andra verksamhetstester? Har vi andra systems planering att ta hänsyn till?)
- Behövs teknisk hjälp till verksamhetstestare t.ex. med att hantera filer?
- Vilka kontaktpersoner finns hos integrationspartners? Vilka behov har de från sitt håll?
- Finns det tillgängliga testmiljöer för kringsystemen? Ska vi själva logga in där och testa eller tar vi hjälp av någon annan?

- Behöver driftmiljön för testmiljöerna på respektive sida av integrationen konfigureras på något sätt för att integrationen ska fungera? (Brandväggar, lösenord m.m.)
- Hur skapas testdata? (Vi kanske vill testa inläsning av en fil på standardformat från en stor aktör som t.ex. en bank men hur får vi dit "våra" testdata på filen?)

- Vilket underlag finns/behövs? (Användningsfall, integrationskontrakt, testfall...)

Samarbete är som sagt en viktig ledstjärna. I de mest lyckade systemintegrationsprojekten jag sett har det genomgående funnits ett iterativt samarbete under utveckling och test mellan dels utvecklare på båda sidor om integrationen och dels utvecklare och användare.

Slutsats för bokstaven I: Varje systemintegration behöver en unik teststrategi.

*) En systemintegration är en definierad dialog mellan två system. De "pratar med varandra" genom att utbyta data mellan sig. Den här dialogen kan se ut på väldigt många olika sätt! Det beror förstås på behovet i den/de verksamheter som de integrerade systemen stödjer.

Datautbytet kan vara enkelriktat eller ske åt båda hållen. Det kan göras momentant, dvs att varje gång som informationen i det ena systemet uppdateras så syns den (eller valda delar av den) även i det andra systemet direkt. Eller tvärtom, att en användare behöver information som egentligen finns i ett annat system och att det då hämtas därifrån utan att användaren behöver veta varifrån det kommer. Det kan också vara så att en viss samlad informationsmängd levereras i klump varje natt från ett system till ett annat. Eller kanske det bara görs en gång om året! 

Det kan vara samma eller två helt olika användargrupper som använder de båda systemen, användare i olika organisationer, eller t.o.m. allmänheten! Att kunna dela data är en strategisk fråga på många plan. Det finns också integrationer med mer "tekniskt" syfte. Ett exempel är att verksamhetssystem "pratar" med organisatonens katalogtjänst, för att synka användarkonton och behörigheter. Ett annat specialfall av integration är beslutsstöds (BI-) system som laddar in data från alla möjliga källsystem i ett samordnat datalager där det sedan går att kombinera information från alla system på nya format.

Det går att tänka sig oändligt många varianter av systemintegration! Något som alltid är viktigt är att definiera vem som är master för informationen, hur transaktionshantering och felhantering ska ske och var ansvaret för datakvaliteten ligger.