Låt utvecklarna vara första försvarslinjen i testningen: Fem minuter som höjer kvalitet och samarbete

Fem minuter av utvecklarens tid kan göra hela skillnaden

Här är en enkel men kraftfull strategi: Låt utvecklare testa varandras kod innan den når testarna. Detta minskar antalet uppenbara buggar, frigör tid för testare att fokusera på mer komplexa problem och minskar den administrativa kostnaden med att skriva och spåra felrapporter.

Jag började använda denna strategi för många år sedan när jag ledde testarbetet för ett företag som levererade skräddarsydda utvecklingsteam åt kunder. Utmaningen? Kunderna ville endast betala för utvecklare, inte för testare. Detta innebar att jag var tvungen att coacha utveck-larna i testning och skapa en process som passade deras arbetsflöde. Teamet var fantastiskt, och resultaten var riktigt intressanta!

Det som gjorde störst skillnad? En enkel regel: I varje pull request skulle utvecklarna göra två saker – kodgranskning och ett test av kollegans nya kod innan leverans till main-branch. Må-let var inte att lägga timmar på testning. Tvärtom: tumregeln var att utvecklarna skulle lägga fem minuter på att testa det grundläggande och använda sin kunskap och erfarenhet för att hitta uppenbara problem. Om de spenderade mer än fem minuter var det för att de hittat något som sparade betydligt mer tid längre fram.

‍

Så vad var resultatet?

1. Uppenbara fel upptäcktes tidigt – ungefär som stavfel vi själva missar när vi skriver texter men som är uppenbara för andra läsare. Detta sparade bland annat tid som an-nars hade gått till att administrera buggar eftersom problemen kunde fixas direkt.
2. Samarbetet förbättrades dramatiskt. I stället för att vara gömda bakom kod började utvecklarna diskutera funktioner, krav och alternativa lösningar öppet med varandra. Dessa samtal ledde till bättre koddesign, tydligare specifikationer och snabbare ut-veckling.

Min ursprungliga teori var att utvecklare skulle dubbelkolla sitt arbete för att undvika att tappa ansiktet inför utvecklarkollegan som skulle testa. Men detta var inte det som hände! Det jag inte hade förutsett var hur denna lilla tidsinvestering skapade utrymme för meningsfull dialog mellan utvecklarna. Den typen av dialog hoppas annars lätt över när teamet är under press att leverera. Genom att införa en obligatorisk paus för testning skapades en möjlighet för samarbete som spred kunskap, justerade prioriteringar och enade teamet mot ett gemensamt sätt att arbeta med kod. Resultatet handlade inte om att undvika att ”se dålig ut” – det hand-lade om att skapa något riktigt bra tillsammans.

‍

Går samma resultat att återskapa i andra organisationer?

Jag upprepade detta i en annan utvecklingsorganisation där jag genomförde en workshop över ett par dagar. I den kontexten fanns flera utvecklingsteam men bara ett par testare. Dessa testare höll på att drunkna i enkla, uppenbara buggar och hann därför inte med djupare testning. När utvecklarna började göra den första testningen så fångades de enkla buggarna tidigt och testarna kunde plötsligt ägna sig åt det de är bäst på: att med djup testkunskap och testdesign avslöja de mer komplexa felen. Dessutom fångades vissa problem, som krävde teknisk domänkunskap, i ett tidigare skede. Återkopplingen till mig var att detta var den mest effektiva förändring organisationen någonsin gjort i sin utvecklingsprocess – och samtidigt en av de minst kostsamma.

Ändå verkar många organisationer ha en motvilja mot denna typ av arbetsflöde – trots att flera moderna utvecklingsmetoder förespråkar liknande arbetssätt, från Extreme Programming till

olika Agila processer. Jag hade en gång en hetsig diskussion med en utvecklingschef som insisterade på att ”utvecklare ska aldrig testa, ALDRIG”. Det projektet fastnade i buggrättningscykel under åtta månader där trenden för kritiska buggar aldrig pekade mot noll. Till slut tvingades man skala ner projektet till en bråkdel av den ursprungligt tilltänkta leveransen bara för att kunna leverera något överhuvudtaget.

‍

Varför är detta så kostnadseffektivt?

• Nya ögon ser det du missar. Tunnelseende är naturligt – vi är alla människor!
• Utvecklarna har domänspecifik kunskap. Vissa fel fångas mest effektivt av den som har djup förståelse för de tekniska aspekterna av kod.
• Samarbetet blomstrar när det får utrymme. De där fem minuterna handlar inte bara om buggar – det är ett tillfälle att diskutera krav, dela kunskap och att röra sig mot samma mål.

‍

Slutsats: Låt utvecklarna testa – det lönar sig

Låt utvecklarna vara första linjen i testningen. Det är en lågkostnadsförändring med stor ef-fekt: bättre kvalitet, avlastade testare och mindre tid lagd på buggadministration. Och som bonus? Ditt team kanske börjar samarbeta bättre än någonsin och detta kan leda till en positiv spiral genom att motivationen höjs.

Ge det ett försök. Även fem minuter kan förändra ditt teams kvalitet och produktivitet.

‍