Kartläggning av Komplexa System

1. Kartläggning av komplexa system
Ett komplext system, som t.ex. en dator, tablet eller smartphone, beter sig
inte alltid som man förväntar sig. Beroenden och delade resurser gör att en
förändring i en del av systemet kan ha omfattande och oanade konsekvenser
någon annanstans.
Låt oss anta att vi har ett sådant system, och får i uppgift att säkra att den
senaste veckans integrationer inte har påverkat systemet negativt.
Testledaren ber oss göra en riskanalys för att sedan återkommer med estimat
för hur mycket testning som bör utföras för att mitigera risken. Vi tittar på
vilka integrationer som har gjorts, vilken eventuell påverkan de kan ha på
komplexa systemet, hur de individuella kodänd ringarna har testats innan
integration, vilka riskområden som identifierats vid tidigare systemtester,
och en massa andra faktorer. Vi tycker att vi har en bra bild av hur
integrationerna slår på systemet och planerar vår testning därefter, som vi
sen skickar till testledaren.
Det låter rätt enkelt i teorin. Problemet är då att verkligheten, i det här fallet
ett komplext system, sällan är så enkel.
Ett komplext system, per definition, är oförutsägbart. Att försöka förutse det
komplexa systemet genom riskanalys blir problematiskt. Man kan så klart
göra en massa antaganden om systemet och göra en grov estimering av vad
som kommer att behöva göras, men så fort man försöker detaljplanera vad
som behöver testas baserat på antaganden och gissningar är det lätt att något
går fel.
Hur går man då vidare med detta? Ett teoretiskt tillvägagångssätt är att
skingra komplexiteten genom att kartlägga hela systemet; beroenden,
resursanvändning, timing, osv. och på detta sätt göra det enklare att välja ut
vad som ska testas. Men det är en monumental uppgift, som växer med
systemets storlek och komplexitet. Små, enskilda delar av systemet kan
kartläggas och förstås i detalj, men sällan mer än så.
Ytterligare ett teoretiskt tillvägagångssätt är att skaffa supertestare som helt
enkelt förstår systemet så bra, och har sådan insikt, att problemet inte längre
blir komplext.
Ett annat sätt, som är mer praktiskt till sin natur, är att börja med en väldigt
grov planering, där testaktiviteten alltid inleds med en utforskande
testsession vars mål är att tillfälligt skingra systemets komplexitet , för att i
sin tur tillåta en mer detaljerad planering. Jag säger tillfälligt skingra,

2. eftersom den information vi får bara gäller för den version av systemet vi har
just nu, och inte den version som kommer nästa vecka med en massa nya
integrationer. Bilden nedan illustrerar kanske resonemanget bättre.
Detta betyder alltså att tiden och kostnaden innan den faktiska vanliga
testexekveringen påbörjas är högre. Det innebär också att testledaren
inledningsvis får en grövre planering än vad han kanske vill ha. Och detta
upprepas för varje testaktivitet.
Vinsten däremot blir en mer effektiv testning av det komplexa systemet, och
en detaljerad planering som inte är baserad på (lika mycket) antaganden och
gissningar.
Den grundläggande utforskande testning har då som syfte att , med hjälp av
den förståelse för det komplexa systemet man har inledningsvis, gå igenom
systemet för att hitta de områden där risken för introducerade fel är stor, så
att man kan planera tillräckligt med testning för att mitigera denna risk.
Detta var några av mina reflektioner kring ämnet. Inget direkt nytt, men
kanske väcker resonemanget några nya frågeställningar.
/Johan Hoberg