Har slängt ihop lite vanliga myter, hinder och funderingar om testautomatisering som ni gärna får slå håll på eller kanske bekräfta eller lägga till någon.
Hittar fler defekter
Jag tror inte att alla har denna övertro på automatiserade tester men det är viktigt att förstå att det inte är någon självklarhet att testautomatisering påvisar fler defekter. Frågan är vilka defekter som hittas. I slutändan är det testfallsdesignen som hittar defekter inte att du automatiserar testfallen.
Minskar eller eliminerar manuell testning
Det finns säkert de som tror att automatiserade tester kommer att ta över manuella tester. Så är inte fallet. Automatiska tester slår inte en duktig och kreativ testare och i slutändan är det fortfarande människor som gör testerna genom att använda en annan teknik. Testautomatisering är snarare en annan roll inom området som inte har skapats men blivit viktigare idag. Jag anser även att det inte är en självklarhet att automatiserade tester minskar det manuella testandet. Snarare kan det frigöra resurser för att verifiera andra funktioner.
Alla kan automatisera
Detta beror så klart på vad som ska automatisera. Väljer du att spela in GUI med exempelvis Selenium så behöver du nödvändigtvis inte lika mycket teknisk bakgrund. En testare som arbetar med automatisering behöver enligt mig vara duktig på programmering. Man ska försöka se testautomatiseringskod som vilken annan kod som helst.
Rätt verktyg löser testautomatiseringen
Att först välja verktyg och beställa dyra licenser för att sedan upptäcka att verktyget inte alls löste de krav som fanns är absolut inget ovanligt. Många gör fel när de först söker efter verktyg för att uppfylla ett behov. Istället ska man först undersöka vilket behov som finns och sedan hitta ett verktyg metod som passar.
Otydliga krav eller förväntningar
Som alltid är det väldigt viktigt att ha tydliga krav för att lyckas med implementering av testautomatisering. Vad ska automatiseras, vem ansvar för vad och vilka verktyg/tekniker ska använda är några frågor som måste besvaras. Förväntningarna på testautomatisering kan även vara orimligt höga, det kan ta väldigt lång tid innan man kan börja se resultat och få tillbaka investerade resurser.
Dålig planering
Dålig eller obefintlig planering är ett vanligt fel när man försöker implementera testautomatisering i ett projekt eller företag. Det måste hanteras som vilket annat projekt där resurser och tidsrammar ska finnas på plats. Tydligt mål med ett syfte är lika viktigt för att veta när något är klart.
Testautomatisering är bara värdefullt vid regressionstester
Ingen tycker om repetitiva tester. Eller ja, det finns säkert många som gör det. Men för det första så är inte regressionstester någon som ”måste” automatiseras. Det kan vara bra att manuellt regressionstesta då en duktig testare ofta kommer på kluriga lösningar under tiden som Automatisering av tester går att använda inom flera olika områden. Det gäller att hitta vad som passar just det organisationen eller projektet bäst.
Testautomatisering är lösning på agiltestning
När man pratar om agiltestning kontra korta iterationer är lösningen ofta att man ska automatisera testerna, och då främst regressionstester.
Alla manuella testfall kan automatiseras
Här är det viktigt att fokusera på rätt testfall. I planeringen behövs goda kunskaper i testdesign. Jag skulle rekommendera att använda sig av modeller för att se vilka områden som behöver testat. Därefter bryta ner och designa testfall.
Testautomatisering sparar på kostnaderna för testning
Enligt mig så, nje det tror jag inte. Testautomatisering kostar pengar och kräver resurser. Det är även en stor chans att testautomatiseringskonsulter är dyrare än testkonsulter. Och nej jag tror inte heller att man kan säga att automatisering kan ersätta 4 testare osv. Det är inga bilar vi bygger, och i bilfabriker har ofta flera tusen anställda. Det gör att vinsten kan bli stor om man automatiserar tester som kan göra samma sak som 100 arbetare.
Testautomatisering i hela flöden
Många gör fel när det designar sina testfall. Försök inte att automatisera hela flöden, risken för att det blir fel någonstans blir större. Samtidigt som det blir svårare att återanvända och underhålla sina testfall. Skapa istället moduler över avgränsade funktioner som sedan går att sätta ihop för att testa något.
Testautomatisering är som bilförsäkring
Läste ett väldigt bra exempel. Automatisering är som en försäkring. Även om du aldrig krockar så har du ändå en försäkring på din bil. Det är för att du ska känna dig trygg ifall det skulle hända något. Det går att inte att skaffa en försäkring efteråt.
Blanda tekniker för test
För att uppnå bra resultat på sina tester är det ytterst viktigt att våga blanda och variera sina testmetoder. Automatisering är ett komplement till redan befintliga tekniker.
Testautomatisering ska hanteras som vilken annan kod som helst
Det är bra att försöka hantera testautomatisering som vilken kod som helst. Det gör att det blir en naturlig del av utvecklingen och testerna uppdateras samtidigt med koden.
Skapa rätt arkitektur för testautomatisering så att ni slipper göra om allt för nästa team
Planera och kravställ ramverket för era automatiserade tester. Om ni inte bestämmer er för någon gemensam struktur kommer alla team att göra på sitt eget sätt. Det gör det både dyrt och svårt för medarbetare att byta mellan team.
Intressant blogginlägg som stämmer bra överens med mina uppfattningar om testautomatisering även om de inte är baserade på så mycket erfarenhet. Vill kommentera några punkter.
Hittar fler defekter
Som du skriver, det är alltid testfallet (designen) som hittar ev. defekter. Under förutsättning att det utförs exakt som beskrivet och det är ju det automatiserade tester gör, testar exakt som verktyget är instruerat. Om samma testfall utförs manuellt exakt som beskrivet kommer ju samma defekter hittas. Risken med att köra extremt detaljerade testfall manuellt är ju dock att en testare kan slarva i t.ex. regressionstest efter några körningar men det gör inte automatiserade tester om de är korrekt konstruerade. Till den manuella testarens fördel finns ju dock förmågan att tänka själv och testa lite utanför testfallets scope baserat på en massa bra faktorer som testautomatisering aldrig kan konkurrera med.
Testautomatisering är bara värdefullt vid regressionstester
Min bild är att testautomatisering bara är värdefullt vid regressionstester eller omtest. När testfall designas och automatiseras måste de köras manuellt åtminstone en gång. Om de sedan automatiseras kan samma testfall köras igen och igen. Särskilt om defekter hittats från början är det lämpligt att testfallet körs igen automatiserat. Och då förhoppningsvis med ett annat resultat. Då kan man nog också känna sig tryggare med att testautomatiseringen är väl genomförd.
Testautomatisering är som bilförsäkring
Rolig liknelse som jag skulle vilja dra snäppet längre. En bilförsäkring kan man aldrig vara säker på att den fungerar innan man faktiskt krockar. Och då hoppas få ut den ersättning man har rätt till. Risken finns alltid att försäkringsbolaget slingrar sig eller att man faktiskt inte har rätt till ersättning.
Samma sak kan appliceras på dålig testautomatiseringen. Om man aldrig krockat är det svårt att veta om testerna man kört många gånger faktiskt fungerar. Risken finns att testautomatiseringen är så dålig (dålig verifiering, täckning etc.) att defekter slinker igenom och produktionssätts. Därför kanske det är en idé att “provkrocka” i test så man är säker att de automatiserade testfallen fungerar.
Visst har du rätt i dina reflektioner. Automatisering är väldigt bra för att undvika slarv. Läste någonstans att 90% av alla fel som uppstår beror på mänskliga fel.
När det gäller regressions så anser jag att man måste komma längre. Automatiserade tester blir väll alltid någon form av regression, men kan man samtidigt som man kodar skapa automatiserade tester så används det inte bara för regression men även för funktionstester.
Gillar din fundering runt försäkringar. Du har rätt, hur kan man veta att testfallen fungerar om aldrig har “krockat” kanske skulle man försöka tänkte TDD när man utvecklar automatiserade testfall. DVS börja med att designa testfall som inte kommer att fungera och verifiera att du för rött. När koden är klar så kollar man om det nu blir grönt som tänkt.
/jagge