Varför är testare viktiga i mjukvaruutveckling?

Bakgrund

Jag jobbar som konsult med fokus på kvalitetssäkring i ett spännande projekt för Trafikförvaltningen i Stockholm, där jag är en del av ett team som består av både konsulter och Trafikförvaltningens egna medarbetare. Tillsammans har vi byggt ett system som verkligen gör skillnad för människor som är beroende av färdtjänst och sjukresor.

Systemet omfattar en modern plattform baserad på Dynamics CRM som hanterar allt från ansökningar om tillstånd till beslut, och två webbportaler som gör det enkelt för kommuner och vårdgivare att samarbeta med Trafikförvaltningen. Det är ett stort system med över      15 000 användare, så kvalitet och stabilitet är verkligen viktigt.

Jag är övertygad om att kvalitetssäkring är avgörande för framgångsrika mjukvaruprojekt, men jag vet också att många organisationer fortfarande tvekar att investera i dedikerade testare. Därför ville jag låta andra röster i branschen tala. Jag intervjuade sex av mina teammedlemmar med olika roller: utvecklare, produktägare, scrum master, verksamhetsspecialist och lösningsarkitekt. Genom deras perspektiv och konkreta exempel hoppas jag kunna visa varför testarrollen inte är en "nice to have" utan en nödvändighet i moderna utvecklingsteam. Deras svar visar tydligt vilken skillnad en testare gör, och det är det jag vill dela med mig av i den här bloggen.

Problemet: Osäkerhet och stress inför leveranser

I många projekt uppstår stress och osäkerhet när det är dags att leverera ny funktionalitet till produktion. Utan systematisk kvalitetssäkring blir frågan "är vi verkligen redo?" svår att besvara med säkerhet. En återkommande hög punkt i svaren är den trygghet som testaren skapar i teamet.

Katarina, som är scrum-master, uttrycker det enkelt: "Testaren hjälper till att skapa trygghet i planerad produktionsleverans."

Love, en av webbutvecklarna, beskriver hur testarens närvaro påverkar hans arbete: "Testarens närvaro gör att jag kan fokusera mer på själva utvecklingen eftersom någon annan systematiskt granskar kvaliteten. Det ger trygghet och gör att jag inte behöver oroa mig för att missa detaljer."

Miia, som är produktägare, lyfter fram den direkta påverkan på beslutsfattande: "Testaren helt enkelt hjälper mig att ta beslut -- är vi redo att releasa/produktionssätta ny version av produkten eller ska vi skjuta fram releasen." Hon fortsätter: "Vi litar på våra testare och behöver inte oroa oss inför releaser. Vi vet att om dom säger att vi är redo så är vi redo."

Kommunikationsutmaningen: Olika språk, olika perspektiv

Utvecklare pratar ofta teknik, verksamheten pratar processer och behov. Mellan dessa världar kan missförstånd lätt uppstå, vilket leder till lösningar som inte möter användarnas verkliga behov. Flera intervjupersoner beskriver testaren som en viktig länk mellan utvecklare och verksamhet.

Josefin, verksamhetsspecialist, säger: "Testaren är ofta en brygga mellan verksamhet och utvecklare som ofta kan översätta tekniska termer till ett språk som även vi förstår."

Miia utvecklar detta perspektiv: "Testare hjälper översätta utvecklingen till funktionalitet. Testaren är ju den som kan användargränssnittet bäst i utvecklingsteamet och förstår verksamhetens arbetssätt och behov och därmed kan kommunicera tydligt hur utvecklingen påverkar dom."

Love beskriver samarbetet konkret: "Testare har väldigt bra koll på verksamheten och hur dom jobbar vilket gör att de kan svara på många användarspecifika frågor. Vi utvecklare har bra koll på hur logiken i systemet fungerar och kan förklara för testarna varför och hur viss funktionalitet fungerar."

Lösningen börjar tidigt: Förebygg i stället för att åtgärda

Många tror att testning börjar när koden är klar, men då är det ofta för sent. Problem som upptäcks sent i processen kostar mycket mer tid och pengar att åtgärda än om de fångas upp redan i kravfasen. Det råder enighet bland alla intervjuade om att testning bör börja så tidigt som möjligt i utvecklingsprocessen.

Daniel, systemutvecklare, menar att testning bör börja "gärna redan vid kravställning där testningsperspektiv kan påverka hur krav formuleras och vilka acceptanskriterier definieras."

Josefin förklarar varför: "Jag tycker att testaren ska vara med redan i början av kravställningen/behovsbeskrivningen för att kunna ställa frågor som man annars ofta kommer på efter utveckling. Genom att identifiera frågorna tidigt kostar det både mindre tid och mindre pengar."

Miia understryker detta: "Desto tidigare desto bättre. Det är aldrig för tidigt att ta in testare. Även om produkten är inte ens redo att konkret testa så behövs det planeras in hur man ska kunna testa, hur man ska kunna använda produkten."

Objektivitet: Varför vi inte kan testa vårt eget arbete

Det är mänskligt att bli blind för sina egna misstag. När vi utvecklar något blir vi investerade i att det ska fungera, vilket gör att vi omedvetet testar med förväntningen att det ska lyckas i stället för att aktivt leta efter problem.

Katarina lyfter fram en viktig skillnad mellan hur utvecklare och testare tänker: "En utvecklare kan också testa dock har en utvecklare och en testare olika mindset. En utvecklare testar med mindset att det ska fungera. En testare testar med mindset att hitta fel och hittar därmed oftare fel i leveransen."

Daniel jämför det med att korrekturläsa sin egen text: "Om man testar egna saker så är så att korrekturläsa egen essä. Man blir blind för fel och corner-cases. Testare fungerar då som second-opinion som på oberoende sätt kan verifiera ändringar."

Marcus, lösningsarkitekt, beskriver hur detta påverkar utvecklarna positivt: "Utvecklingen påverkas positivt indirekt, när utvecklare vet att testning skall genomföras blir de noggrannare."

Verkliga konsekvenser: När testning saknas eller lyckas

Teorin är en sak, men vad händer egentligen när testning saknas eller när testaren fångar kritiska problem? Exemplen från vårt projekt visar tydligt skillnaden.

Daniel delar ett exempel på när testaren fångade ett allvarligt säkerhetsproblem: "Testare upptäckte ett problem med behörigheter till känsliga delar av systemet innan det skulle produktionssättas."

Han berättar också om konsekvenserna när testning saknas. Detta är ett exempel från ett annat projekt: "Bristen på testning ledde till att jag ändrade koder på priser för licenser i bokföringssystem som gjorde att fel pris tilldelades till TV-licenser. Det ledde till felaktiga beräkningar (den viktigaste funktionen i systemet) och manuell datarättning i produktionsdatabas."

Miia beskriver hur testaren räddar situationer: "Det finns tillfällen där ny utveckling hade orsakat fel med stora konsekvenser i produktion om inte testare hade hittat och kommunicerat problemen i god tid."

Den dolda värdet: Systemkunskap över tid

I projekt där teammedlemmar kommer och går är kontinuitet i kunskap en utmaning. Testaren blir ofta en kunskapsbärare som förstår både hur systemet fungerar tekniskt och hur det används i praktiken.

Daniel pekar på ett ofta förbisett värde: "Man ska inte underskatta kunskapen om systemet och krav som testare samlar på sig under sin tid i projektet. Det hjälper att felsöka, förstå processen i systemet etc."

Han ger ett konkret exempel: "Inga utvecklare som levererade första versionen av systemet jobbar längre och de nya känner inte till alla komponenteter och hur de bör fungera, det kan dock testare som kan sprida kunskapen."

Josefin beskriver hur detta påverkar arbetet: "Utan testare hade vi inte haft samma struktur på testscenarier, speciellt inte när det gäller end-to-end-tester eftersom det är väldigt tidskrävande och kräver stor noggrannhet. Vi som verksamhetsspecialister hade inte varit i närheten av att hinna testa allt som vi nu kunnat med hjälp av testare."

Mätbara resultat

För vårt projekt med över 15 000 användare och kritiska samhällsfunktioner är stabiliteten avgörande. Resultaten talar för sig själva.

Daniel ger ett konkret mått på vad testaren bidrar med: "Tack för noggranna tester i varje sprint (både manuella och automatiserade) kan vi förhindra möjliga incidenter i produktionsmiljö som kan drabba verksamheten (myndigheten) eller invånare i Region Stockholm, vi har faktiskt inte haft grova fel på flera år."

Marcus beskriver det från ett arkitektperspektiv: "Noggrant planerad och genomförd testning påverkar leveransen med högre kvalitet och stabilitet."

Miia summerar utvecklingen i teamet: "Utvecklingstickets har blivit tydligare för att testare behöver ju förstå vad är det man ska testa. Vi har färre fel vid produktionssättningar. Samtidigt har vi blivit mognare att våga stoppa releasen också om testarna känner så. Det naturligtvis leder till färre produktionsfel."

Skillnaden utan testare

Vad händer egentligen i team som saknar dedikerad testare? Flera av mina kollegor har den erfarenheten och kan jämföra.

Love beskriver skillnaden: "Skillnaden var att utvecklare fick testa sitt eget arbete, vilket ofta ledde till att buggar och kravmissförstånd slank igenom. Projektet gick långsammare eftersom fel fick rättas i efterhand."

Josefin berättar: "Det fanns inte tid till att utföra lika många tester. Ofta testades också bara funktionen och inte hela flödet, därmed missades buggar i andra delar av flödet. Arbetet blev mer reaktivt än proaktivt."

Marcus förklarar resursproblemet: "I ett team utan testare måste personer i andra roller testa. Detta medför att tillgänglig tid för till exempel utveckling minskar då utvecklare måste testa mer, samt att kvaliteten sjunker då den som testar egna förändringar inte testar förutsättningslöst."

Ett komplett team

Josefin uttrycker det tydligt: "Utan testare anser jag inte att vi är ett komplett team."

Daniel är lika tydlig i sin rekommendation: "Jag har svårt att tänka på någon typ av projekt där testarrollen inte skulle vara viktigt. Kanske demo-projekt, PoC, interna applikationer för oss själva (typ todo-listan för teamet med snabba ärenden), men allt annat som säljs på riktigt SKA ha testarroller i teamet."

Han fortsätter med en stark varning: "Om man inte har testare eller testarrollen, hur säkerställer man kvalité? Oavsett anledningar varför man inte har testare så behöver man erkänna att man INTE har riktigt koll på kvalité och att man INTE följer ingenjörs principer inom software engineering, att man förhandlat bort säkerhet och kvalité av produkten."

Avslutning

Intervjuerna visar tydligt att testaren är en oumbärlig del av ett utvecklingsteam. Testaren bidrar inte bara med att hitta buggar, utan skapar trygghet, fungerar som en brygga mellan teknik och verksamhet, fångar problem tidigt, och bygger värdefull systemkunskap.

Marcus sammanfattar det kort och koncist när han beskriver vad han skulle lyfta fram först om han skulle argumentera för en testare: "Snabbare leveranser med högre kvalitet."

Miias rekommendation till produktägare eller projektledare utan testare är enkel: "Skaffa en, nu. :)"

För Trafikförvaltningens system, med över 15 000 användare och kritiska samhällsfunktioner, har testaren varit avgörande för att säkerställa att systemet fungerar som det ska. Bland annat genom noggrann testning har teamet kunnat leverera en stabil och pålitlig lösning som förbättrar livet för de som är beroende av sjukresor och färdtjänst i region Stockholm.