Inspiration & Kunskap

Checklista - 12 punkter för bra automatiserade tester

Det finns flera skäl till eller mål med att skriva automatiserade tester. Att skriva dessa tester är förhållandevis enkelt, men att skriva ”bra" automatiserade tester är betydligt svårare och kräver lång erfarenhet och medveten träning. I det här inlägget har jag samlat några mål (på hög nivå) som behöver uppfyllas för att de automatiserade testerna ska bli bra. Målen är sedan nedbrutna i totalt 12 punkter. Definitionen av ”bra” automatiserade tester är när alla 12 punkter är uppfyllda.

Här är några mål på hög nivå som kan gälla:

  • Tester bör hjälpa oss att förbättra kvaliteten.
  • Tester bör hjälpa oss att förstå systemet.
  • Tester bör reducera (och inte öka) risk.
  • Tester bör vara enkla att köra.
  • Tester bör vara enkla att skriva och underhålla.
  • Tester bör kräva minimalt underhåll när systemet utvecklas runt dem.

Tester bör hjälpa oss att förbättra kvaliteten

1. Test som specifikation

Om du använder TDD - testdriven utveckling eller BDD - beteendedriven utveckling (test-först-utveckling) ger testerna dig ett sätt att fånga vad systemet ska göra innan du börjar bygga det. Att tänka igenom olika scenarier för att göra dem till test hjälper oss att identifiera de områden där kraven är tvetydiga eller motsägelsefulla. Sådan analys förbättrar kvaliteten på specifikationen, vilket leder till förbättrad design som i sin tur förbättrar programvarans kvalitet.

2. Defektavstötande

Automatiserade tester hittar buggar, men det är inte huvudsyftet med testautomation. Automatiserade tester förhindrar att buggar införs. Tänk på automatiska tester som defektavstötande, som hindrar fel från att komma tillbaka till vår programvara efter att vi har sett till att den inte innehåller något fel. Där vi har bra kompletta regressionstester har vi inga buggar eftersom testerna kommer att peka ut felen innan vi ens checkar in vår kod.

3. Utpekning av defekter

Om de automatiserade testerna är ganska små (det vill säga att vi bara testar ett enda beteende i var och en), kommer vi att kunna fastställa (peka ut) felet snabbt, baserat på vilket test som misslyckas. Men för att uppnå det måste vi skriva tester för alla möjliga scenarier för att täcka varje enhet av programvaran. Testerna får aldrig innehålla fel (defekter). Därför är det avgörande att vi håller testerna så små och triviala som möjligt (låg komplexitet, konsekvent format och testar ett enda beteende i varje test).

Tester bör hjälpa oss att förstå systemet

4. Tester som dokumentation

Automatiserade tester kan tydligt belysa hur koden ska fungera. De visar vad resultatet ska bli (det anger det förväntade resultatet av ett eller flera påståenden).

Om vi vill veta hur systemet gör något, kan vi aktivera felsökaren, köra testet och stega igenom koden för att se hur det fungerar. Enhetstesterna fungerar som en form av dokumentation för systemet.

Tester bör reducera (och inte öka) risk

5. Tester som säkerhetsnät

Att ändra äldre kod är riskabelt eftersom vi ofta inte vet vad vi kan ha sönder, och det är också svårt att veta ifall vi har haft sönder något! Vi måste arbeta väldigt långsamt och noggrant, och göra mycket manuell analys innan vi gör några förändringar.

När vi arbetar med kod som har en automatiserad testsvit kan vi däremot arbeta mycket snabbare. Testerna kommer att fånga oväntade sidoeffekter av förändringar och meddela oss om vi har haft sönder något. På det här viset fungerar de automatiska testerna som ett säkerhetsnät som gör att vi vågar ta chanser.

Läs även: Testautomatisera strategiskt - så ska du tänka (video)


6. Ingen testrisk

Vi måste vara noga med att inte införa nya typer av problem i systemet till följd av automatiserade tester. Håll testkoden separat från produktionskoden för att undvika att skapa testspecifika beroenden i systemet (särskilt viktigt för enhetstestkoden). All testspecifik kod och bibliotek ska länkas in av testet och endast i testbygge och i testmiljö. Testberoenden och testkod får aldrig finnas i den skarpa koden när den är byggd för produktion.

Tester bör vara enkla att köra

Det finns fyra specifika punkter som gör automatiska tester enkla att köra. Med dessa fyra punkter uppfyllda är det bara att klicka på en knapp (eller ännu hellre trigga igång automatiskt) för att få den värdefulla feedback som testerna ger:

  • Testerna måste vara helt automatiserade så att de kan köras utan ansträngning.
  • Testerna måste vara självutvärderande så att de kan upptäcka och rapportera fel utan manuell inspektion.
  • Testerna måste vara repeterbara så att de kan köras flera gånger med samma resultat.
  • Varje test ska vara oberoende så att det kan köras för sig själv.

7. Fullt automatiserade tester

Ett test som kan köras utan någon form av manuellt ingripande är ett helt automatiserat test. Att uppfylla den här punkten är en förutsättning för att kunna uppfylla de andra.

8. Självutvärderande

Ett självutvärderande test har kodat in allt det testet behöver för att verifiera att det förväntade resultatet är korrekt. Testet meddelar oss endast när utfallet inte har godkänts; som en konsekvens kräver en ren testkörning noll manuell ansträngning.

9. Repeterbara tester

Ett repeterbart test kan köras många gånger i rad och ger exakt samma resultat utan någon mänsklig inblandning/analys mellan körningarna.

Tester bör vara enkla att skriva och underhålla

När vi ändrar beteendet hos en del av systemet bör vi förvänta oss att ett litet antal tester påverkas av våra modifieringar. En av fördelarna med testautomation är att göra förändringar enklare. Vi bör därför alltid sträva efter att se till att våra tester inte gör det motsatta (gör förändringar svårare). Tester bör kräva minimalt underhåll när systemet utvecklas runt dem.

10. Enkla tester

Vi bör hålla fokus på tester snarare än kodning av testerna. Det innebär att testerna måste vara enkla/triviala (enkla att läsa, enkla att skriva och enkla att underhålla). Vi bör sträva efter att verifiera ett tillstånd per test genom att skapa en separat testmetod för varje unik kombination av förutsättningar. Varje testmetod bör testa systemet genom en enda väg i systemet.

11. Uttrycksfulla tester

Ett bibliotek med hjälpmetoder som bygger upp ett domänspecifikt testspråk möjliggör för personen som skriver testkoden att uttrycka de koncept som den vill testa, utan att behöva översätta sina tankar till mycket mer detaljerad kod.

12. Dela upp problemen

Håll testkoden separat från produktionskoden (behåll strukturen och logiken från produktionskoden men i en parallell struktur). Varje test bör fokusera på ett enda problem för att undvika komplicerade och otydliga tester.

 

Sammanfattning

Det är skillnad på test och bra test, men det är ofta svårt att vet hur man ska definiera ett test som just bra. I den här checklistan delar jag med mig av 12 punkter för bra automatiserade tester, där kravet på att testerna ska vara enkla att skriva och underhålla är en viktig del. 

Att bygga och underhålla mjukvara blir alltmer komplext. Därför behöver vi utveckla fler och fler verktyg och tekniker för att hänga med och vara konkurrenskraftiga. Det gör det svårt att hitta balansen mellan kvalitet och innovation, struktur och kaos. Vår CQA-guide är skapad för att hjälpa dig med just det, ladda ner den nedan! 

Ladda ner CQA-guiden

 

Inte tid att läsa nu?

Ladda ner artikeln som en pdf istället.

Skrivet av

Viktor Lazslo

är automatiseringsexpert och har i mer än 22 års tid jobbat med att effektivisera mjukvarutestning och utveckling med hjälp av verktyg, automatisering och processförbättringar både internationellt och i Sverige. Viktor har omfattande kunskaper inom systemutveckling och programmering samt i att ta fram verktyg för funktionella- och prestandatester.

Inte tid att läsa nu?

Ladda ner artikeln som en pdf istället.