Når manuel unit test begynder at drive dig til vanvid

Har du nogensinde siddet og sammenlignet xml dokumenter, ledt efter forskelle i små og store bogstaver, manglende attributter og værdier som ligger uden for scope?

Hvis du har så kan du må måske blive inspireret her.

Situationen var, at vi på dette projekt havde identificeret integrationspunkterne som de mest kritiske og vi havde reelt set kun mig som tester. Men ok – sådan er det vidst mange steder. Jeg havde i flere dage siddet og kigget mig fuldstændig blind i xml dokumenter, attributter og manglende elementer og værdier som ikke var lige inden for scope – og det var ved at drive mig til vanvid.

Det var ikke helt inden for scope at vi havde talt automatisering af disse test, men jeg måtte bevise overfor projektledelsen at det kunne betale sig. Så en dag hvor projektlederen havde ryggen til mig en hel dag, så tog jeg fat og fik automatiseret omkring 30 ud af de 200 af de unit test jeg sad og skulle køre manuelt. Med NUnit var det relativ nemt at kode de unit tests, for jeg var så dybt inde i hvordan testcasene var bygget op, at der kun var slaveprogrammering tilbage.

Projektledelsen var godt klar over at unit testen var vigtig og at den tog i omegnen af 4-5 dage at gennemføre manuelt, med stor risiko for at testeren var helt skeløjet efterfølgende.

Nu tog det under 2 min at køre de 30 unit test igennem......

Projektledelsen var super begejstret, så efter endnu 5 dage, så havde jeg automatiseret de resterende 170 unit tests. Nu tog testen ca. 10 min at gennemføre. Men det er også en horibel forskel fra 4-5 dage og til 10 min.

Så var jeg nu arbejdsløs? Næ, nu kunne jeg begynde mig at koncentrere mig at designe endnu dybere test cases og begynde at test de andre dele af systemet.

Gevinsten var rigtig stor for udvikleren som sad med integrationerne, for det som han oplevede var, at han kunne få lukket sine opgaver hurtigt. Udvikleren og jeg sad i tæt dialog, udvikleren kodede og jeg trykkede på knappen for at køre unit testen, udvikleren havde nu et svar 2 min efter på det interface og kunne rette ind straks. Unit testen kunne fortælle udvikleren helt præcis hvor der var fejl og selvfølgelig var der tiltider også fejl i testen, men det vigtigste var at der blev skabt en rigtig god dialog mellem udvikleren og projektet og integrationspunkterne blev nu konstant overvåget af unit testen.

Fordi unit testen var så nem at køre, og fordi udvikleren fik svar tilbage straks, så blev der ikke brugt tid på at rapportere defects. Kun i de tilfælde hvor udvikleren var på andre opgave, var vi nød til at dokumentere en fejl grundigt.

Det er svært at få dækket alle scenarier med test cases, så der var også situationer var systemet fejlede men unit testen lyste grønt. Så nu gik øvelsen ud på, at få unit testen til at lyse rødt – altså kode en unit test, som rapporterede en fejl netop i den nye situation. Herefter var der kun hårdt arbejde tilbage for udvikleren og et tryk på unit test knappen i ny og næ.

Alt i alt en ret stor succes for testen. Det endte med at ca. 350 unit test var automatiseret og de blev kørt på omkring 10-12 min. Jeg kan på det varmeste anbefale, at man koder sig ud af sådanne situationer, så man ikke brænder testerne helt af.

Kickstartet med 120 regressionstest på 4 uger

Testautomatisering kan også være en succes, det behøver ikke gå så galt som jeg skrev om i mit sidste indlæg.

Jeg blev stillet overfor en udfordring, som jeg var meget tæt på at sige nej til, men mit konkurrence instinkt drev mig til, at kaste mig ud idet.

Kunden havde stillet mig over for det opgave, at de ville have automatiseret 120 regressionstest, som skulle køre på deres daglige byg hver nat. De havde i forevejen automatiseret nogle af regressionstestene, så de ville bare have, at jeg skulle automatisere resten inden for de næste 3 uger.

Men .... med en del erfaring i baggagen, så udspurtge jeg udviklingschefen og testmanageren grundigt omkring, hvordan deres miljøer var sat op, hvordan deres testprocesser var skruet sammen, om testcasene havde den rigtige detaljeringsgrad og om de havde mandskab til at tage over, når nu vi havde nået målet.

Det så ud til at de havde de rette forudsætninger, men jeg måtte stille spørgsmålstegn til det eksisterende automatisering, for det det lød vidst som om, at der var noget kunne være en stor risiko.

Hvad jeg erfarede var, at den eksisterende kode, var lavet på næsten samme erfaringsgrundlag, som jeg havde på et af mine første projekter. Ganske rigtigt, koden var stort set udbrugelig og udviklingschefen måtte slå sig godt i tøjret, da jeg måtte meddele ham, at han skulle acceptere, at de sidste 6 måneders indsats skulle skrottes.

Med mit efterhånden mangeårige basisframework i hånden, så kunne jeg inden for den første uge danne største delen af frameworket til applikationen. De første regressionstest kom også i mål, og vi kunne efterhånden se, at der nu kun var hårdt arbejde tilbage.

Næste step var at få implementeret testene i det daglige byg og rapporteringen.

Resten af regressionstestene kom på plads i fjerde uge og nu var der kun uddannelse af deres udvikler og en tester tilbage. De to personer tilsammen skulle tage over og fortsætte automatiseringen. Udvikleren kunne nu se, hvordan han med frameworket, var i stand til at kode robuste testscripts. Testeren blev uddannet i at scripte en smule, så han kunne bygge testcasene op og udvikleren kunne varetage det hårde bagvedliggende programmeringsarbejde.

Jeg har desværre ikke hørt, hvordan det siden hen er gået dem, men jeg forstiller mig at kan bidrage med nogle kommentarer til dette indlæg, med lidt viden om hvordan gik efterfølgende.

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.