Hvis jeg fortæller dig at testautomatiserings største udfordring er vedligeholdelse af de automatiserede tests, så vil du måske undre dig.
Du mærken smerten før eller siden
Lidt provokerende vil jeg sige, at du nok ikke har mærket smerten endnu. Du har sikkert ikke prøvet at have en stor automatiseret test suite og en forretningsapplikation, som ved enhver given lejlighed flytter sig, så din test suite ikke giver dig troværdige resultater mere. Du har sikkert heller ikke brugt oceaner af tid på at fejlsøge på dine tests, for dernæst at finde ud af, at det var fordi udviklerne havde ændret et enkelt felt på en webside.
Du ønsker jo bare at dine test er så automatiske, at du kan få svar på, om forretningsapplikation fungerer som den skal – automatiske test er vel så automatiske at jeg bare skal trykke på en knap, og så give mig et resultat – ikke? Det er vel hele ideen med automatisk test !
I øvrigt så er test automatisering jo heller ikke svært. Man skal jo bare købe et tool, så kan testere bruge det tool til at skrive testene i, så bliver de jo automatiske allerede fra testernes hånd. Det er bare rigtig smart.
Men…..
Det er svært at finde den rigtige vej
Begiver du dig ud I automatisering af test med den opfattelse, så må jeg skuffe dig med, at du nok ikke opnår succes på den lange bane, men derimod, kommer til at få nogle grimme sår på sjælen og nogle lommesmerter som er til at tage at føle på. Du ender nok med at kaste det hele over højre skulder til sidst.
Vejen til succes med automatisk test kræver at du læner dig op at nogen, som har mærket hvor ondt det gør, at gå ned af de forkerte stier, nogen som kan se at der står stop eller omkørsel længere fremme og nogen som med succes har fået automatisering til at virke på den lange bane.
Hvorfor bliver vedligeholdelsen så din største smerte?
De laver hele tiden ændringer
Det er her at du skal have lidt mere indsigt, end hvad du kan læse som overskrifter.
Webudvikling kan ofte karakteriseres ved at udviklingen går stærkt, der kommer ofte nye releases, nye sider kommer til, gamle forsvinder og eksisterende ændres. Alt sammen til stor gene for testen. For alle ændringerne skal jo testes og alt det som stadig skulle virke skal jo også testes. Så hvordan skal vi dog nå at gennemføre regressionstesten, når test mængden stødt forøges? Det er her at du ønsker at automatisk test kommer ind i billedet.
Den traditionelle fremgangsmåde – ender blindt !
Her skal du ændre hvert test script
Her har du de websider som du lige nu har. Du har tre sider og du nogle automatiske test scripts, som benytter disse websider.
Disse tre test du har udviklet i dit nye tool, kører glimrende og automatisk lige nu.
Ved næste release ændres den midterste web side. Det resulterer nu i, at du nok skal rette I alle tre test scripts. Du finder i øvrigt kun ud af at de ikke virker, ved faktisk at afvikle dem.
Løsning på første problem
Nu skal du kun ændre ét sted
I stedet for at rette i de tre test script, så er der opfundet et design pattern, som kaldes Page Object Model. Dette design pattern adressere netop ovenstående problem ved, at du indfører ét Page Object per webside. Et Page Object skal altså ses som en facade på en webside. I sådan et Page Object inkluderes de felter, knapper og høj niveau forretningsfunktioner, som har med kun den ene webside at gøre. Disse Page Objects benyttes nu af dine Test Scripts i stedet.
Det bevirker nu, at når den nye release kommer med ændringer til den midterste webside, så er det kun det korresponderende Page Object som skal tilrettes.
Dette design pattern bør være den måde dine automatiske test er bygget på. Det er her hvor du begynder at få succes med test automatisering
Er der flere problemer?
Vedligeholdelse bliver dit største problem
Ja – det faktum at din forretningsapplikation ændres løbende og I disse tider, sikkert oftere og oftere. Så skal du holde dine Page Objects i synk med websiderne – jo oftere og jo flere ændringer der er på websiderne, jo flere Page Objects skal du vedligeholde og opbygge for de nye websider.
Ergo bliver vedligeholdelse, hvad enten du vil eller ej, dit største mareridt.
Der findes løsninger på dette problem – det kan du læse om i næste afsnit som kommer snart.
4 vigtige punkter
- Læn dig op at nogen med rigelig erfaring og ar på sjælen.
- Hold dig væk fra de gængse tools på markedet, hvis dit mål er mange test cases og du releaser ofte.
- Implementer design pattern Page Object Model.
- Afvikle dine automatiske test så ofte som muligt.
