Test automatisering: derfor skal du ikke starte med værktøjer

Læsetid: ca 6 min.

Test automatisering er noget man hører meget om i forbindelse med de agile projekter. Der er meget hype omkring emnet, og oplægget 5 ways automation is like sex fra sidste års Agile Testing Days er med til at bekræfter den teori:

Cassandra Leung:

In my experience, automation is a lot like sex in high school; everyone says they’re doing it but, in reality, most aren’t even close to starting. And many that are have no idea what they’re doing!

Fordelene ved at automatisere testen er ofte opvejet af omkostningerne ved at komme i gang. De succeshistorier, der bobler frem til forskellige konferencer, er ikke altid reproducerbare i den kontekst og organisation man sidder i. Man kommer nemt til at fejle, ved blot at prøve gentage “det de andre gør”. En af grundene til det i min optik handler om at man fokuserer for hurtigt på værktøjer.

At falde for fristelsen

Er man lidt teknisk mindet, vil synet af et nyt værktøj i sig selv være en oplevelse og give lysten til at kaste sig ud og prøve det. Sådan kunne det være, selv om der ikke foreligger en anden strategi bag end antagelsen om at det vil spare tid, hjælpe med at teste noget mere og gøre testen mere konsistent.

Så hvorfor skal man ikke starte med værktøjer, når man vil i gang med at automatisere testen? Der er i hvert fald mindst tre gode grunde, som alle er forbundet med en vis risiko for at:

  • det vil tage mere tid end forventet (og dermed får man ikke noget brugbart op og køre inden for den afsatte tid / budget).
  • det bliver sværere og sværere at vedligeholde det, i takt med ændringer til systemets krav bliver flere og større end man kan nå at få bugt med.
  • fejlene slipper alligevel igennem, selv om man har automatiseret test.

Det tager længere tid end forventet

Den nye spændende værktøj lover at man hurtigt kan komme igang. Måske er det noget som kan optage testforløbet ved at klikke rundt i systemet, eller en GUI til at lave test steps uden at skulle tænke på at skrive kode.

Alligevel støder man ind i problemet: test scriptet er ikke stabilt, ikke konsekvent eller mangler et redskab til at gøre noget specielt som værktøjet ikke lige understøtter. Et typisk eksempel her, er et script som kunne være optaget og eksekveres fint i en browser, men fejler hårdt i en anden:

tool-relative-locators.png

Måden som tool’et identificerer elementer kan være forskelligt, og nogle gange kræver det et know-how at vide hvilke elementer man helst skal interagere med for at det virker – også i andre browsere. Andre udfordringer kunne være håndtering af dynamisk UI (asynkron indlæsning), sikkerhed og måden at interagere med systemet. De mere avancerede værktøjer tager bedre hånd om disse problemer, men sjældent kan håndtere udfordring med dårlige test data eller testbarhed på en applikation, som er ikke bygget til at blive automatiseret.

Stik imod den oprindelige forventning kunne det ende med en erkendelse af, at værktøjet ikke kan automatisere de cases man gerne vil – efter at have brugt en del tid på det. En anden opdagelse man kunne gøre er at værktøjet stiller krav til den måde som applikationen er skrevet: både UI og kodestruktur. Det er noget man ville have haft fordel i at vide, før man kodede applikationen.

Det bliver sværere at vedligeholde det

Den nye og spændende værktøj lovede os det var nemt at komme i gang, og det kunne ske vi var heldige nok at komme igennem forløbet uden at støde ind i forhindringer. Testforløbet, der blev optaget eller kodet virker og resultatet er 0 fejl gang efter gang man kører det. Hurraaaa! Vi klapper os selv på skulderen, fordi det var jo også en succes.

Men så begynder der at ske sporadiske fejl.. Ting vi ikke havde forudset. Vores test data forsvinder. Serveren svarede ikke. Skærmbilledet vi tester nåede ikke at blive indlæst. Der er introduceret et popup-vindue i den seneste version, som vi ikke havde regnet med at se da testen blev skrevet. Vedligeholdelsen af test-scriptet er ikke en triviel opgave, og ej heller en sjælden affære.

Man når hurtigt til den erkendelse at det er nødvendigt at evaluere ændringer til testen samtidigt med ændringer til krav. Helst samtidigt, for ellers ender det som et efterslæb af teknisk gæld man får bygget løbende op. Netop mængden af gæld er det som kan ende med at dræbe den gode intention om at automatisere så meget som muligt.

En anden erkendelse her kunne være at god test design er mindst lige så vigtig som god test implementering – du kan sjældent få et godt resultat uden at have styr på begge dele. Et godt test design kræver at man kender sine forudsætninger: krav, brugerforløb og hændelser i systemet som kan forstyrre eller afbryde solskinsscenariet.

Fejlene slipper alligevel igennem

Endelig, så kunne man have sluppet igennem nåleøjet og nået dertil hvor test designet er solidt, implementering er stabilt. Testen kører, og rettes til løbende, så det svarer til de seneste rettelser i systemet. Men testen finder ikke de fejl som slipper igennem og opstår i ellers så grønne testforløb af en velsmurt Continious-Integration maskine. Hvorfor det?

Man kunne have taget de “nemme” test cases, som var hurtigt at komme i gang med men ikke rammer de vigtigste krav og scenarier, hvor fejlene ender med at opstå i. Det kunne også være fordi test forløbet er overfladisk, og ikke tester alle krav og kriterier i bund. Det er en falsk negativ test, der rapporterer alt ser godt ud – og man sidder derfor med tilsvarende falsk tryghed.

Det er jo ikke målet i sig selv at testen skal være grøn, men snarere at testen skal løbende give noget værdi!

Således kan vores iver efter at komme i gang med et test automatiseringsværktøj blive mødt af virkeligheden, hvor det er nemt at bruge en del af sin tid uden at få den ønskede afkast. Hvad gør man så for at gøre det rigtigt?

Et bedre sted at starte

Jeg tænker minimum de to punkter, som helst løses i bredt samarbejde på teamet:

1. At identificere og afgrænse problemet man prøver at løse. Nogle blogposts her og her kommer omkring noget så basalt som at sætte et mål, og kriterier for done (inklusivt cost/benefit analyse som grundlag for hvad kan betale sig at automatisere). Citat fra den ene blog som sætter det så fint på spidsen:

Jean-Pierre Lambert: The goal is not to simply automate tests. It is about writing tests specifically designed for automation. It is also about writing tests at the proper technical level to give enough confidence at the smallest possible cost: cost of writing, cot of running and cost of maintaining.

Punkt 1. er måske noget af det sværeste at lære, fordi erfaringen med vedligeholdelse af de forskellige typer af test kommer ikke på en gang.

2. At lave en analyse af forudsætningerne for at design og eksekvering af automatiseret test kan lykkedes med at give værdi:

  • Det funktionelle grundlag, i form af veldefinerede, velbeskrevne og identificerbare krav og deres risikovurdering. Alle relevante detaljer medmen også prioritering da ikke alt er lige vigtigt at automatisere.
  • Testdata, inklusiv test brugere og alle relevante test data. Det handler ikke blot om at have data, som at kunne have kontrol over de relevante test data som kan ændre sig over tiden og invalidere test resultatet som følge deraf.
  • Dedikeret testmiljø og konfiguration, som kan svare mere eller mindre til den ønskede opsætning. Delt testmiljø giver delte problemer.
  • Sammenhængen med de øvrige test, som foretages: alt fra manuelle, tekniske integrations- og API tests som kunne i princippet teste det samme flere gange.
  • Tekniske risici og krav til applikationen i forhold til testbarheden – applikationens evne til at understøtte forskellige former for test, inklusivt den automatiserede.

Mere om disse i de kommende blogs fra mig.

Samarbejdet på teamet omkring disse punkter er nøglen til at nå i mål med succes, da hverken problemet eller forudsætningerne kan være 100% klare for en-persons testautomatiserings-team. Hyppige ændringer i krav, design, UI og teknologi kan være nødvendige for at lave det rigtige produkt, men disse er nødt til at være reflekteret i koden som automatiserer testen, hvis det skal give værdi. På den måde sikrer man sig at kunne lave produktet rigtigt.

Reklamer

Skriv et svar

Udfyld dine oplysninger nedenfor eller klik på et ikon for at logge ind:

WordPress.com Logo

Du kommenterer med din WordPress.com konto. Log Out /  Skift )

Google+ photo

Du kommenterer med din Google+ konto. Log Out /  Skift )

Twitter picture

Du kommenterer med din Twitter konto. Log Out /  Skift )

Facebook photo

Du kommenterer med din Facebook konto. Log Out /  Skift )

w

Connecting to %s