Vi har hatt QA, ja. Hva med automatisk kvalitetssikring?

Når vi ønsker å introdusere en ny funksjon eller forbedre en eksisterende, er det lett å gå i "det fungerer på min maskin"-fellen: Du skrev litt kode, åpnet den tilhørende siden og så at det fungerte. Man kan tro at det er alt vi trenger, men det å ha en funksjon som fungerer er bare en liten del av det å faktisk fullføre funksjonen.

Vi ønsker å beholde roen når vi lanserer en ny funksjon, og sikre at vi ikke ødelegger noe ved et uhell. Det finnes to hovedprosesser som forhindrer at dette skjer: manuell testing og automatisert testing. Vi forklarer den manuelle QA-prosessen vår grundig i et eget blogginnlegg, så vi vil bare gå inn på de automatiske delene her, for noen ganger trenger man bare roboter i stedet for mennesker!

Hva mener vi med automatisert testing?

Automatiske tester er også kode

Hvis vi endrer noe på én side, skal det ikke plutselig ødelegge en annen side. Hvis vi skulle teste alle eksisterende funksjoner hver gang vi introduserer noe nytt for å sikre at det fortsatt fungerer, ville vi aldri kunne lansere noe som helst! For å sikre en viss grad av sikkerhet har vi automatiserte tester. Konseptet med automatiserte tester er ikke noe nytt, og vi håper at alle andre programvareselskaper også bruker dem! Vi tenkte imidlertid at det ville være verdifullt å forklare hvorfor og hvordan vi bruker dem.

De automatiserte testene kjøres hver gang vi endrer noe i koden. For å gå enda lenger, så er testene i seg selv også kode! Selv om en funksjon fungerer når vi tester den manuelt, er den ikke komplett med mindre det også finnes en test for den i koden. Det faktum at den fungerer akkurat nå, i ditt spesifikke testtilfelle, på din maskin, betyr ikke at den vil fortsette å fungere på ubestemt tid.

Vi mener at tester er like nødvendige som selve koden, om ikke litt mer. De gir oss en klar definisjon av hva koden vår skal gjøre, og sørger automatisk for at den gjør det! Vi kan fritt gjøre endringer i koden uten å bekymre oss for at ting skal gå i stykker. Hvis testene består, skal alt fungere som forventet!

Hvorfor bruker vi automatisert testing?

De automatiserte testene våre gjør at vi kan gå raskere frem uten å ødelegge ting. Vår manuelle kvalitetssikring går mye raskere fordi vi for eksempel ikke trenger å prøve å lage eksamener med mange forskjellige navn. Vi vet fra de automatiserte testene våre at dette bare fungerer, så vi trenger ikke å prøve det på nytt selv!

Automatiserte tester gjør at vi kan jobbe raskere uten å ødelegge ting

På grunn av dette kan vi også være mye grundigere enn det som ville vært rimelig å gjøre manuelt. Vi kan teste alle mulige handlinger koden kan utføre, til og med de som forutsetter at en del av nettstedet er nede. Dette skal naturligvis aldri skje, og det ville vært tungvint å teste det manuelt. Men vi kan bare late som om nettstedet er nede og se at alt fortsetter som forventet med de automatiserte testene våre!

En parentes: Målinger spiller ingen rolle

Automatiserte tester skaper alltid debatt om hvor mye testdekning som er nødvendig. Dekningsgrad er et mål på hvor mye av koden som faktisk testes av testene, angitt i prosent. Testdekningen er noe du automatisk kan følge med på, noe som gjør det veldig enkelt å bestemme seg for at den bør være så høy som mulig. Hvis vi har 100 % testdekning, bør ingenting gå i stykker ved et uhell, ikke sant?

Vel...

La oss si at vi har en funksjon som vi sender et tall til. Den gjør en svært kompleks beregning og gir oss deretter resultatet tilbake. Det vi kan gjøre som en test, er å kalle funksjonen og deretter sjekke om resultatet er et tall. Dette er naturligvis ikke en fornuftig test for denne koden: Vi har ingen anelse om funksjonen utfører den riktige beregningen! Men med denne testen oppnår vi 100 % testdekning: Hele kodestykket er dekket, bare ikke på en måte som betyr noe.

Metrics er en fin krykke for å se om vi ikke gjør noe veldig rart, og derfor bruker vi dem. Men beregninger er ikke et mål for å sikre at vi skriver kode av god kvalitet!

Er alt viktig?

Vi skriver alltid tester for alt, men vi skiller mellom ulike scenarier

Vi mener at alle deler av Easy LMS er essensielle, og at det ikke ville vært det samme uten dem! Men dessverre er vi fortsatt bundet av en begrenset mengde tid. Det er ikke rimelig å teste alt. Vi må alltid gjøre en avveining av hvor dyptgående vi ønsker å automatisere noe. Vi skriver alltid tester for alt, men vi skiller mellom ulike scenarier. I noen tilfeller er det nok med enkle tester som vi nevnte tidligere, men hvis noe er virksomhetskritisk, går vi enda lenger!

Men hva hvis noe er virksomhetskritisk?

Enkelte deler av systemet er virksomhetskritiske. Hvis for eksempel ingen lenger kan logge inn, er det ikke mye du kan gjøre med Easy LMS. Selv om testene våre tester påloggingskoden, ønsker vi likevel å prøve innlogging hver gang før vi lanserer en ny funksjon. Å utføre denne valideringen for hånd ville bety at vi måtte bruke et par minutter hver gang vi ønsker å lansere noe. Vi kan selvfølgelig gjøre dette, men jo flere ting vi anser som nødvendige, jo flere minutter må vi bruke. Og det blir mye. Heldigvis kan vi gå ett skritt videre. Testene vi har nevnt tidligere, tester koden, men vi har også akseptansetester. Disse interagerer med nettstedet på samme måte som du ville gjort i nettleseren din, slik at vi kan automatisere bort noen av de QA-skrittene vi ellers måtte ha tatt! Dette betyr at vi kan bruke dem til å teste en hel funksjon fra ende til ende. For å gå tilbake til det forrige eksempelet, trenger vi ikke lenger å logge inn hver gang for å forsikre oss om at det fungerer. Hvis den ikke gjør det, vil akseptansetesten mislykkes! Alle disse metodene hjelper oss med å fange opp mange feil før de når deg, men vi er tross alt mennesker