Testaren är död – länge leve testaren

När jag startade min testbana för drygt tjugo år sedan fanns det i stort sett två yrkesroller.

Antingen var man testledare eller så var man testare. Testledaren agerade ”miniprojektledare” och testaren skrev och exekverande testfall. Relativt snart började testrollen delas upp i två varianter – en mer kodnära, där automatisering spelade en allt större roll och en mer verksamhetsnära, där fokus ofta låg på slutanvändaren och dennes behov.

Fortfarande idag så syns detta rollmönster tydligt. Ett exempel är ISTQBs certifieringsupplägg och ett annat exempel är jobbannonser där man ofta ser företag och organisationer söka just testledare och/eller [tekniska] testare. I det senare fallet finns dock tecken på att en ny verklighet är på väg att ta form. Nya och ibland kryptiska roller har börjat dyka upp i titlar och annonser.

Vad gör egentligen en teststrateg, en testkoordinator, en teknisk testledare etc?

En delförklaring till denna nya verklighet är det massiva intåget av agila utvecklingsmetoder under de senaste fem-tio åren. En direkt konsekvens av det agila upplägget är att rolltänket försvinner och ersätts av ett upplägg där teamet tar ett gemensamt ansvar både för utveckling och för testning, vilket betyder att det är teamets sammanlagda kompetens som blir viktig, inte att en enskild individ har en i förväg beskriven roll. Detta kan tydligt exemplifieras av den traditionella testledaren vars roll inte längre existerar i och med att teamet inte har en uttrycklig ledare. Det självorganiserande teamet måste dock hantera planering och styrning av teamets arbete, varvid testledarens kompetens fortfarande är viktig. Ett andra exempel är att en alltmer ökad testautomatisering gör att kompetenserna som behövs för rollerna utvecklare respektive testare allt mer överlappar.

En annan trolig delförklaring till den nya verklighet där roller försvinner, flyter samman eller tillkommer är den massiva datorisering som just nu pågår i samhället. Datorer finns idag överallt och används av alla, vilket ställer helt nya krav både på utveckling och på testning. Bland annat så ökar vikten av systemegenskaper som prestanda, datasäkerhet och användbarhet dramatiskt. I alla dessa tre områden finns en generell kunskapsbas som både testare och utvecklare behöver. Vidare finns ofta en motsättning mellan systemets testbarhet och dessa tre egenskaper. D.v.s. ökar man systemets testbarhet (möjligheten att manipulera och observera systemet i testsyften) så riskerar man att sänka systemets prestanda, minska systemets säkerhet och/eller försvåra systemets användbarhet. Med andra ord ställs idag väsentligt högre krav på kompetens både hos individ och team för att kunna ta rätt designbeslut och därefter hantera de effekter på utveckling och testning som blir konsekvenserna av dessa beslut.

Mot bakgrund av ovanstående är det min, och många andras, slutsats att rollen som beskrivningssätt för testyrket inte längre fungerar så bra. I en given kontext kan det fortfarande vara av stort värde att diskutera roller, men då måste dessa roller vara tydligt beskrivna och man ska vara medveten om att denna beskrivning oftast inte går att generalisera utanför den givna kontexten.

Istället för att prata roller bör vi därför inrikta oss på kompetenser.

Traditionellt har ”testkompetens” delats in i tre områden:

1. Testteori –
   den teoretiska kunskap som behövs för att kunna genomföra testning på ett effektivt sätt.
2. Systemkunskap –
   kunskaper om den teknik och de teknikplattformar som det testade systemet baseras på samt
3. Domänkunskap –
   kunskaper om hur produkten faktiskt används och vilka problem produkten ska lösa

Jag anser att dessa tre kompetensområden fortfarande i högsta grad är giltiga men att de behöver kompletteras och eventuellt förfinas. Jag har identifierat fem kompetensområden, delvis nya för testprofessionen, vilka blir allt viktigare och som vi behöver diskutera vidare.

Dessa är..

1. Systemegenskaper
2. Plattformar och Verktyg
3. Process och Metodik
4. Krav
5. Utveckling

Som nämnts tidigare så finns det vissa systemegenskaper (bland annat just prestanda, datasäkerhet och användbarhet) där den individ som ska testa dessa egenskaper behöver kunna mer om dessa egenskaper än bara hur man testar dem. Dessa egenskaper utgör egna expertområden, där det är naturligare att se egenskapen som en helhet istället för att bryta ut testningen och resonera separat om den, såsom är fallet idag inom ramen för den traditionella testteorin.

Vidare blir testverksamheten alltmer automatiserad och integrerad med utvecklingen samtidigt som plattformar och verktyg för både test och utveckling ständigt vidareutvecklas och blir alltmer komplexa. Redan idag finns ett större antal vanligt förekommande verktyg där det krävs expertkunskaper för att konfigurera dem och där delar av konfigurationen baseras på hur testningen är tänkt att genomföras men där även sättet att bedriva utvecklingsarbetet har en påverkan. Således behövs både djupare insikt om utveckling och testarbete samt specifik och detaljerad kunskap om själva verktyget.

Nära kopplat till komplexa verktyg är process och metodik. Även detta område är starkt kopplat till den traditionella testteorin, men precis som med området egenskaper så finns delar av process och metodik-området utanför testteorin. Ett konkret exempel är hur man bör hantera systemtestning i ett scrum-upplägg. Här behöver man ha insikt både i testupplägget som helhet och i scrum som arbetsmetodik. Återigen så ser vi ett exempel på hur enbart själva testkunskapen inte är tillräcklig.

I gränslandet mellan krav och test finns nästa intressanta kompetensområde.

Nya representationsformer för krav, som till exempel user stories, påverkar förstås testningen. Även balansen mellan egenskaper och testbarhet är i grunden en kravfråga som kräver en djupare testförståelse, men där enbart testkunskap inte räcker till.

Det sista av mina fem områden är utveckling, som ju traditionellt har ansetts vara testningens motpol. Trots det har utvecklarna länge tagit ett ansvar för den kodnära testningen genom att implementera lågnivå-testfall direkt i koden som testmetoder, testklasser eller separata testprocedurer. Från andra hållet ser vi mer och mer testning även på högre nivåer som automatiseras direkt eller indirekt via script (kod). Min känsla är att utvecklarna i sin kodnära testning skulle ha nytta av mer testkunskap och att testarna som kodar sina script, i ännu högre utsträckning skulle ha nytta av utvecklingskunskaper. Återigen ett exempel på ett område där den totala kvaliteten både på produkt och på arbete kan höjas genom en korspollinering av kunskaper.

Min slutsats av ovanstående resonemang är att försöken att definiera testyrket via roller inte bara är förlegat utan att det även ger onödiga begränsningar i den multidisciplinära verklighet som vi nu lever i.

Istället bör man resonera om kompetenser – gärna ”on demand” – för att göra organisationen som helhet så effektiv som möjligt.

Detta ger även spännande möjligheter för individen i det dagliga arbetet, där arbetsuppgifterna blir mer mångfacetterade och även på sikt där en karriär kan byggas på en vidareutveckling av kompetenser snarare än att bli fast i en roll.

Testaren är död – länge leve testaren.

Kort om författaren

Mats Grindal är konsult i testbranschen sedan mer än 20 år. Just nu jobbar han som teststrateg på SL med framtidens tunnelbana i fokus. I jobbet ingår bland annat att ställa krav på bemanningen av de testteam som ska testa uppgraderingar av röd tunnelbanelinje planerade för den kommande 10-årsperioden. I hans förra projekt jobbade han med att testa avancerad medicinsk utrustning i en scrum-liknande miljö i vilket automatisering spelade en viktig roll.

Mats Grindal på LinkedIn - AddQ, din partner för test