Ledarskap inom testning: Att testa som ett team

Ibland kan det innebära att det inte finns några testare alls (dun-dun-duuu), och att verksamhetsanalytiker och utvecklare tar fullt ansvar för testningen.

Vänsterförskjutning är inget nytt – förespråkare för testning har i många år predikat mantrat ”testa tidigt, testa ofta”. Redan 1993 föreslogs att alla artefakter i en stegvis process – både dokument och programvara – kunde (och ofta borde) testas.

Vänsterförskjutning handlar framför allt om att tidigarelägga tänkandet kring testning i processen.

Även om vattenfallsmodellen var den dominerande livscykelmetoden vid den tiden är antalet steg eller deras varaktighet inte det viktiga. Den underliggande principen var att kunskapskällorna som ger riktning åt utformningen och utvecklingen av programvara bör ifrågasättas eller testas. 

I ett stegvis projekt kan detta innebära formella granskningar. I ett agilt projekt kan testaren (eller utvecklaren, verksamhetsanalytikern eller användaren) föreslå scenarier som utmanar den som skrivit ett krav eller en berättelse att tänka igenom konkreta exempel och diskutera dem innan någon kod skrivs.

Det här är de viktigaste förändringarna som ingår i fenomenet vänsterförskjutning:

1. Metoden beteendedriven utveckling (BDD) har gjort det möjligt för utvecklare, användare/verksamhetsanalytiker och testare att samverka kring det som kan kallas verksamhetsberättelser. Testdriven utveckling har använts av många utvecklare i 15 år eller mer. I dag införs BDD i större utsträckning eftersom metoden främjar bättre samarbete i agila team och dessutom introducerar BDD-verktyg som kan användas av utvecklare. Det är en enklare test-först-metod.
2. Kontinuerlig leverans (CD) har funnits i 5–10 år och har sina rötter i de högautomatiserade metoder för byggande och lansering som utvecklades av stora internetföretag. Den används nu av de flesta organisationer med en närvaro på nätet.
3. CD systematiserade och snabbade upp lanseringsprocessen genom automatisering. Men det synliggjorde också förseningarna i produktion, driftsättning och infrastrukturförändringar som tidigare hade dolts av långsamma processer för byggande, testning och lansering. DevOps är en förändring av det kulturella tankesättet där utvecklare samarbetar mycket närmare med driftpersonal. Just nu dyker nya verktyg upp nästan dagligen och leverantörer marknadsför DevOps som ”nästa stora grej”. Det är en mycket haussad och dynamisk situation.
4. SMAC, eller socialt, mobilt, analys och moln, representerar en förändring i hur organisationer hanterar förändringar i verksamhet och system inom det mobila området. Experiment inom verksamheten, som genomförs som förändringar i produktionssystem, övervakas på detaljnivå. De ”stora” datamängderna som samlas in bearbetas och verksamhetsbeslut fattas utifrån den analys som erhållits.

Täta experiment med produktionssystem möjliggör innovation i verksamheten ”i marknadsföringens hastighet”. Experimenterande står i centrum för det som var 2010-talets viktigaste trend – digital omvandling.

Get Free Access

Get regular tech leadership wisdom for delivering better software and systems.

Create Free Account

Have an account? Log In

Testning som aktivitet, inte roll

Vänsterförskjutning förändrar testarnas roll. Omfördelningen av testningen som vänsterförskjutningen medför gör det tydligt att testare inte ensamma ansvarar för testningen, det vill säga att testare inte längre äger testningen. 

Om man tänker efter ägde de egentligen aldrig testningen helt och hållet, men det fanns en outtalad förståelse i projekten att oavsett vad resten av teamet, särskilt utvecklarna, gjorde i fråga om testning, fungerade testarna som ett skyddsnät. Om utvecklarna hade ont om tid och minskade sin testning för att kunna leverera, tillhandahöll testarna skyddsnätet.

Testning är nu en aktivitet, inte en roll.

Utvecklarna börjar använda bättre testmetoder och får bättre insyn i sitt arbete. Bra komponenttestning eller enhetstestning har specifika mål som skiljer sig från systemtestning (som ett exempel). Därför kan omfattningen (eller mängden) systemtestning minskas. 

Den korrekta fördelningen av testmål och testning för att uppnå dessa mål är det primära syftet med teststrategin. Tyvärr hölls utvecklarna tills nyligen inte effektivt ansvariga, så de förlitade sig på sen systemtestning för att kompensera.

Vänsterförskjutning gör utvecklarna mer ansvariga.

Överlag omfördelas ansvaret för testningen, vilket förändrar testarens roll. Testarna kanske utför mindre taktisk testning, men deras strategiska bidrag ökar. Testarna kan äga teststrategin, utmana krav, ge råd till intressenter och skapa en närmare relation med utvecklarna för att stödja bättre testning av utvecklarna och testautomatisering.

En ny roll

Vänsterförskjutning innebär att återkoppling ska ges så snart det är möjligt att ge återkoppling som hjälper teamet att förstå, utmana och förbättra mål, krav, design eller implementering. 

Användare, BA:er, utvecklare och hela programvaruteamet bör vara beredda att utbyta återkoppling på detta sätt. Ibland finns det motstånd, men det övergripande målet är att genomföra ett bättre och mer välinformerat projekt – det är allt.

Det enklaste sättet att sammanfatta detta beteende är ”engagera dig tidigt” – så tidigt som möjligt. Delta i diskussionen och samarbeta kring idéer och krav, samt i varje skede där resultatet från det skedet påverkar värdet av projektets slutliga leverans. 

Enkelt uttryckt utmanar testaren kunskapskällor, oavsett om dessa källor är intressenter, användare, utvecklare, verksamhetsberättelser, dokument eller föregångare.

Det vanligaste tillvägagångssättet är att utmana genom exempel. I alla skeden kan dessa exempel betraktas som tester. De kan snabbt förkastas efter användning eller formaliseras i testautomatisering eller manuella kontroller. Dessa exempel kan helt enkelt användas taktiskt för att påpeka brister i människors tänkande eller ges till utvecklare, exempelvis som idéer eller frön till utvecklartester. De kan också användas som hjälpmedel vid coachning för att visa användare eller utvecklare hur bättre tester kan skapas.

Betrakta ditt programvaruprojekt som en process för kunskapsinhämtning. Denna kunskap samlas in under hela projektet och utvecklas ofta över tid. Målet med vänsterförskjutning är att säkerställa denna kunskap genom att utmana och testa nära dess källa, samt att så långt det är möjligt säkerställa att den är tillförlitlig innan den låses fast i kod.

Vänsterförskjutning tar testförst-filosofin ett steg längre. Agilt arbete har alltid främjat samarbete och snabb återkoppling – vänsterförskjutning kan ses som ett samordnat tillvägagångssätt för snabb återkoppling. Om ditt team använder ett vänsterförskjutet tillvägagångssätt för testning kan rätt verktyg göra stor skillnad. Ta en titt på vår kurerade lista över verktyg för programvarutestning för att hitta det som passar bäst för ditt team.

Agila testinterventioner

Det vänsterförskjutna tillvägagångssättet är grundläggande för en teststrategi i agila projekt. I ett agilt sammanhang kan teststrategin ses som en serie testinterventioner. I alla projekt finns kritiska ögonblick där möjligheter att samla in och ge återkoppling uppstår. Testaren behöver fokusera på dessa kritiska ögonblick och vara beredd att bidra vid dessa tillfällen.

I dina egna projekt behöver du identifiera kritiska ögonblick där intervention är möjlig och identifiera vilka val ni kan göra när ni testar som ett team. Bör testaren till exempel skriva enhetstester åt utvecklarna, tillhandahålla exempel för att hjälpa dem komma igång eller coacha dem för att förbättra deras testförmåga? Bara du och ditt nya programvarutestteam kan avgöra detta.

Vi använder en typisk Scrum-process för att visa hur testinterventioner kan placeras i Scrum-metoden. Interventioner sker antingen på projekt- (eller release-)nivå eller på sprintnivå. Diagrammet nedan visar en vy på projektnivå och de fem viktigaste interventionerna.

Utmaning och definition av användarberättelser är de delar där testaren validerar en användarberättelse respektive föreslagna acceptanskriterier för en berättelse. Integrationstester kontrollerar att nya funktioner länkas korrekt till andra funktioner och till systemet som helhet. Systemtester och användar- (acceptans-)tester genomförs efter behov.

Ett projekt har vanligtvis flera sprintar, och de fyra sprintinterventionerna visas i diagrammet nedan. Det dagliga ståmötet är ett tillfälle att rapportera framsteg, lyfta problem, identifiera risker eller diskutera frågor som tagits upp och svar som kommit fram under sprinten. 

Förfining av användarberättelser och bidrag till utvecklarnas testning är dagliga aktiviteter som äger rum som en del av diskussioner med användare, analytiker och utvecklare. Testaren inför utvecklarnas tester och nya systemtester i en växande samling tester som ska automatiseras.

I tabellen nedan kan du se en tabellöversikt över testarnas insatser. Din process kan se annorlunda ut eller bygga på Scrum med variationer, men tabellen identifierar typiska insatstyper i en typisk Scrum-process. Du kan ha fler eller färre aktiva insatser vid olika tidpunkter i din egen unika process.

Jag föreslår att du identifierar de kritiska momenten, föreslår ditt bidrag och förhandlar med ditt team. Du erbjuder mer testledning och vägledning i stället för att frivilligt ta ansvar för testarbetet. Detta tillvägagångssätt gör det mycket enklare att visa ditt värde för teamet, men teamet kanske inte behöver lika många testare.

Relationer med utvecklare

I vissa organisationer kan relationen mellan utvecklare vara präglad av misstro, skuldbeläggning och antagonism. I värsta fall är relationen giftig: utvecklarna testar inte särskilt mycket alls och testarna betraktas som utvecklarnas tjänare. Testarna antar beteenden som kan kallas medberoende och agerar som offer. Det är precis denna situation som vänsterförskjutningsmetoden syftar till att undvika.

Det finns många metaforer som har använts för att beskriva en god relation mellan utvecklare och testare. Vi använder ett arbetssätt med pilot och navigatör för att illustrera hur den motsvarande relationen mellan utvecklare och testare kan fungera. Men först ska vi titta på en dysfunktionell situation.

Navigatören går inte ombord på planet utan vinkar till piloten när planet lyfter. Navigatören reser med buss, separat men långsamt. Till slut kommer navigatören fram till destinationen, men efter en tid upptäcks det att planet har flugit åt fel håll och kraschat in i ett berg.

Visst borde navigatören ha varit ombord på planet? Föreställ dig hur piloter och navigatörer faktiskt arbetar tillsammans.

• Piloten kan inte flyga planet utan en navigatör. Navigatören kan inte flyga planet.
• Piloten och navigatören kommer överens om färdplanen innan resan börjar.
• Piloten lyfter och flyger planet.
• Navigatören följer kursen och jämför den med färdplanen och/eller slutdestinationen, med hänsyn till ogynnsamma händelser, särskilt vädret.
• Navigatören letar efter avvikelser, planerar en ny kurs och meddelar piloten, som justerar flygrutten.
• Och så vidare.

Relationen mellan pilot och navigatör kan jämföras med relationen mellan programmerare och testare. Det är inte heller meningsfullt att dela upp utvecklare och testare i separata team som arbetar sekventiellt. Ändå är det så vi traditionellt har arbetat under de senaste trettio åren eller så – särskilt i större projekt som löper över längre tid.

Vänsterförskjutning omfördelar tänkandet kring testning och för det i praktiken framåt i processen. Testare fungerar som fullvärdiga partner till utvecklarna, precis som navigatörer gör med piloter:

• Testaren och utvecklaren sammanställer gemensamt information om kraven.
• Vanligtvis ifrågasätter testaren kraven genom exempel (möjliga eller faktiska testidéer).
• Utvecklaren tänker på implementeringen och använder exemplen för att ge riktning åt sin design.
• Testaren, utvecklaren, intressenterna, användarna och analytikerna enas om en gemensam förståelse av ett tillförlitligt krav.
• Testaren har ständig kontakt med utvecklaren och diskuterar förändringar av kraven, risker för fel samt hur testning kan visa att funktioner fungerar eller avslöja fel.
• Testaren ser på hur funktionen som arbetas med kommer att integreras både på teknisk nivå och på användarresenärens nivå, samt hur integrationen kan testas.
• Testaren blickar bortom den omedelbara funktion som utvecklaren arbetar med för att identifiera framtida utmaningar, risker, förändringar och osäkerheter.
• Och så vidare.

Den idealiska relationen mellan utvecklare och testare som beskrivs ovan uppstår inte automatiskt. Teamet måste arbeta fram den. Du kan se var och en av aktiviteterna ovan som en insats, men insatser är inte alltid bekväma för alla parter. Ge detta tillvägagångssätt bästa möjliga chans att lyckas genom att diskutera varje insatstyp med dina samarbetspartner redan från början – när du först vet att ni kommer att arbeta nära tillsammans.

Insatser, liksom bra användarberättelser, sätter igång samtal.

Varje insatstyp kräver att båda sidor samtycker till att den är giltig och relevant. För att känna sig trygga måste parterna lita på varandra och förstå att det finns goda skäl att ställa frågor, ta upp problem och ifrågasätta krav eller förståelse under dagliga avstämningar, planeringsmöten eller retrospektiv.

More Articles

• 9 bästa konferenserna om digital transformation att delta i 2026–2027
• Så använder du DevOps-mätvärden för att skala upp ditt företag

Utmaningar med distribuerade och outsourcade team

I diskussionerna ovan har det underförstått antagits att alla arbetar i samma team och på samma plats. När arbetsbelastningen för programvarutestning läggs ut och/eller flyttas till andra länder uppstår flera negativa faktorer. Tabellen visar tre typiska faktorer att ta hänsyn till.

Fysisk (och tidsmässig) separation	Team kan vara utspridda på ett kontor, i olika byggnader, orter, länder och tidszoner. Kommunikation störs, kanalerna är begränsade och mindre information flödar.
Olika drivkrafter	Leverantörsteamet arbetar för en organisation som får betalt för att utföra testningen. I slutändan är deras drivkraft att gå med vinst. Vid avtal till fast pris är pressen att arbeta snabbt. Vid avtal baserade på tid och material finns frestelsen att dra ut på arbetet.
Kulturella skillnader	Nationella och kulturella skillnader kan vara betydande. Det kan ibland ta tid att uppmärksamma dem och ta hänsyn till dem.
Företags-/organisationskultur	Företagskulturer skiljer sig också åt – företag tenderar att samarbeta bäst med företag av jämförbar storlek, flexibilitet och formalitetsgrad. Företag är mer eller mindre försiktiga när det gäller integritet, säkerhet, konfidentialitet och så vidare. Företag har olika ledarstilar, och skillnaden mellan offentliga och kommersiella organisationer kräver också viss tillvänjning.
Leverantörer arbetar utifrån avtal	Din leverantör har ingen lojalitet gentemot projektets intressenter eller deras affärsmål. De arbetar enligt reglerna som anges i avtalet. Om du kan, se till att dina avtal identifierar alla ansvarsområden på båda sidor och att avtalet belönar bra beteenden och bestraffar dåligt beteende.

Vissa företag förstärker befintliga programvarutestteam för att bygga upp kapacitet för större projekt eller anlitar specialiserade testföretag i stället för att förlita sig på konsulter eller interna användare för testningen. I andra situationer kan all utveckling och/eller testning överlämnas till leverantörer. I samtliga fall behöver kundföretaget hantera sina leverantörer. Det innebär inte att det räcker att skriva ett begränsande avtal med stränga vitesklausuler.

När saker går fel vill du ha snabba svar och samarbete från din leverantör; du vill inte att de gömmer sig bakom juridiska klausuler i avtalen.

Framgångens hemligheter är:

• Om du inte hanterar din leverantör kommer de att hantera dig (om ni inte är fullvärdiga partner och låter leverantören fastställa villkoren kommer leverantören att ha alla trumf på hand).
• Målet är att definiera en god arbetsrelation. Den behöver etableras på alla nivåer – hos intressenter, chefer och yrkesutövare.
• Avtal bör formuleras så att alla ansvarsområden på båda sidor identifieras, med lämpliga mått, tröskelvärden, etappbetalningar och acceptanskriterier definierade för att uppmuntra gott beteende (på båda sidor av överenskommelsen).
• Överenskommelser bör uppmuntra öppenhet och engagemang för det gemensamma målet att projektet ska lyckas.

Tankeställare

Och slutligen några frågor att fundera över. 

Vilken relation har du som testare till dina utvecklare? Eller, om du är utvecklare och läser detta, vilken relation har du till testarna? Fråga kanske dina samarbetspartner inom utveckling eller testning hur de skulle beskriva er relation. Jämför era anteckningar!

För att programvarutestteam ska vara produktiva måste de kommunicera och samarbeta.