När vi vill införa en ny funktion eller förbättra en befintlig är det lätt att falla för "det fungerar på min maskin"-fällan: Du skrev lite kod, öppnade motsvarande sida och såg att det fungerade. Man kan tro att det är allt vi behöver, men att ha en fungerande funktion är bara en liten del av att faktiskt slutföra den funktionen.
Vi vill vara lugna när vi släpper en ny funktion och vara säkra på att vi inte råkar förstöra något av misstag. Det finns två huvudprocesser som förhindrar att detta händer: manuell testning och automatiserad testning. Vi förklarar noggrant vår manuella QA-process i ett separat blogginlägg, så vi kommer bara att gå in på de automatiska delarna här eftersom du ibland bara behöver robotar istället för människor ?!
Vad menar vi med automatiserad testning?
Automatiska tester är också kod
Om vi ändrar något på en sida ska det inte plötsligt gå sönder på en annan sida. Om vi skulle testa alla befintliga funktioner varje gång vi introducerar något nytt för att se till att de fortfarande fungerar skulle vi aldrig kunna släppa något! För att ändå säkerställa en viss grad av säkerhet har vi automatiserade tester. Konceptet med automatiserade tester är inte något nytt, och vi hoppas att alla andra programvaruföretag också använder dem! Vi tyckte dock att det skulle vara värdefullt att förklara varför och hur vi använder dem.
De automatiserade testerna körs när vi ändrar något i koden. För att gå ännu längre än så är testerna själva också kod! Även om en funktion fungerar när vi testar den manuellt är den inte komplett om det inte också finns ett test för den i koden. Det faktum att det fungerar just nu, i ditt specifika testfall, på din maskin, betyder inte att det kommer att fortsätta att fungera på obestämd tid.
Vi anser att tester är lika nödvändiga som själva koden, om inte till och med lite viktigare. De ger oss en tydlig definition av vad vår kod ska göra och ser automatiskt till att den gör det! Vi kan fritt göra ändringar i koden utan att oroa oss för att saker ska gå sönder. Om testerna är godkända ska allt fungera som förväntat!
Varför använder vi automatiserad testning?
Våra automatiserade tester gör att vi kan gå snabbare fram utan att förstöra saker. Vår manuella QA är mycket snabbare eftersom vi inte behöver försöka göra till exempel Exams med många olika namn. Vi vet från våra automatiserade tester att detta bara fungerar, så vi behöver inte prova det igen själva!
Automatiserade tester gör att vi kan gå snabbare fram utan att förstöra saker
På grund av detta kan vi också vara mycket mer noggranna än vad som skulle vara rimligt att göra manuellt. Vi kan testa alla möjliga åtgärder som koden kan vidta, även de som förutsätter att en del av webbplatsen är nere. Naturligtvis ska detta aldrig inträffa, och att testa det manuellt skulle vara besvärligt. Men vi kan bara låtsas att webbplatsen är nere och se att allt fortsätter som förväntat med våra automatiserade tester!
En parentes: Mätvärden spelar ingen roll
Automatiserade tester väcker alltid diskussionen om hur mycket testtäckning som behövs. Täckning är ett mått på hur mycket av din kod som faktiskt testas av dina tester, angivet i procent. Täckningen av dina tester är något som du automatiskt kan spåra, vilket gör det mycket enkelt att bestämma att den ska vara så hög som möjligt. Om vi har 100% testtäckning borde ingenting gå sönder av misstag, eller hur?
Tja...
Låt oss säga att vi har en funktion som vi skickar ett nummer till. Den gör en mycket komplex beräkning och ger oss sedan tillbaka resultatet. Vad vi skulle kunna göra som ett test är att anropa funktionen och sedan kontrollera om resultatet är ett tal. Detta är naturligtvis inte ett vettigt test för den här koden: vi har ingen aning om funktionen utför rätt beräkning! Men med det här testet kan vi uppnå 100% testtäckning: hela kodstycket har täckts, men inte på ett sätt som betyder något.
Mätvärden är ett bra hjälpmedel för att se att vi inte gör något riktigt konstigt, och därför använder vi dem. Mätvärden är dock inte rätt mått för att se till att vi skriver kod av god kvalitet!
Är allt viktigt?
Vi skriver alltid tester för allt, men vi skiljer mellan olika scenarier
Vi anser att alla delar av Easy LMS är viktiga, eftersom det inte skulle vara detsamma utan dem! Men tyvärr är vi fortfarande bundna av en begränsad mängd tid. Det är inte rimligt att testa allt. Vi måste alltid göra en avvägning av hur djupt vi vill automatisera något. Vi skriver alltid tester för allt, men vi skiljer mellan olika scenarier. I vissa fall räcker det med enkla tester som vi nämnde tidigare, men om något är verksamhetskritiskt går vi ännu längre!
Men vad händer om något är verksamhetskritiskt?
Vissa delar av systemet är verksamhetskritiska. Om till exempel ingen längre kan logga in finns det inte mycket du skulle kunna göra med Easy LMS. Även om våra tester testar inloggningskoden skulle vi fortfarande vilja försöka logga in varje gång innan vi släpper en ny funktion. Att utföra denna validering för hand skulle innebära att vi skulle behöva spendera ett par minuter varje gång vi vill släppa något. Naturligtvis skulle vi kunna göra detta, men ju fler saker vi anser vara nödvändiga, desto fler minuter skulle vi behöva spendera. Och det blir en summa. Lyckligtvis kan vi gå ett steg längre. De tester som vi tidigare har nämnt testar koden, men vi har också acceptanstester. Dessa interagerar med webbplatsen på samma sätt som du skulle göra i din webbläsare, vilket gör att vi kan automatisera bort några av de QA-steg som vi annars skulle behöva ta! Detta innebär att vi kan använda dem för att testa en hel funktion från början till slut. För att återknyta till vårt tidigare exempel behöver vi inte längre logga in varje gång för att se till att det fungerar. Om det inte gör det kommer acceptanstestet att misslyckas! Alla dessa metoder hjälper oss att fånga många buggar innan de når dig, men vi är alla människor trots allt
