1. Test i sin enkelhet
Testning är i sig en väldigt komplex aktivitet med många variabler som
påverkar vad, när och hur den ska utföras. Testning av ett väldigt stort
system, som t.ex. en mobiltelefon ökar komplexiteten ytterligare. I kontexten
av ett internationellt företag med tusentals ● ● ●
anställda på olika kontinenter gör
tidskillnader, kulturskillnader, parallellt Komplex och komplicerad[2]
testande, ansvarsfördelning mellan kontor och En kort begreppsdefinition kan
andra faktorer att komplexiteten blir mindre vara på sin plats. Ett komplext
överskådlig. Om företaget dessutom integrerar system är ett system som inte är
mycket kod från tredje part, blir det ännu förutsägbart, utan mer spontant
svårare att förutse hur systemet kommer att och oordnat och har en dynamik
bete sig. som gör att det skiljer sig från
statiska och förutsägbara objekt
Det är svårt för människor att hantera denna som endast är komplicerade till
typ av komplexitet, men på något sätt må ste skillnad från komplexa. Ett stort
mjukvarusystem har just dessa
detta göras hanterbart för testare ute i
egenskaper, med många subsystem
organisationen.
som interagerar med varandra,
och med hårdvaran den kör på. En
Som testare står vi ofta inför vad som brukar
urvalsmetod som kräver att man
kallas ett ”wicked problem” [1]. D.v.s. ett
tar hänsyn till en mängd data och
komplext problem som inte har en optimal går igenom långa processflöden är
lösning, utan flera, och inte kan lösas utan att komplicerad, men inte
ta hänsyn till en mängd olika perspektiv. nödvändigtvis komplex. När
någonting antingen är fullständigt
Ett sätt att försöka lösa denna komplexitet är förutsägbart, eller helt
att skapa processer, strategier och slumpmässigt är det inte komplext.
kontrollmekanismer för att kunna styra olika
aktiviteter som utförs av testare. ● ● ●
Problematiken kring detta är tudelad; dels
låter komplexa system sig sällan detaljstyras från toppen, dels blir
lösningarna på komplexiteten ofta väldigt komplicerade i sig, vilket skapar
en mängd följdproblem.

2. Detaljstyrning från toppen
För att driva en effektiv testorganisation på ett stort företag är det därför
kritiskt att hela tiden trycka beslut och ägandeskap så långt ner i
organisationen som möjligt. Det finns flera anledningar till detta. Att ta
beslut i komplexa frågor kräver djupare, erfarenhetsmässigt förankrad
förståelse, vilket gör att den abstraherade förståelse som managers,
testledare, gruppledare, eller teststrateger ibland besitter inte räcker för att
ta de detaljbeslut som behövs. Men det är också så
att de faktiska testarna är de som hela tiden ser ● ● ●
förändringarna i systemet och måste anpassa sig
till dem, vilket gör att de som grupp blir mer Antifragile [3]
antifragile än andra grupper vars bild av systemet En lekmansdefinition av
är så abstrakt att de inte påverkas av dessa dagliga , antifragile är någonting
små, evolutionära förändringar. Detta gör att (person, objekt,
testarna, till skillnad från de andra grupperna, är organisation, etc.) som
mer förberedda på att hantera okända problem på blir starkare av
påfrestning (inom rimliga
ett effektivt sätt och inte blir överraskade på
gränser). DNA och
samma sätt eftersom de har stött på så många muskler är två exempel.
okända faktorer i systemet tidigare. De har också
en helt annan möjlighet att se systematik i ● ● ●
problemen de måste hantera, och kan utforma
lösningen efter det. Slutligen driver ägandeskap över sitt eget arbete en
motivation och ett engagemang som överstiger vad t.ex. pengar kan
åstadkomma[4][5]. Engagemang i sig är en förutsättning för t.ex. innovation
och kompetensutveckling, vilka båda är kritiska för en fortsatt effektiv
testorganisation.
Managers, testledare, gruppledare, teststrateger och andra liknande roller
måste därför veta sina begränsningar och lämna denna typ av detaljbeslut till
de som har bäst förutsättningar för att kunna ta dem för sina respektive
expertisområden. Konsekvensen om man inte gör det är en suboptimering av
testorganisationen som blir mer eller mindre allvarlig beroende på kontexten.
Ett följdproblem av att inte lägga besluten i testarnas händer är att deras
karriärutveckling ofta då går via dessa ledarroller och att färre och färre
specialiserar sig på den faktiska testningen, vi lket får ödesdigra
konsekvenser på sikt, då avancerad testkompetens går förlorad.

3. Komplicerade lösningar
Det finns ett egenvärde i enkelhet, och enkelhet kostar [6]. För hur perfekt
en komplicerad lösning på ett komplext problem än är så fallerar den ofta av
en enkel anledning – den mänskliga faktorn. Man kan göra miss tag, man
kanske inte orkar, man kanske inte förstår, man kanske inte ser värdet. Det
finns mängder av förklaringar. Och detta gäller för processer, metoder,
strategier, verktyg och så vidare. En komplicerad metod eller process kan
också göra sken av att vara mer heltäckande än en enkel sådan, vilket
begränsar möjligheten och motivationen för testaren att utnyttja sin egen
erfarenhet och tysta kunskap.
Effektivt urval av testfall är något som universiteten har undersökt . De har
tagit fram olika typer av algoritmer för att plocka fram de testfall (jag
använder ordet här utan att begränsa mig till den traditionella synen på
testfall) ur en mängd som är mest effektiva [7]. Det är också något som drivs
som effektiviseringsåtgärder på företag. Om man har 1000 testfall och inte
har råd att köra alla 1000 så måste man göra ett urval som minimerar den
ökade risken. Problematiken ligger ofta i hur komplicerat det är att göra
dessa urval. Om denna urvalsmetod är för svår att förstå, eller är i för många
steg, så kanske testaren istället väljer att gå på instinkt och erfarenhet, eller
återanvända tidigare gjorda urval. Men det är inget alternativ att inte göra
något urval alls, eftersom man inte kan köra alla testerna.
Lösningen borde alltså vara att göra urvalsmetoden så enkel att den faktiskt
används, men mer effektiv än ingen formell urvalsmetod alls. En metod, med
ett fåtal steg som är enkla att förstå och kan tillämpas oavsett erfarenhet
utan att begränsa eller stjälpa, som tillför värde. Det är också viktigt att
metoden lämnar utrymme för testarens expertkunskap som komplement och
inte gör sken av att urvalsmetoden tar hänsyn till alla variabler i det
komplexa problem som urvalsmetoden försöker lösa. En magisk urvalsmetod
som alltid ger det optimala urvalet av te ster i alla olika situationer existerar
inte om urvalet är komplext, och att ge sken av att vara magisk ger bara en
falsk trygghet. Komplicerade metoder har i många fall svårare att anpassa sig
till nya kontexter, medan enklare met oder inte står inför samma problem,
eftersom komplexa metoder ofta har fler parametrar som kan variera mellan
olika kontexter.
Ett annat exempel på när komplexitet ställer till det är
automatiseringslösningar. Att fö rsöka designa en massiv, komplicerad
automatiseringslösning som t äcker alla eventuella behov är dömt från början
att misslyckas. Problemet är för komplext, och att försöka förutse hur
automatiseringslösningen kommer att behöva bete sig i alla möjliga

4. scenarion är en omöjlig uppgift. Den typen av komplexitet som en
automatiseringslösning innebär kan bara växa fram evolutionärt. Så klart
måste man ha någon slags riktlinjer och tankar från början, men man måste
starta med en enkel lösning som löser en liten delmängd av de behov man har,
för att sedan låta lösningen växa fra m. Man kommer att stöta på problem på
vägen, och nå nya insikter baserat på de framgångar och misslyckanden ma n
möter, men det är också det som kommer att göra automatiseringslösningen
så mycket mer antifragile. Ett system som kan anpassas till nya problem som
uppstår och inte har målat in sig i ett evolutionärt hörn. Modularitet är ett
exempel på en sådan systemegenskap. Lösningen blir baserad på praktisk
istället för teoretisk erfarenhet.
I både urvals- och automatiseringsdiskussionen finns det en möjlighet att
förenkla för testaren via effektiva verktyg. Om testar en har ett enkelt,
välfungerande verktyg i vilket man bara trycker på en knapp och får tillbaka
ett förslag till urval, så kan de underligga nde algoritmerna vara hur
komplicerade som helst – för testaren är det fortfarande enkelt. Sa mma sak
kan gälla för skapandet av automatiska testfall.
Den stora risken med detta är att testaren då plötsligt abstraherar sig från
det faktiska urvalet eller det faktiska skapandet av testfallet, och inte förstår
komplexiteten i aktiviteten, vilket gör testaren mindre antifragile och har
sämre förmåga att anpassa sig till okända framtida problem. Dessutom står
verktygen själva inför samma komplexitetsproblem som testaren . Det finns
alltid risker för att den mänskliga faktorn ställer till det för verktygen också.
Även teststrategier står inför detta komplexitetsproblem. Teststrategin ska
ge stöd och riktning i komplexa frågeställningar, men o m teststrategin är
komplicerad kommer testare att helt enkelt strunta i de delar av den som de
inte förstår, och tolka strategin olika. Konsekvensen av detta blir att
organisationen inte har en enhetlig strategi. Vad organisationen måste göra
är helt enkelt att skapa en enklare, kanske något mindre fullständig strategi,
för att säkra att den faktiskt följs. Det kostar som sagt att förenkla, men det
är värt den kostnaden i slutändan. Det är också viktigt att låta testaren själv
sköta detaljeringen av strategin, eftersom det endast är här kompetensen
finns för detta. Här bör organisationen se till att det är enkelt för testaren att
göra denna detaljering, i form av mallar och riktlinjer som stöd i arbete t.
Att en komplicerad process bara är en pappersprodukt är också något som
kan inträffa om det faktiskt går att förenkla processen. Ofta skrivs en sådan
komplicerad process av någon som inte är tillräckligt praktiskt insatt i
verksamheten, och det som händer då är att testare jobbar efter en informell
enklare process som uppnår samma mål. Att sen lägga tid på att underhålla
processer som inte används är fullständigt bortkastat.

5. Slutsats
Test är tyvärr mycket mer komplext än de flesta som inte är insatta i det
förstår. Problemen, som beskrivits i artikeln, uppstår när man tror sig kunna
i detalj toppstyra en testorganisation baserad p å en abstraherad, förenklad
modell av verkligheten, eller försöker skapa komplicerade lösningar för att
man tror att det behövs komplicerade strategier för att lösa komplexa
problem.
Att förenkla kostar – resurser, tid, ansträngning – men det finns egentligen
inga andra effektiva alternativ när man står inför alltför komplexa problem.
Komplicerade lösningar där man tror sig ta hänsyn till alla de variabler man
identifierar blir svåranvända och känsliga för de variabler man inte känner
till. Enkla lösningar som tar hänsyn till att problemen inte är helt
förutsägbara blir istället antifragile och ger oss verktyg som är flexibla nog
att vara användbara i en värld fylld av komplexitet och osäkerhet, samtidigt
som testare får mer incitament att använda dem ofta i sin vardag , eftersom
de kräver mindre ansträngning och är lättare att förstå.
En enkel lösning kan karakteriseras av t.ex. färre antal steg i en process eller
metod, färre antal in- och utdata, färre beroenden, färre variabler, färre
interaktioner, osv., men det är kritiskt att lösningen fortfarande upp fyller
sitt mål tillräckligt väl.
Det finns gränser för hur mycket man kan förenkla någonting. Och det gäller
att vara medveten om den gränsen. Enkelhet tillför värde, men också en
kostnad. Värdet måste alltid överstiga kostnaden. Grafen nedan är ett
exempel på hur det skulle kunna se ut.

6. Referenser
[1] Wicked Problem
http://en.wikipedia.org/wiki/Wicked_problem
[2] Komplexitet
http://sv.wikipedia.org/wiki/Komplexitetsteori
Christer Hoberg – Komplexitetsmax
http://kth.diva-portal.org/smash/record.jsf?searchId=1&pid=diva2:10395
Tor Nörretranders – Märk Världen
http://www.bokus.com/bok/9789100570705/mark-varlden/
[3] Nassim Nicholas Taleb - Antifragile
http://www.slideshare.net/andrefaria/antifragile-16611267
http://en.wikipedia.org/wiki/Antifragile:_Things_That_Gain_from_Disorder
http://www.amazon.com/Antifragile-Things-That-Gain-Disorder/dp/1400067820/
[4] Jurgen Appelo – Agile Management 3.0
http://www.noop.nl/people-motivation/
http://www.noop.nl/2009/10/people-motivation-target-intrinsic-desires.html
[5] Dan Pink – Drive
http://www.danpink.com/books/drive
http://www.youtube.com/watch?v=u6XAPnuFjJc
[6] Edward de Bono – Simplicity Principles
http://noscope.com/2005/de-bonos-simplicity-principles/
http://www.amazon.com/Simplicity-Edward-De-Bono/dp/0140258396
[7] Emelie Engström – Decision support for test management and scope selection in a software
product line context
http://www.avhandlingar.se/avhandling/b5a61f2e46/
http://dl.acm.org/citation.cfm?id=2005507