Vem ansvarar för din testautomatisering över tid?

Men vi tror att det finns en djupare, underliggande fråga bakom den:

”Vem bör ansvara för testautomatisering?”

Och på ett ännu djupare plan:

”Vilka olika delar av testautomatiseringen kan man ansvara för?”

Testautomatiseringens två delar: Test Harness och slutanvändarflöden

På Eficode delar vi gärna in testautomatisering i två tydliga delar:

Test Harness

En Test Harness kan definieras på många sätt, men vi definierar den som ”allt som krävs för att ett testfall ska kunna köras”. Huvudkomponenterna är:

• de valda testverktygen

• miljöerna

• testdatan

• lösningen för Continuous Delivery

• andra stödverktyg (t.ex. Docker)

Slutanvändarflöden

Den andra delen av testautomatiseringen handlar om innehållet i ett testfall. Vad gör det och varför? Detta är nära kopplat till mjukvarans krav och de affärsproblem som den löser.

Har du någon gång funderat på varför ansvaret så ofta skickas runt när man försöker lösa testfel? Du hör saker som: ”Våra testfall har misslyckats i pipelinen, vem kan åtgärda dem?” Det här är anledningen. Testet kan misslyckas för att något är fel i Test Harness, eller för att testfallets affärsinnehåll inte är anpassat till själva applikationen som testas.

Problem med ansvarsfördelningen under projektet

När testningen inte hinner med funktionsutvecklingen

I projektets tidiga faser pågår det ofta ett slags kapplöpning mellan funktionsutveckling och utveckling av Test Harness. För att testa det som har utvecklats behöver du också lägga till nya funktioner i Test Harness. Det kan vara lockande att välja den enkla vägen och ”bara bli klar” med Test Harness.

Men när funktionaliteten växer och fler testfall automatiseras går, enligt vår erfarenhet, merparten av tiden åt till att analysera varför befintliga testfall har misslyckats. Det innebär att du får allt mindre tid att skriva nya testfall. Känner du igen dig?

När ingen tar ansvar

Du får problem om ingen tar ansvar för delen med slutanvändarflöden i testautomatiseringen. I det värsta fall vi har sett kan QA-specialisterna inte eller vill inte ens prata med funktionsutvecklarna: ”Jag skrev inte de här testerna, så jag ansvarar inte för att de misslyckas.”

Dessa situationer försvårar analysen av testfallen ytterligare och kan leda till stora problem för teamet, eftersom nya funktioner kanske inte testas alls – åtminstone inte automatiserat.

Lös problemen med ansvarsfördelningen

Det finns många sätt att hantera dessa två problem. Till exempel:

• en dedikerad QA-specialist eller en SDET-roll i teamet kan, med hjälp av resten av teamet, hantera båda utmaningarna. 

• en testare kan ansvara för End User Workflows medan utvecklingsteamet ansvarar för Test Harness. Det fungerar utmärkt eftersom det naturligt främjar tvärfunktionella team. 

• kanske kan produktägaren eller någon annan affärsansvarig, med stöd från en QA-expert och resten av utvecklingsteamet, samarbeta med hjälp av ATDD – verksamheten skriver End User Workflows och utvecklingsteamet automatiserar dem.

• ett av de bästa sätten att tidigarelägga testrelaterade frågor är att ha experten eller experterna med redan när nya funktioner definieras, tillsammans med andra intressenter, exempelvis säkerhetsrepresentanter. På så sätt blir testning och förbättring av Test Harness en del av funktionsdesignen.

Det finns inga lösningar som passar alla. Det måste fungera i just din kontext. Men när ni diskuterar arbetssätt behöver ni komma överens om följande: 

• Hur skapar vi en Test Harness av hög kvalitet? 

• Hur säkerställer vi att End User Workflows representerar det vi faktiskt vill uppnå?

Ansvar för testautomatisering under förvaltningsfasen

Om dina testfall ständigt misslyckas i onödan, om det tar en evighet att analysera testfel eller om det tar för lång tid att ens implementera ett testfall, lider du troligen av betydande teknisk skuld.   

Kodkvalitet har utvecklats från det klassiska måttet svordomar per minut till hur enkelt och friktionsfritt det är att lägga till och underhålla automatiserade testfall i dina applikationer. Om irritationen är ständig är det ett tecken på att det är dags att betala av skulden. Det lönar sig på sikt, eftersom 60 % av en mjukvaras livslängd ägnas åt underhåll. 

När ditt mjukvaruprojekt är i förvaltningsfasen bör du inte förvänta dig särskilt många förändringar. Precis som själva mjukvaran behöver Test Harness och End User Workflows då bara minimala uppdateringar. 

Men även om arbetet kanske inte är omfattande kan det vara klokt att, tillsammans med projektet, överföra det till ett team som ansvarar för att förvalta flera applikationer. Ofta är det inte ens meningsfullt att göra detta internt. Det kan vara mer rimligt att outsourca både applikationen och underhållet av testautomatiseringen.

Kort sagt: Vem bör äga testautomatiseringen?

Så vem bör äga testfallen? Vi på Eficode anser att alla som deltar i projektutvecklingen bör äga testerna. Hur arbetet fördelas mellan Test Harness och End User Workflows bör alla parter uttryckligen komma överens om. 

I slutändan är tester en del av produkten, precis som källkoden.