Äntligen fredagen den 13:e!

System beter sig konstigt, funktioner slutar att fungera, applikationer kraschar osv. Men är det verkligen testaren som har otur? Nej så klart inte. Däremot så ser testaren till att genom kunskap, erfarenhet och inställning skaffa sig en dos “otur” som hen kan koppla på när det behövs som bäst.

Så här i juletider blir vi påminda om olika traditioner, vissa som vi håller fast vid, vissa som bryts och vissa byts ut mot nya. En tradition som vi agila testare gärna vill bryta är den att test är en aktivitet som utförs när programmerarna har gjort sitt jobb, det vill säga en klassisk överlämning. Även om många team i dag skulle säga att man har lämnat vattenfallsmodellen och nu är agila så är just överlämning till test något som fortfarande är vanligt.
Tips: Om “test” har en egen silo på er Kanban-board så är inte testarbetet fullt integrerat i er utvecklingsprocess.

I dagens agila team talas det ofta om att alla team-medlemmar har ansvar för test. Det stämmer förvisso men för att inse vad test är så behöver vi först reda ut ett av de vanligaste missförstånden: Verifiering är inte detsamma som test. Test är så mycket mer än verifiering.

Inom Rapid Software Testing har James Bach och Michael Bolton valt att använda orden “checking” och “testing” där checking är den typ av verifiering som kan utföras av förprogrammerade maskiner, t ex automat-tester, medan testing är den del av testprocessen som endast en tränad människa kan utföra. Man kan dra liknelsen med kompilering kontra programmering: Kompilering utförs av maskiner och programmering är det som vi människor ägnar oss åt. För att citera ovan nämnda Bach och Bolton: “Ingen pratar om automatiserad eller manuell programmering.” (fritt översatt)

Denna tankegång är viktig att ha med sig när man ser över sin testprocess. Gör vi Test på riktigt eller har vi enbart fokus på automatiserade tester? När många av de agila utvecklingsteamen i dag saknar en dedikerad testare så blir test lätt ett tråkigt måste som tar tid och energi. Det som vi tycker är tråkigt vill vi inte göra och har vi då medel att få någon annan att göra det, t ex en dator, så är det lätt hänt att vi försöker automatisera bort all “testning”. Och så har vi då fallit i verifiering kontra test-fällan.

Givetvis behöver vi automatiserade tester (vi borde verkligen börja kalla det för “automatiserade verifieringar”)! Massvis av dem. Men gör dem av rätt anledning. Syftet med automatisering är inte att spara tid, det är att konsekvent verifiera ett förbestämt beteende i systemet. Så sträva mot automatisering för att det gör produktens kvalitet högre och er utvecklingsprocess stabilare. Ge produkten och teamet vad de behöver. Att verifiering som utförs av en dator oftast är både snabbare och säkrare jämfört med en människa är bara en bonus.

Den agila testarens jobb är inte att hitta buggar utan att förhindra dem. Det gör vi genom att vara med överallt där vi kan och får (och får vi inte så ser vi till att vi får ändå). Med hjälp av sin “otur”, kan testaren hjälpa till i alla utvecklingsled genom att t ex analysera kraven, testa designen, sitta med vid kodgranskning, utföra Utforskande Testning, utveckla autotester, granska releaseprocessen och pipelines med mera.

I alla team behövs det någon som är driven och brinner för test. Har ni ingen testare i just ditt team? Undersök om ni kan få hjälp av en testare från ett annat team för en dag. Kanske kan ni besöka ett team, en organisation eller en kollega som arbetar aktivt och brett med test? Eller ta del av konferenser, meetups, bloggar och poddar som bevakar den stora, roliga och utmanande världen som test trots allt är. Vi behöver alla lite hjälp på traven med att kontrollera vår “otur”.