<img height="1" width="1" src="https://www.facebook.com/tr?id=1272750026111903&amp;ev=PageView &amp;noscript=1">

Hvorfor testautomatisering ikke bare er tut og kjør!

Shomaila Kausar

Shomaila Kausar | 14. november 2017

Vi ønsker å automatisere testingen vår. Dette har jeg hørt altfor mange ganger. Problemet er bare at etter dette utsagnet blir det som regel stille.. veldig stille. Oftest hører jeg utsagnet igjen etter noen måneders tid, noen få ganger føles det som om det er blitt sagt bare for å være med på noe som er hipt.

Hvorfor automatisere testingen?

Hvordan går man egentlig videre? Eller rettere sagt, hva gjør man når man får en forespørsel om å automatisere? Spørsmålet som bør stilles bør være: Hvorfor vil dere automatisere? Dette vil kanskje virke demotiverende og kanskje helt feil for mange av dere. Men tenk litt på det, du som utvikler, designer, tester eller leder et prosjekt. Skal du begynne å automatisere fordi noen sier at dere skal eller, skal det foreligge en annen årsak bak det hele.

Svarene på spørsmålet om hvorfor man skal automatisere kan være mange, for eksempel:

- Vi sliter med mange feil og ønsker å få ned feilraten
Testautomatisering vil ikke gi dere mindre feil, den vil bare verifisere at koden som er implementert tidligere fortsatt virker ok uten at det skapes nye følgefeil.

- Vi ønsker å kunne teste bredere
Testautomatisering vil ikke gi dere bredere testing, den tester kun det den blir bedt om å teste. Men vil frigjøre ressurser, slik at de kan kjøre mer manuell eksplorativt test.

Les også: Automatiserte tester er viktig - gode krav er en nødvendighet

- Vi ønsker å bruke mindre tid på manuelle tester
Nå begynner man å komme inn på noe. Det stemmer, automatiske tester kjører som regel mye fortere enn hva menneskelig testressurser kan få til. Men husk mennesker kan finne feil ved å gjøre feil. Automatiske tester gjør ikke feil. De følger en «bruksanvisning» til punkt og prikke.

- Vi ønsker å teste alle mulige utfall
Det er aldri mulig å få testet alle mulige utfall. Men man får dekket flere utfall ved å lage gode automatiske tester som tar inn forskjellige input variabler og jobber med forskjellige typer tilstander.

Hvordan automatisere testingen?

La oss anta at du har et system som har vært i drift i noen år. Dette systemet får noen nye leveranser i ny og ne, og dette krever at dere setter av en periode på noen dager eller uker til å manuelt teste nye versjoner. Skal man i slike tilfeller starte med å si at leveransen ikke kan tas imot på grunn av manglende automatiske tester på kodenivå? Nei, man kan ikke og bør ikke gjøre det.

“Rom ble ikke bygget på en dag!”

Jeg anbefaler at hele teamet setter testautomatisering på dagsorden, setter opp realistiske mål og starter i det små. Man kan for eksempel i starten si at man skal prøve å lage enhetstester til all ny funksjonalitet og etterhvert gå over til å sette dette som et krav. Jeg anbefaler at man kjører samme taktikk på automatisering av GUI test. Ved å automatisere enkle funksjoner, vil dere bli kjent med automatiseringsverktøyet samtidig som dere blir kjent med deres et system på en helt ny måte.

Når dere er kommet i gang er det viktig å tenke på vedlikeholdbarhet og kost/nytte.

Ler også: 4 tips til hvordan du kan effektivisere testingen

Se opp!

Veldig mange av oss går rundt med en formening om at automatisering av tester skal erstatte menneskelige testere. Dette er feil. Automatiske tester, enten på enhetsnivå, integrasjonsnivå eller brukergrensesnittnivå tester kun en del eller en bestemt vei gjennom koden.

La meg beskrive dette på en litt annen måte. Se på systemet under test som en labyrint. De automatiske testene kan illustreres som veier ut av denne labyrinten eller områder i labyrinten som er godt dekket. Det vi må huske på er å sjekke de områdene/veiene i labyrinten som testene ikke verifiserer, og forsøke å finne de feilene som i figuren under er illustrert som røde lyn før man går i produksjon.

Enhetstester og GUI tester

Hva må automatiseres?

Ved gjennomføring av ytelsestester bør automatiske tester være et must. Maskinene har forlengst gått forbi oss i masseproduksjon og det er ikke lenger kostnadseffektivt å tenke andre muligheter i den forbindelse. I tillegg til dette bør man også vurdere å automatisere alt test knyttet til smoketester i forbindelse med produksjonssetting, dette gjelder både de som kjører i continuous delivery miljøer som alle andre miljøer. Alle tester som er formet som en liste med steg, hvor stegene må følges i en bestemt rekkefølge uten muligheten til å gå andre ”veier”, bør automatiseres så langt det lar seg gjøre.

Tips: Bedre, raskere og billigere testing

Konklusjon

Helt til slutt vil jeg benytte anledningen til å filosofere litt over ordet “testautomatisering”. Mulig det burde byttes ut med “automatisert verifisering”. En tester sin hovedoppgave er å finne feil. En enhetstest skal kun verifisere at funksjonaliteten virker som den skal under en gitt begrenset tilstand. En automatisert test av GUI er bare en vei gjennom labyrinten.

Den dagen AI kommer og maskinen tenker litt utenfor “boksen”, vel den dagen skal jeg vurdere om jeg vil kalle det testautomatisering…

 

Jobber du med testing?  Se våre ledige stillinger

Del på sosiale medier: