Vi vil så gjerne kvalitetssikre programkoden vår best mulig og da må vi testautomatisere!
Eller må vi alltid det?
Jeg vil dele noen tanker og spørsmål det bør tas stilling til før dere setter i gang prosessen med utvikling av testautomatisering.
Før igangsettelse av testautomatisering bør vi utføre en behovsvurdering og definere et forretningsmål med testautomatiseringen; – hva er det man egentlig ønsker å oppnå med automatiseringen? Ved å automatisere uten å vite hva man vil oppnå fører fort til et mislykket automatiseringsprosjekt, da det er vanskelig å vite om målet blir nådd ved veis ende. Husk også at automatisering kun er et verktøy for å oppnå et mål.
Noe som også er viktig å ha klart for seg er at testautomatisering ikke må ses på som et venstrehåndsarbeid i et prosjekt men må betraktes som et eget utviklingsprosjekt. Det er liten forskjell på å skrive testkode og å skrive produksjonskode.
Vi kan benytte testautomatisering for forskjellige forretningsmål som blant annet kostnadsreduksjon, raskere produksjonssetting, bedre stabilitet/ robusthet /ytelse eller arbeidsbesparelse.
For de fleste blir nok testautomatisering valgt for ønske om generering av raskere test og for oppnåelse av en solid løsning. For oppnåelse av dette bør vi først og fremst fokusere på testautomatisering av enhetstester og integrasjonstester da testautomatisering av disse gir rask tilbakemelding om systemet er klart for funksjonell utforskende testing!
Testautomatisering utfordrer utviklerne til å gjøre utvikling og endringer raskt i koden og vil også bruke automatisering som et sikkerhetsnett for egen koding. Ofte vil automatisering dytte utviklerne raskere fremover slik at man får en synergieffekt med økt utvklingshastighet, noe vi ikke sier nei til.
Noen velger å bruke testautomatisering for å få ned feilraten i programkoden, men testautomatisering resulterer langt fra alltid mindre feil men fungerer mer som et sikkerhetsnett mot utilsiktede endringer slik at ny kode ikke innfører følgefeil. Med testautomatisering kan man redusere manuell regresjonstest og heller teste bredere, kvalitativt, og få mer tid til utforskende testing som også har vist seg å gi bedre kvalitet på løsningen.
Vi kan testautomatisere løsningen for å oppnå forretningsmålet men vi må ikke glemme å stille en kost/nyttevurdering av automatiseringen. Er det verdt å legge inn noen millioner i automatisering for å oppnå 100.000 i gevinst?
Når vi vet forretningsmålet og vi mener at automatisering er riktig verktøy, må vi finne ut:
• Når koster det mer enn det smaker?
• Hvordan få kostnaden lavest mulig og nytten høyest mulig?
• Hvilke tiltak må til for å oppnå bedre kost/nytteverdi?
Vi må rett og slett undersøke og analysere hva vi får igjen av automatiserte tester opp mot manuelle tester, samt hva kostnadsforskjellen blir.
For å finne ut av dette må man ta hensyn til Automatiseringskost:
• Opportunity cost – tiden man bruker på å automatisere tester som kunne vært brukt på manuell testing
• Vedlikeholdskost
• Implementasjonskost
• Verktøystøttekost
Kost/nytte vurdering er heller ikke alt som skal til for å lykkes. Før man setter i gang med testautomatisering bør man sette en begrensning på hvor mye som bør automatiseres og når man skal stoppe automatiseringen. Dette må være en løpende vurdering siden automatiseringsprosjekt ofte får en brått stigende kostnadskurve. Spesielt vedlikeholdskostnaden på gamle tester blir fort høy. For å kunne sette slike begrensninger må man komme med kriterier og definere når nok er nok.
Testautomatiseringsprosjekter kan noen ganger, over lang nok tid, bli veldig store og større enn selve utviklingsprosjektet selv, noe som blir helt feil da det skal være til hjelp og ikke til en belastning for prosjektet!
For å sitte igjen med det som skal automatiseres bør man stille følgende spørsmål:
• Hva ønsker man å oppnå med automatiseringen?
• Hvordan får man det til å lønne seg?
• Hva er det vi ikke skal/kan automatisere?
• Hvilke deler av løsningen har godt gevinstpotensiale?
• Hvilke deler har dårlig gevinstpotensiale?
For å forstå hvor testautomatisering bør opprettes tar vi utgangspunkt i testkvadrantene for å se hvor det egner seg best.
Kvadrant Q1: inneholder funksjoner som egner seg best til testautomatisering som – Enhetstest/ komponenttest – Integrasjonstest.
Når vi beveger oss over til kvadrant Q4: har vi tester som trenger mer verktøystøtte for testautomatisering som – Stabilitetstest – Lasttest – Ytelsestest.
Kvadrant Q2: viser tester som kan automatiseres men også kjøres manuelt som – Funksjonelle tester – Prototyper – Simuleringer.
Jo mer man beveger seg fra kvadrant Q2 til kvadrant Q3: går man over til manuell funksjonell testing som utforskende testing – UAT (User Acceptance Testing) – Scenario- og Akseptansetesting – Alpha/Beta test.
Noe som er verdt å merke seg er at denne tegningen av testkvadrantene viser grønt område i kvadrant Q1 som tilsier at testautomatisering er ´billig´ å lage, mens jo mer vi nærmer oss kvadrant Q4 blir fargen lysere noe som indikerer at testautomatisering blir ´dyrere´ å produsere.
På samme måte viser mørk blåfarge i kvadrant Q2 at det er ´billigere´ å produsere testautomatisering enn i kvadrant Q3.
Ja, ja, sier du kanskje nå, men HVOR i løsning skal man automatisere? Hvor er det hensiktsmessig å automatisere?
Til å få svar på dette bør vi utføre en arkitekturvurdering, som vil vise oss hvor i løsningen/systemet man kan få gjort automatisering. Ved å tegne opp arkitekturen/lage et flytskjema av hele systemarkitekturen vil vi kunne se hvor i systemet det er hensiktsmessig å koble seg på med automatisering. Vi kan da også ta stilling til hvor/hva som kan isoleres ved å lage mocker eller stubber?
Og, når vi har tatt stilling til hvor og hva som skal automatiseres er det på tide å velge Metode for hvordan automatisering skal gjennomføres. Vi kan f.eks. sette opp en prioritert liste med oppgaver som skal gjøres som:
• Hvem skal gjøre hva?
• Hvor skal vi begynne å automatisere?
• Skal vi bruke eksterne rammeverk?
• Skal vi prøve å teste mest mulig isolert eller mest delvise isolert?
• Skal vi bruke mocker og stubber?
• Hva stoler vi på at andre har testet?
• Hva er det som virker stabilt, har lav endringstakt og ikke trenger automatisering?
Ja, det er mange spørsmål vi må ta stilling til og flere er det. For, når vi har valgt metoden for hvordan vi skal testautomatisere trenger vi å vite dekningskravet for testene vi skal lage. Hvilken dekning trenger vi:
• Kombinatorisk dekning dvs. interaksjon mellom variable?
• Banal testdekning?
• eller kun hva man trenger for å få testet løsningen brukbart?
Nå synes du vel vi har sett på mange oppstarts-kriterier for testautomatisering og lurer vel på når vi skal snakke om hvilke verktøy vi bør bruke for å lage testene. Men du skal vite at dette er en nyttig vei å gå for først når vi vet:
• Forretningsmålet
• Kost-/nytteverdien
• Når man skal automatisere og når man skal stoppe
• Hvilken saneringsplan man har for å slette gamle utdaterte tester
• Hvor i løsningen det er lurt å koble på automatisering …
Da, er det på tide å se på hvilke verktøyvalg man skal gjøre!
Hvis vi begynner med automatiseringsprosessen ved å velge verktøy kan vi fort ende opp med feil valg for automatisering av systemet, jeg anbefaler derfor å gå gjennom alle foregående vurderinger for ikke å gå i tabber mange har gjort før deg bl.a. ved å velge f.eks. Cucumber fordi det er populært eller velge Selenium og automatisere absolutt alt med det fordi vi kanskje allerede har programvaren.
En annen ting er at vi heller ikke må glemme å fokusere på hvilke testnivå vi skal skrive testen for. Har vi valgt å fokusere hovedsaklig på funksjonell test av enhetstester er verktøy veldig ofte gitt da vi ofte skriver automatiseringskode i samme språk og i *Unit rammeverk som passer til – Junit for Java – Nunit for .net – PyUnit for python. For test av API er det avhengig av hva slags API man har f.eks. – REST/SOAP – Postman – Jmeter.
Det er også lurt å ta stilling til om man trenger rammeverk som krever mye vedlikehold eller ikke.
Testautomatisering kan også være en god løsning for generering av testdata. Vi kan da få et mangfold av inputdata til testing av systemet og for inputdata til blant annet ytelsestest.
Det kan være flott å testautomatisere løsningen, men husk alltid på at løsningen som oftest lever videre med videreutvikling og planlagte endringer i grensesnitt (Public interfaces), noe som må tas med i hvordan testautomatiseringen skal vedlikeholdes med bl.a. sanering av gammel kode slik at vi ikke drar med oss utgåtte tester som kan feile og på den måten ikke vite om det er testen eller systemet som feiler.
Jeg har nå guidet deg litt gjennom det som skal til for å sette i gang med testautomatisering, og det som gjenstår nå er implementasjonen.
Programmering av testautomatisering kan starte opp
Denne artikkelen er skrevet av Sidsel Wang Skudal. Hun jobber som testleder i Promis Qualify.