Styrgruppen frågar inför kvartalsrapporten. Den nya Scrum Mastern frågar i sprintplaneringen. Projektledaren frågar dagen före release. De vill ha ett dokument – helst i Word, gärna med en mall i sidhuvudet, absolut med ett versionsnummer.
Men dokumentet är inte poängen. Innan vi pratar testplan behöver vi svara på en mer grundläggande fråga:
Varför testar vi egentligen?
Alltför ofta får testaren uppdraget att ”skriva en teststrategi”, laddar ner en mall, och fyller i efter bästa förmåga. Resultatet ser professionellt ut – men saknar förankring i verkligheten.
Orsaken? Vi hoppar över det mest fundamentala: testuppdraget.
Testuppdraget är svaret på varför vi testar i just detta sammanhang. Det är inte ”att hitta buggar” – det är alldeles för vagt. Ett bra testuppdrag kopplar direkt till affärsmål och risker:
”Säkerställa att betalsystemet hanterar 10 000 transaktioner per minut under julhandeln utan att tappa en enda order eller exponera kunddata.”
Och här kommer insikten som många testare missar:
Testaren är inte den som definierar testuppdraget. Testaren är facilitatorn.
Produktägare, affärsintressenter, utvecklare, drift och support sitter på kunskapen. Testarens roll är att facilitera den strukturerade diskussionen som gör den kunskapen explicit.
”Vi behöver bara testa att allt fungerar” är lika meningslöst som det är vanligt. Det är testarens jobb att ställa frågorna som gör det konkret:
- Vad är den viktigaste affärsregeln?
- Vad händer om funktionen inte fungerar perfekt?
- Var är koden mest komplex?
- Hur backar vi tillbaka om något går fel?
Svaren bildar tillsammans testuppdraget – den gemensamma förståelsen av vad testningen ska uppnå.
Från uppdrag till strategi
När testuppdraget är tydligt kan vi formulera strategin. Strategin är vår övergripande approach för att uppfylla uppdraget – vilka testtyper som behövs, vilka risker vi prioriterar, hur vi balanserar automatisering mot manuellt arbete.
Men strategier finns på flera nivåer, och de kan heta många olika saker: policyer, riktlinjer, standards, handböcker. På koncernnivå finns övergripande principer. På programnivå koordineras flera projekt. På projektnivå anpassas strategin till den specifika kontexten. I agila team kompletteras projektstrategin med ett sprintnivåfokus.
Dessa styrande dokument ska följas – men de kan och bör utmanas när de inte fungerar. Att blint följa en föråldrad policy hjälper ingen. Att ignorera den utan dialog är värre. Rätt väg är att förstå varför policyn finns, följa den, och lyfta frågan genom rätt kanaler när den inte passar.
Här blir testarens roll att facilitera den strategiska diskussionen. Utvecklare, produktägare, arkitekter och drift har alla olika bild av vilka risker som är värda att prioritera. Utvecklarna kan tro att integrationen med legacy-systemet är trivial (”vi har ju gjort det förr”), medan drift vet att API:et ändrats sedan senast. Den typen av gap upptäcks sällan av sig självt – någon behöver ställa frågorna som får dem i ljuset.
Utan sådana faciliterade diskussioner upptäcks missförstånd ofta först i integrationstestningen, veckor för sent.
Från strategi till plan
Strategin säger vad och hur. Planen säger vem och när.
I agila team behöver testplanen sällan vara ett separat dokument. Mycket av det som traditionellt ingick i en testplan – startkriterier, slutkriterier, vem som testar, vilka testtyper som krävs – kan istället formuleras som en del av teamets Definition of Done.
En DoD som inkluderar testaspekter kan se ut så här:
Enhets- och integrationstester skrivna och gröna. Kodgranskad. Testad i stagingmiljö. Prestandakrav verifierade för berörda flöden. Inga kända kritiska buggar.
Det är i praktiken en testplan – fast inbakad i teamets dagliga arbetsflöde istället för gömd i ett dokument som ingen öppnar.
Det som däremot kräver planering utöver DoD är aktiviteter som spänner över flera sprintar eller kräver resurser utanför teamet: prestandatestning i dedikerad miljö, säkerhetsgranskning av extern specialist, koordinerad integrationstestning med andra team. De behöver framförhållning.
När börjar vi, när pausar vi, när är vi klara?
Oavsett metodik behöver teamet svar på tre frågor:
När är vi redo att börja testa? Om koden inte bygger, miljön är nere eller testdata saknas – börja inte. Bra fråga till teamet: ”Vad händer om vi börjar testa utan dessa saker?”
När pausar vi? När kritiska buggar blockerar stora delar av systemet. När miljön är så instabil att resultaten blir opålitliga. Automatiska smoketester fungerar som tidig varningssignal.
När är vi klara? Aldrig, om vi ska vara ärliga. Men vi behöver pragmatiska kriterier för när testningen är tillräcklig. Scenariobaserade diskussioner fungerar bäst:
”Vi har 80 % kodtäckning men vet inte om de kritiska affärsflödena fungerar. Skulle ni vara bekväma med att släppa då?”
Sista slutkriteriet bör alltid vara: produktägaren har accepterat kvarvarande risker. Det handlar om informerat risktagande, inte om perfektion.
Testaren som kommunikationsbrygga
”Hur går testningen?” Frågan kommer dagligen från olika håll. Utan plan blir svaret antingen för detaljerat (”null pointer exception i CustomerService.java rad 234”) eller för vagt (”det går bra”).
Olika målgrupper behöver olika budskap:
- Utvecklare vill ha stack traces och reproduktionssteg
- Produktägare vill veta påverkan på funktionalitet och release
- Ledning vill se trender, risker och beslutsunderlag
- Kunder vill höra att deras data är säker
En kritisk del av testarens facilitatorroll är att översätta mellan dessa världar. När en utvecklare säger ”race condition i asynkrona callbacks” behöver produktägaren höra ”ibland försvinner kundens order om de klickar för snabbt.”
För ledning: ge kontext och rekommendation, inte bara problem.
Vi har hittat 15 buggar, varav 3 är kritiska för go-live. Vi rekommenderar att fördröja releasen 3 dagar för att fixa dessa.
Den värsta kommunikationen är den som döljer problem. Grön status när kritiska buggar finns hjälper ingen. Var snabb, var specifik, ge kontext, kom med rekommendationer.
Dokumentation – för vem skriver vi egentligen?
I reglerade miljöer är svaret enkelt: man dokumenterar för att man måste. Spårbarhet krävs, revision väntar.
I ett agilt team är frågan svårare. Det agila manifestet sätter ”fungerande programvara framför uttömmande dokumentation” – men manifestet säger framför, inte istället för. Dokumentation som ersätter kommunikation är anti-agilt. Dokumentation som stödjer och förlänger kommunikation har stort värde.
Två frågor behöver ställas innan pennan sätts på pappret:
För vem skriver vi? Om svaret är ”för oss själva, just nu” – håll det lätt och tillfälligt. Om svaret är ”för den som underhåller systemet om tre år” – då är kraven helt andra. Personen vet inte vad ni vet idag. Personen behöver förstå varför ni fattade de beslut ni fattade, inte bara vad.
Behövs det alls? Om hela teamet sitter tillsammans och vet vad som gäller – behövs dokumentet då? Ibland är svaret genuint nej. Men när teamet växer, när folk slutar, när ni lämnar över – då visar sig värdet av att ha skrivit ner saker.
Poängen är inte att alltid dokumentera, utan att medvetet välja när det ger mer värde än kostnaden att skriva och underhålla.
Sammanfattning
Testplanering är inte en ensam aktivitet. Det är en faciliterad dialog mellan olika perspektiv och kompetenser.
Testaren är inte den som sitter med mallen och fyller i. Testaren är orkesterledaren som hjälper alla att spela samma melodi, även om de använder olika instrument. Vi bidrar med metodkunskap, strukturerade tekniker och erfarenhet. Men viktigast: vi ställer de rätta frågorna som får andra att tänka i kvalitetstermer från början.
Perfekta förutsättningar finns aldrig. Men genom att systematiskt arbeta från testuppdrag genom strategi till plan skapar vi struktur utan rigiditet. Genom riskbaserad prioritering fokuserar vi där det gör mest nytta. Genom tydliga kriterier och kommunikation skapar vi gemensam förståelse av vad kvalitet betyder.
Det är det testaren faktiskt bidrar med. Inte mallen. Faciliteringen.