Når testautomatisering går galt

Dette er en ærlig beretning om, hvor galt det kan gå, når man starter forkert.

Men først en tak til Unions for at sponsere mine dyrtkøbte erfaringer. Vi troede alle sammen på det, men det blev desværre ikke den succes som vi alle gerne ville have haft det til at være.

Denne historie er mine refleksioner over et mine af de første testautomatiserings projekter.

Med en business case i hånden, som godtgjorde for en besparelse på nogle mio. kr. pr år, plus et kvalitetsløft af vores webapplikation og en intro fra en ”ekspert” i brugen af QTP, så begav vi os ud i projektet at automatisere regressionstesten.

Eksperten gennemførte et lille pilotprojekt, som viste os hvordan vi forholdvis nemt kunne optage og afspille de testcases som testerne havde designet. Det så lækkert ud og var ret meget en wow oplevelse, at se webapplikationen blive betjent automatisk. Så hvorfor skulle det dog ikke blive en succes.

Jeg fik en kort introduktion til hvordan vi kunne optage og afspille og hvad QTP ellers havde af smarte ting. Så med min udviklerbaggrund og en del erfaring med automatisering af unit test, så kunne det da ikke gå galt.

Vi mente at vi havde alle de rigtige forudsætninger:

• En testproces som kørte på skinner
• Super dygtige testere 
• Engagerede udviklere og testere
• Flere tusind testcases
• Scrum som udviklingsproces
• Automatisk deployment af miljøer og byggemand bob til at styre dem
• Automatisk udrulning af databaser og patchlevels
• Et Quality Center som var perfekt styret og sat op
• Et Quality Center team til vedligeholdelse af tilpasningerne
• Alle krav i QC og styring af kravdækning
• En skarp testmanager
• En skarp udviklingschef
• En udvikler (undertegnede) til at varetage testautomatiseringen

Webapplikationen var bygget op på et ganske godt grundlag, med et eget udviklet framework i jsp og javabeans ( udviklerne kan nok bidrage med lidt mere her ? ).

Målet var at automatisere regressionstesten. I sig selv et rigtig godt startsted for testautomatisering.

Det første vi gjorde var, at begynde at lære QTP at kende. QTP kan rigtig mange ting, men der er ikke rigtig noget, som fortæller om, hvordan man skal starte. Man kan selvfølgelig starte med Mercury’s flight booking applikation – den viser faktisk vejen ret langt hen af vejen, men den fortæller ikke principperne i hvordan man skal starte. Så det handlede mest om at forsøge at optage nogle skevenser, dernæst tilrette dem, så de blev datauafhængige og så sætte dem sammen til en testcase.

Det så også rigtig godt ud til at starte med og vi kom også rimelig langt, men der blev lidt for meget spaghettikode og vi fik aldrig tænkt over, hvilke lag testautomatiseringen skulle indholde og hvorfor. Det bevirkede at det blev rigtig svært at vedligeholde testen og fejlfinde i den. QTP er så heller ikke verdens stærke debugging værktøj og der følte jeg mig sat noget tilbage, da jeg var vant til at udvikle i visual studio.

Da det ikke rigtig lykkedes med QTP, tog vi kontakt til Examinator og startede et pilot projekt op omkring automatisering med TestBench og TestDrive. Produktet så meget lovende ud og vi håbede til det sidste at det ville lykkedes. Men for mit eget vedkommende, så tiltalte deres produkt mig ikke rigtig, da jeg synes at jeg mistede kontrollen over hvordan automatiseringen skulle køre – der var næsten ingen scripting muligheder og alt var point and click – du var virkelig lagt i hænderne på værktøjet og det muligheder oig begrænsninger.

Til sidst mistede alle troen på at det ville blive en succes og jeg måtte videre til nye opgaver.

Hvad har jeg så lært med tiden?

• at man skal bygge frameworket til testautomatisering op lige efter bogen.
• at frameworket er delt op et basis framework til og et framework dedikeret til den applikation, som skal automatiseres.
• at det kræver et meget test samarbejde mellem en udvikler og en tester
• at det kræver tålmodighed fra ledelsen
• at man er godt hjulpet, hvis man bliver kickstartet rigtigt og får bygget det rigtige framework fra starten.
• at man ikke skal tro at automatisering af capture/replay
• at man skal kende sit værkstøj og dets begrænsninger
• at testautomatiseringen ikke ligger i testafdelingen, men mest af alt skal placeres i udviklingsafdelingen.
• at det kræver rigtig god kommunikation og kemi mellem udviklere og testere

Jeg har ikke det eksakte tal på, hvor meget at det kostede, men det var ikke billigt at få den lærdom. Vi brugte 6 måneder på at få det til at lykkes, men uden noget rigtig held.

Jeg håber at mine gode kollegaer fra den tid kan bidrage med deres syn på dette indlæg, jeg tror i hvert fald at der mere vi kan lære.