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

Automatisering av det ukjente

Shomaila Kausar

Shomaila Kausar | 09. september 2019

Du skal lage automatiske tester i et prosjekt hvor kravspesifikasjonen er utført etter vannfallsmodellen, mens utviklingen blir utført smidig. Hvordan løser du det? I denne artikkelen gir jeg deg 4 råd og tips som jeg selv har hatt stor bruk for de siste årene.

Utfordrende for alle parter

Men la oss først se litt på bakgrunnen for at slike situasjoner oppstår. Du har kanskje erfart å jobbe med prosjekter hvor kravene blir skrevet etter vannfallsmodellen for så å bli en del av en kontrakt som leverandøren forsøker å oppfylle med en smidig utviklingsmetodikk. Til tross for at du da jobber smidig hender det i en del prosjekter at noen brukerhistorier blir liggende lenge i backlogen før de blir tatt inn i en sprint. I slike tilfeller risikerer du at kravene er utdatert eller blir misforstått når de kommer til utviklingsteamet og fagsiden ikke er tilgjengelig i samme grad. Når kravene da prøves å utvikles i løpet av en sprint eller to, opplever vi ofte at vi må gå flere runder før løsningen blir som den var tiltenkt. Prosjekter som dette vil oppleves som utfordrende for alle parter, særlig for testutviklerne. For applikasjoner som produseres i slike prosjekter er det meget vanskelig å få skrevet gode testcaser, enda vanskeligere er det å lage automatiske tester.

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

Jeg har vært med i prosjekter hvor vi har vært flinke med å gå gjennom krav på nytt og spesifisere de bedre i forkant av en sprint - men i en hektisk hverdag kommer ikke alltid alle detaljer frem. Når du så under sprinten skal automatisere test av slik funksjonalitet ender det ofte med at testen må skrives om, videreutvikles eller faktisk slettes etter et par runder. Under får du mine beste tips for hvordan du kan unngå dette.

1. Forstå hva vi har - og hva vi vil få til slutt

Før du legger en strategi for hvordan du skal automatisere testing av en applikasjon under utvikling er det viktig å ha en god forståelse av hva som er blitt produsert - og hva som faktisk skal produseres. Svarene på dette får du ikke nødvendigvis fra et dokument eller en samling jira saker. Her må du drive med “detektivarbeid”. Snakk med de som er tiltenkt å være brukerne. Ikke spør dem om hva de vil ha, men spør heller hvordan de vil bruke applikasjonen.

2. Ha færrest mulig ukjente faktorer

Er prosjektet av en slik natur at du ikke alltid vet hva du ender opp med, kan du prøve å luke ut andre usikkerhetsmomenter. Jeg vil derfor anbefale at du ikke velger å gå for et helt nytt og ukjent testverktøy eller rammeverk, men bruke noe du kjenner godt til og har god erfaring med.

Jeg har tidligere skrevet om valg av korrekt verktøy i denne artikkelen.

3. Splitt og hersk

Denne teknikken går ut på å dele opp automatiske tester i mindre biter. Når du deler opp en automatisk test i biter må dette gjøres på en fornuftig måte. Først deler du testen opp i biter som skal teste forskjellige deler av funksjonaliteten. For eksempel; har du en søknadsmodul, kan du dele testene opp i mindre tester som går ut på å teste:

  1. Åpne søknad
  2. Fylle ut søknad
  3. Lagre søknad
  4. Innsending av søknad

Deretter deler du opp en test i mindre tester basert på sannsynligheten for at funksjonaliteten vil bli endret eller videreutviklet. For eksempel vet du at registrering av adresse som i dag gjøres manuelt, vil bli erstattet med preutfylling av adresse gjennom en integrasjon mot folkeregisteret. Når du kjenner til slike planlagte endringer, kan du isolere testen av denne funksjonaliteten. Ved innføring av endringen trenger du kun å endre den den isolerte testen, mens øvrige tester fremdeles vil fungere og vil ikke bli berørt av endringen.

4. Automatiser og stopp

Har du deler av en funksjonalitet som er ukjent, dvs at du ikke vet hvordan denne vil bli til slutt, eller en funksjonalitet som er lite fullstendig; STOPP! Ikke automatiser for å automatisere. Lag testene dine slik at du for eksempel legger inn manuelle steg som ved senere sprinter kan erstattes med egne automatiske tester.

Tips til mer lesning: Hvorfor testautomatisering ikke bare er tut og kjør!

 

Jeg håper disse tipsene kan hjelpe deg på veien til testautomatisering, men husk: du kan ikke automatisere alt fra dag én, men det betyr ikke at du skal vente med å begynne å automatisere før helt til slutt. Det blir også feil!

 

Ønsker du å vite mer om hvordan vi jobber med test i Systek, eller har spørsmål og kommentarer til innlegget,
ta gjerne kontakt.

Del på sosiale medier: