Når vi vil introducere en ny funktion eller forbedre en eksisterende, er det nemt at falde i "det virker på min maskine"-fælden: Du skrev noget kode, åbnede den tilsvarende side og så, at det virkede. Man kunne tro, at det var alt, hvad vi havde brug for, men at have en funktion, der virker, er kun en lille del af det at færdiggøre funktionen.
Vi ønsker at bevare roen, når vi frigiver en ny funktion, og sikre en vis grad af sikkerhed for, at vi ikke ødelægger noget ved et uheld. Der er to hovedprocesser, som forhindrer dette i at ske: manuel testning og automatiseret testning. Vi forklarer grundigt vores manuelle QA-proces i et separat blogindlæg, så vi vil kun komme ind på de automatiske dele her, for nogle gange har man bare brug for robotter i stedet for mennesker...!
Hvad mener vi med automatiseret testning?
Automatiske tests er også kode
Hvis vi ændrer noget på en side, bør det ikke pludselig ødelægge en anden side. Hvis vi skulle teste alle eksisterende funktioner, hver gang vi introducerer noget nyt for at sikre, at det stadig virker, ville vi aldrig kunne udgive noget! For stadig at sikre en vis grad af sikkerhed har vi automatiserede tests. Konceptet med automatiserede tests er ikke noget nyt, og vi håber, at alle andre softwarevirksomheder også bruger dem! Men vi tænkte, at det ville være værdifuldt at forklare, hvorfor og hvordan vi bruger dem.
De automatiserede tests kører, hver gang vi ændrer noget i koden. For at gå endnu længere end det, så er testene i sig selv også kode! Selv om en funktion virker, når vi tester den manuelt, er den ikke komplet, medmindre der også er en test for den i koden. Det faktum, at det virker i dette øjeblik, i din specifikke testcase, på din maskine, betyder ikke, at det vil fortsætte med at virke på ubestemt tid.
Vi mener, at test er lige så nødvendige som selve koden, hvis ikke lidt mere. De giver os en klar definition af, hvad vores kode skal gøre, og sørger automatisk for, at den gør det! Vi kan frit foretage ændringer i koden uden at bekymre os om, at tingene går i stykker. Hvis testene består, bør alt fungere som forventet!
Hvorfor bruger vi automatiseret test?
Vores automatiserede tests giver os mulighed for at gå hurtigere frem uden at ødelægge noget. Vores manuelle QA er meget hurtigere, fordi vi f.eks. ikke behøver at prøve at lave eksamener med mange forskellige navne. Vi ved fra vores automatiserede tests, at det bare virker, så vi behøver ikke selv at prøve igen!
Automatiserede tests giver os mulighed for at bevæge os hurtigere uden at ødelægge ting
På grund af dette kan vi også være meget mere grundige, end det ville være rimeligt at gøre manuelt. Vi kan teste alle de mulige handlinger, som koden kan udføre, selv dem, der forudsætter, at en del af webstedet er nede. Det bør naturligvis aldrig ske, og det ville være besværligt at teste det manuelt. Men vi kan bare lade, som om webstedet er nede, og se, at alt fortsætter som forventet med vores automatiserede tests!
En sidebemærkning: Målinger er ligegyldige
Automatiserede tests udløser altid en debat om, hvor meget testdækning der er brug for. Dækning er et mål for, hvor meget af din kode der rent faktisk testes af dine tests, angivet i procent. Dækningen af dine tests er noget, du automatisk kan spore, hvilket gør det meget nemt at beslutte, at den skal være så høj som muligt. Hvis vi har 100 % testdækning, burde intet gå i stykker ved et uheld, ikke sandt?
Nå, men...
Lad os sige, at vi har en funktion, som vi sender et tal til. Den foretager en meget kompleks beregning og giver os derefter resultatet tilbage. Det, vi kunne gøre som en test, er at kalde funktionen og derefter tjekke, om resultatet er et tal. Det er naturligvis ikke en fornuftig test for denne kode: Vi har ingen idé om, hvorvidt funktionen udfører den korrekte beregning! Men med denne test kan vi opnå 100 % testdækning: Hele kodestykket er dækket, bare ikke på en måde, der betyder noget.
Metrikker er en god hjælp til at se, om vi gør noget virkelig mærkeligt, og derfor bruger vi dem. Metrikker er dog ikke et middel til at sikre, at vi skriver kode af god kvalitet!
Er alting vigtigt?
Vi skriver altid test til alt, men vi skelner mellem scenarier
Vi mener, at alle dele af Easy LMS er vigtige, da det ikke ville være det samme uden dem! Men desværre er vi stadig bundet af en begrænset mængde tid. Det er ikke rimeligt at teste alt. Vi er altid nødt til at foretage en afvejning af, hvor dybt vi vil automatisere noget. Vi skriver altid test for alt, men vi skelner mellem scenarier. I nogle tilfælde er det nok med simple tests, som vi nævnte før, men hvis noget er missionskritisk, går vi endnu længere!
Men hvad nu, hvis noget er missionskritisk?
Visse dele af systemet er missionskritiske. Hvis ingen længere kan logge ind, er der for eksempel ikke meget, man kan gøre med Easy LMS. Selv om vores tests tester login-koden, vil vi stadig gerne prøve at logge ind hver gang, før vi frigiver en ny funktion. At udføre denne validering manuelt ville betyde, at vi skulle bruge et par minutter, hver gang vi ville frigive noget. Vi kan selvfølgelig godt gøre det, men jo flere ting, vi finder nødvendige, jo flere minutter skal vi bruge. Og det løber op. Heldigvis kan vi gå et skridt videre. De tests, vi tidligere har nævnt, tester koden, men vi har også accepttests. Disse interagerer med hjemmesiden på samme måde som i din browser, så vi kan automatisere nogle af de QA-skridt, vi ellers skulle have taget! Det betyder, at vi kan bruge dem til at teste en hel funktion fra ende til anden. For at vende tilbage til vores tidligere eksempel behøver vi ikke længere at logge ind hver gang for at sikre, at det virker. Hvis det ikke gør det, vil accepttesten mislykkes! Alle disse metoder hjælper os med at fange mange fejl, før de når frem til dig, men vi er trods alt alle mennesker
