Testare kan inte programmera!

testare.jpg

Det finns många testare som vill automatisera tester, men som inte tror sig kunna programmera. Det är lätt att de söker sig till olika typer av automatiseringsverktyg som förväntas hjälpa till, men som lika gärna kan stjälpa automatiseringsprojektet.

Vad som ofta händer är att det snabbt skapas en stor mängd test (förhoppningsvis relevanta). Sen kommer test som kanske inte borde göras med just det verktyget. Men när det enda verktyget är en hammare, då ser alla problem ut som spikar…

Antalet testfall ökar. Förhoppningsvis ökar även den relevanta testtäckningen. Sen kommer de oundvikliga ändringarna i produkten som skall testas. Plötsligt slutar många testfall fungera, och utvecklingen hamnar i ett läge där det är osäkert om produkten fungerar som tänkt.

Men utvecklingen fortsätter, de automatiska testerna är ”testarens ansvar”, ingen annan vill sätta sig in i verktyget som används (eller hindras av höga licenskostnader). Under tiden måste testaren både uppdatera gamla tester och skapa nya i takt med utvecklingen.

Till slut når kaoset nivån att testerna som inte går igenom stängs av. Nästa steg är att kasta ut allt och återgå till manuell testning med alla de nackdelar det innebär. 

Nåt år senare är delar av teamet utbytt och en ny testare hittar ett nytt och fint verktyg som skall göra det lätt att automatisera….

Men vad finns det för alternativ?
Ett sätt är att undvika specialverktyg så långt det går och skriva testerna i ett programmeringsspråk. Det behöver inte vara samma språk som för produkten.

Några stora fördelar med det är att:
Mycket lägre tröskel för att få hela teamet delaktigt. De agila principerna om ”Collective Code Ownership” gäller även för testkod. Även om testerna är skrivna i ett annat programmeringsspråk än produkten som skall testas så är de begripliga för utvecklarna. Speciellt som de oftast kan använda samma utvecklingsmiljö för all både test- och produktkod.

Att kunna få hjälp av en mer erfaren programmerare är mycket värt för den testare som inte trodde sig kunna programmera. Ofta är möjligheterna att återanvända kod större. Testautomatiseringen kan dra nytta av några decenniers erfarenhet av programmering. ’Clean Code’ är lika viktigt för testkod som för produktionskod. Utvecklingsmiljön (IDE) ger ofta bra stöd för debugging, kontroll av syntax m.m. Versionshantering, kodgranskning och ’merge requests’ kan hanteras på samma sätt som för övrig kod. Testaren blir bättre på att programmera.

Nackdelar då?
Det kan vara en lite brantare startsträcka, men min erfarenhet är att tidsvinsten i långa loppet är mycket större.

Så mitt råd till testare är: tro på dig själv. Du kan programmera!

IMG_8050-4.jpg

Oskar Drenske är en utvecklare som fokuserat sig på det han brinner för – kvalitet.