En testares vardag

Början på en typisk dag i projektet

I det öppna välplanerade kontorslandskap vi sitter i är några av mina närmast placerade kollegor redan i farten när jag kommer in på morgonen. Vi som sitter närmast tillsammans arbetar i samma projekt. Projektet syftar till att förbättra en typ av ärendehantering. Exempel på denna ärendehantering är att en ansökan inkommer. Ansökan kan antingen behandlas helt automatiskt eller hamna för manuell hantering hos en handläggare beroende på kombinationer av vad som angetts på ansökan och vilka egenskaper kunden har i flera olika system.

Systemtest kan ske parallellt med tidig integration

Den här morgonen sitter min magnet-plupp kvar på lappen för att skriva testfall till ett av del-flödena för en viss typ av ärende på scrum-tavlan. Nästan alla testare jobbar just nu integrerat med angränsande system men min uppgift är att ”mocka” bort alla externa beroenden och testa enbart vårt system med hjälp av en motor för ”keyword driven testing”. Jag matar denna motor med order i XML-format om vad ärendehanterings-systemet ska göra och man kan även ge den order att utföra olika verifieringar mot ärendenas och handlingarnas tillstånd i databasen.

Att omvandla krav till testfall behöver inte vara rocket science

Efter scrum-mötet och fram till lunch utgår jag från kraven och skapar en egen bild av vad som ska verifieras, i stort sett en lista med meningar av typen ”Verifiera att ...”. Testar-hornen växer ut lite i pannan och jag kommer på en del negativa tester samt kombinationer som kraven inte verkar täcka helt. Påbörjar samtidigt en ny lista med de varianter av personegenskaper jag kommer att behöva göra mockar för, baserat på vad som måste testas. De aktuella kraven är rent funktionella och bra skrivna. Samtidigt på något sätt finns där i kraven en inneboende antydan till struktur och detaljerad design som vi kan ärva in i testarbetet.

Detta gör att vi på test får resurser över till att fokusera på olika komplexa scenarier i testfallsskrivandet istället för att detaljera krav.

Testdata är en annan femma

Efter lunch tar jag min lista på vilka egenskaper i termer av krav-språk varje kundvariant ska ha och vill för varje typ av egenskap dokumentera vilken XML-tagg i de blivande mock-filerna som representerar just denna egenskap, till exempel om kunden är bosatt inom- eller utomlands. Idag har jag otur då det inte rör sig om en 1:1-mappning mellan det språk kraven använder och de tjänster som kommer att anropas och som därmed måste mockas i mina tester. För att reda ut saken behöver jag få fatt på och skapa en gemensam bild med två av utvecklarna, vår kravare och aktuell arkitekt.

Vi kommer att behöva uppdatera existerande mockfiler med nya svar. Det är här den stora delen av arbetsinsatsen hamnar eftersom det är sista länken i kedjan. När de färdigutvecklade testerna körs och systemet hämtar mock-svaren från fil istället för externa system får vi en situation där vi måste debugga våra egna tester.

Allt XML-snickrande i textfiler sker just nu manuellt och även halvautomatiskt med skript, makron eller formler i MS Excel. Fördelen med dessa ”handverktyg” är enkelheten, flexibiliteten och möjligheterna att experimentera fram struktur och arbetssätt. Nackdelen är att de skalar dåligt när massan av tester växer och dessutom är MS Excel problematiskt att använda när antalet förgreningar/brancher i vårt versionshanterings-system subversion växer.

Hur kan man effektivisera rättning av nattliga automatiserade tester?

Under eftermiddagen kommer testansvarig på förvaltning förbi. Han utreder varför några av alla de tusentals tester som körs på natten fallerat. Inom projekten har vi dokumenterat vad testerna gör på ett grafiskt sätt i en testmodell för varje ärendeflöde. Vi kan därför på stående fot förstå vad som hänt, vad som borde ha hänt och vilket krav som är inblandat. Snabbt ser vi att det är funktionalitet som förändrats i projektet som påverkat resultatet av testerna. Just vårt projekt får ta sig an de fallerande testerna denna gång.

Senare på eftermiddagen börjar kontoret tömmas för dagen. Jag tar ett mellanmål, höjer skrivbordet till stående position och fyller på vattenflaskan för sista rycket.

Kort om författaren

Stefan Nerby har arbetat med systemutveckling sedan början av 1990-talet och med test och kvalitetssäkring av mjukvara sedan 2004. Han har verkat inom områden som testautomatisering, testdata och modellbaserad test. Stefan brinner för att vara användarnas företrädare, förvaltnings förlängda arm i projekt samt hitta sakerna i vardagen som gör arbetet mer effektivt.

Stefan Nerby på LinkedIn - AddQ, din partner för test