Ge dig själv tid att testa.

En testkonsults arbetsdag är ofta oförutsägbar och överraskande – något som avskräcker somliga men attraherar andra. Personligen uppskattar jag omväxlingen och de skiftande arbetsförhållandena då det håller mina reflexer på topp och gör att jag aldrig får långtråkigt.

En del arbetsuppgifter är förstås mer intressanta än andra. En del saker kastar jag mig gärna över, och andra skyr jag som en katt vatten. Att testa browser-kompatibilitet, till exempel, tycker jag är oerhört oupphetsande – och svårt! Inte tekniskt komplicerat, men svårt att inte missa något. Svårt, också, att prioritera – det finns ju oändligt många kombinationer med webbläsarversioner, skärmupplösningar, operativsystem, …

Tråkigt är också att upprepa samma test gång efter annan på nya mjukvaruversioner – tacka vet jag automatiserade regressionstester! Därför har jag den senaste tiden ägnat en del av min personliga utvecklingstid åt att doppa tårna i det hav som är kontinuerliga integrationer och byggen, kombinerade med sviter av automatiserade enhets- integrations- och systemtester. Det är ett stort hav med enorma möjligheter för den som har tid och råd att sålla, fokusera och utbilda sig. Än så länge har framförallt en lärdom satt sig i mitt huvud: försök att inte ha en övertro på testautomatisering. Att automatisera ett test handlar inte om att testa något, egentligen, och det inbegriper sällan att hitta buggar. Det handlar om att snabbt kunna få en känsla för om en ny mjukvaruversion fortfarande uppfyller vissa krav.

Alla företag jag har besökt har, självklart, haft versionshantering av sin källkod. De har också haft ett byggsystem som känner av när ny kod checkas in och då bygger relaterade komponenter och exekverar aktuella enhetstester – allt för att ge programmerarna förtroende för den nya koden och bekräftelse på att de inte haft sönder något. Det jag har saknat från många arbetsplatser är att de som jobbar med test också har insikt i den här processen och medvetenhet om vad som faktiskt testas automatiskt vid varje kodbygge.

Känslan jag har är dock att denna insikt och medvetenhet är på uppgående – samtidigt som en annan känsla säger mig att efterfrågan på ”tekniska testare” ökar kraftigt. Givetvis finns ett värde i att utrusta sig med testare som har förståelse för hela kedjan av mjukvaruutveckling, är bekanta med system för kontinuerliga byggen och kan hantera verktyg för automatiserade tester.

Testare är ett serviceyrke, och ju mer vi kan desto mer kan vi hjälpa till med – så mitt tips är att lära sig de verktyg och system som finns till hands, inte minst för din egen skull. Ju mer förtroende du kan få för att ett nytt bygge av mjukvaran uppfyller förväntningar – medelst kontinuerliga byggen, integrationer och automatiska tester – desto mer tid får du ju över till det du gör bäst, att testa.

Så lär dig subversion eller git, lär dig maven eller ant, lär dig Jenkins eller CruiseControl, lär dig JUnit, Selenium, Cucumber, lär dig något skriptspråk … vad som nu passar in i just ditt team och ditt projekt. Ge dig själv tid att testa!