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ändringarna 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, 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.