Rolf Ekström

Multisourcing - en ny spelplan för testaren

2017-05-17 Artikelbanken Test Läst 131 gånger

Den här artikeln handlar om multisourcing - en viktig trend inom IT organisationer - vad det innebär och hur det påverkar testaren. Läsaren får några handfasta råd om hur man kan agera i sådan miljö. Artikeln spekulerar också om huruvida den här trenden leder till att det behövs mer eller mindre testning i framtiden. Riskerar vi arbetslöshet eller kan vi se fram mot massvis med roliga uppdrag? Gissa - eller läs vidare.

När man arbetar med test märker man snart hur viktigt det är att förstå sin omgivning och kunna anpassa sig till förändringar. Det är viktigt att inte bara förstå applikationen man testar och något om tekniken bakom, utan också vad som utmärker den organisation man arbetar i.

Multisourcing och standardsystem

En intressant trend som pågått ett tag och som inte ser ut att avta är multisourcing, att en organisation väljer att lägga ut sin IT på många olika underleverantörer och där man i största möjliga mån eftersträvar att använda standardsystem i stället för egenutvecklat.

För inte så länge sedan hade de flesta organisationer stora interna IT-enheter med många programmerare som utvecklade och underhöll ett antal system som stödde organisationens verksamhet. Det finns naturligtvis fortfarande på sina ställen, men utvecklingen går mot att lägga ut mer på underleverantörer. Dessutom försöker man dela upp så att man lägger ut olika delar av IT-systemen på den leverantör, intern eller extern, som kan sköta det bäst, så kallad multisourcing. (Jag använder den termen i väntan på att ett svenskt begrepp etableras.)

Drivkrafter

Den stora drivkraften bakom multisourcing är ekonomi.  Man antar att man får maximalt värdeskapande genom att konkurrensutsätta leverantörerna och använda den leverantör som har bäst pris för prestanda. Standardiseringen gör att man inte riskerarar hamna på jobbiga tekniska återvändsgränder utan kan dra nytta av de allmänna förbättringar som sker inom leverantörens system. Det ger tydligare uppdelning mellan beställare och leverantör. Det kan också finnas tankar om att en organisation som använder standardiserade IT-tjänster är lättare att omorganisera och fusionera med andra organisationer.

Något går kanske också förlorat. Det är inte lika lätt att skräddarsy lösningar för organisationen. De hängivna interna resurserna som tagit fram specialanpassade system ersätts men en mängd funktionärer. Det kan också uppstå friktioner mot leverantörerna och mellan olika leverantörer eftersom dessa har olika kommersiella intressen. Sedan återstår också det kanske största problemet, att lyckas integrera alla system till en effektiv och fungerande helhet.

Hur påverkas testarens omgivning

Testorganisationen går naturligtvis också att lägga ut men eftersom testning måste ske nära verksamheten kommer den i stort sett ha kvar sin vanliga roll. Däremot påverkas testningen på flera olika sätt. Borta är de tydliga systemhierarkierna som man läst om i läroböckerna. Ni vet - ett system består av delsystem som består av komponenter, testningen antas först göras av komponenter, för att sedan byggas upp till systemtest och acceptanstest. Istället måste man nu testa i stora mer eller mindre väldefinierade nätverk med interna eller externa komponenter.

Samma sak med projektledningen. Eftersom flera organisationer måste samverka kanske det inte går att organisera det som ett huvudprojekt med delprojekt utan som flera samverkande projekt. Projekten kan ha olika men samordnande mål och olika kommersiella intressen.

Nya utmaningar för testaren

Alla som arbetar med test (testare, testledare, testchef mm) påverkas av att arbeta i en multisourcad miljö. Här är några av utmaningarna:

Testorganisationen måste hantera många olika sorters system – plattformar – tekniker – gränssnitt. Det skiljer sig kanske inte så mycket från hur det alltid varit i stora organisationer. Nytt är dock att testmiljöerna nu inte bara är interna utan måste samordnas över flera organisationsgränser. Det kan vara många IT-tekniska problem som måste lösas innan man kan börja testa – brandväggar, VPN-tunnlar, ip-nummer, certifikat mm. Ibland måste testorganisationen ta initiativet och beställa eller ordna detta.

Testdata måste ofta synkas mellan de olika systemen i den totala testmiljön. Kanske också dataformat, datum och tid. Här kan minsta lilla tuva stjälpa hela lasset och göra meningsfull testning omöjlig.

Under testperioden måste man kunna hantera knepiga beroenden. Förstå vilken del man ska testa i en komplex helhet bestående av den egna organisationens och det egna projektets funktionalitet kopplad till många andra system.

När misstänkta fel uppdagas så är det inte så lätt att analysera vad som är orsaken. Är det något i det distribuerade testdatat, testmiljöerna eller testförutsättningarna som är tokigt eller är det ett riktigt fel som någon bör rätta? Om så är fallet, i vilken leverantörs system ska rättningen göras?

Underleverantörer kanske inte håller med om att felet ligger i deras system. Det kan behövas en övertygande bevisföring för att landa felrapporter och få dem rättade.

Det är ofta nödvändigt att kommunicera med många personer hos många leverantörer, med olika kommersiella intressen, olika regelverk, olika kulturer och språk.

Listan är säkert inte komplett. Vi på Konsultbolag1 arbetar med att samla på oss mer erfarenhet om arbete i multisourcade miljöer och kommer över tid att lära oss själva och våra kunder mer om detta område.

Några handfasta råd

De problem man har att brottas med kan skilja sig mycket mellan olika organisationer men här är några råd som vi har kommit fram till kan vara bra att prova när man arbetar i stora, integrerade, multisourcade miljöer.

  • Försök tidigt få fram, eller rita en egen, arkitekturbeskrivning över alla system för att kunna planera testmiljöer.
  • Se till att testmiljöer är uppkopplade och synkade i god tid.
  • Leta upp duktiga och engagerade personer hos de olika leverantörerna som kan svara på frågor och hjälpa till när det är problem.
  • Försök få inloggningsmöjlighet (användare) i de inblandade systemen så att det går att se vilken effekt testfallen får i andra system. Alltså även i system utanför de system som primärt testas.
  • Håll koll på integrationsordningen mellan leveranser i de olika systemen, styr leveranser för maximal testbarhet tidigt.
  • Lägg in aktiviteten systemintegrationstestning i projektplanen och se till att den är klar innan acceptanstesterna börjar.
  • Använd systemarkitekturen för att tillsammans med kravspecifikationerna ge underlag för att skriva de testfall som visar att systemen är korrekt integrerade.
  • När knepiga problem uppstår tveka inte att koppla upp telefonmöten (t.ex. Skype) med deltagare från de olika systemen för samordnad felsökning och problemlösning. Brukar bli effektivt och ger ofta nya insikter.

Annorlunda – men mer eller mindre?

Och nu till den stora frågan: Kommer det behövas mer eller mindre testinsatser framöver? Läsaren har nog redan börjat ana vartåt det lutar. All erfarenhet som vi hittills samlat på oss tyder på att testinsatsen ökar relativt andra delar i projekten. Det är inte så enkelt att få många system och leverantörer att samverka. Därför krävs det duktiga testare som tillsammans med andra aktörer kan få saker att fungera. Allt för att skapa en fungerande helhet som effektivt tillgodoser kundernas behov i en komplex miljö.

Dela artikeln