Fredagsfix och andra fienden till framgångsrik testautomatisering

Automatisering av testfall är en av inneaktiviteterna i mjukvarubranschen just nu, men samtidigt är det inte ovanligt att höra uttalanden som "Vi testade att automatisera, men det fungerade inte" eller "Vi har lite automatiserade tester, men vi använder dem inte för de går sönder hela tiden". Måste det bli så här? Naturligtvis inte. Här kommer några viktiga checkfrågor. De kan låta självklara, men vara nog så viktiga att påminna sig om emellanåt.

1. Går det att automatisera det du vill testa?

Första frågan som bör ställas är så klart om det överhuvudtaget går att testa det du vill säkerställa på ett bra sätt. Är det ett API eller ett UI som ska testas så är det oftast lugna puckar, men hur testar du till exempel att videon som strömmas till användaren inte hackar eller ser dålig ut? Visst kan man kolla bit rates och jämföra olika frames och annat, men frågan är: Är insatsen som behövs värd besväret, eller blir det effektivare att fortsätta testa hela eller delar av testbasen manuellt?

2. Är testobjektet tillräckligt stabilt?

Hur mycket kommer gränssnittet att förändras under projektets gång? Ska du testa ett redan publicerat API? Go for it! Ska du testa ett UI vars arkitekt bestämmer sig för ett nytt utseende varje vecka? Glöm det! Manuella testare är oftast både anpassningsvilliga och luttrade efter många projekt med luddiga och föränderliga kravspecar, men ett testramverk är ytterst bokstavstroget. En knapp som har flyttats eller bytt namn löser testaren för det mesta med ett höjt ögonbryn, medan det automatiska testfallet får krupp och vägrar fortsätta. Dessutom krävs det varje gång en inte obetydlig insats för att rätta till de tester som gått sönder.

3. Automatiserade testfall kräver tid till underhåll!

Detta för oss osökt över till nästa punkt på listan: Det går inte att tro att man kan lägga en stund på att automatisera sina testfall och att man sen bara behöver exekvera dem för all framtid. Testfallen behöver underhållas kontinuerligt om inte ansträngningen för att laga dem ska bli för stor, vilket leder till att ramverket faller ur bruk och lika gärna kan slängas. Alltså kan man inte allokera 100% av resurserna till att utveckla nya testfall eller att exekvera manuella testfall - det kommer att straffa sig i längden!

4. Kan det återanvändas? Gör det!

I alla mjukvaruprojekt är underhållbarhet superviktigt. Men i automatiseringsprojekt där det ofta är förhållandevis få resurser som ska lösa allt från att skriva nya och underhålla gamla testfall till att utveckla testramverket och att rapportera resultat, så är det ofta kritiskt. Är klockan 16 på en fredag och utvecklarna har precis släppt ett antal API-förändringar som ska testas i helgen? Vill du behöva ändra på ett ställe i en utility-fil eller i alla dina 500 testfall? Trodde väl det...

Är de nödvändiga förändringarna i ramverket så stora att de tar dagar att fixa, så är antingen projektet blint för mjukvarans kvalitet eller så upptäcks inte regressioner när de kommer in. Detta innebär ofta att det tar minst lika lång tid att uppdatera ramverket som det tar att reda ut orsakerna till alla nya fallerande testfall. Dessutom kan personer som är upptagna med underhåll inte användas till att skriva nya testfall.

5. All makt åt integratörerna!

Naturligtvis går det att undvika mycket av dessa problem om man har processer på plats för att 1) förvarna testutvecklarna om att förändring är på gång så att de kan uppdatera ramverket i tid och 2) slänga ut eventuella förändringar som förstör testresultaten. Har man dedikerade integratörer så är dessa ofta bra personer att stå på god fot med som testare. De har koll på vad som är på gång och de vet ofta vad som troligtvis orsakar problem, speciellt om det är ett continuous integration-system där testautomatiseringen är inbakad i integrationsmiljön. Har intergatörerna makt att inte ta in eller slänga ut dålig kod eller kod som innehåller beteendeförändringar som inte rapporterats i förväg och inte ständigt blir överkörda av ivriga projektledare eller produktägare, så kan detta gå väldigt smidigt och kvaliteten över tid blir ofta hög. Är leverans NU det viktigaste, så får projektet räkna med att det uppstår luckor i testtäckningen och att kostnaderna för underhållet ökar.

6. Testa testkoden! Eller: Ändra aldrig något viktigt på en fredag...

Tyvärr är det ju inte bara utvecklarna av produktionskod som kan slå sönder ett testramverk, även testutvecklarna själva brukar vara bra på detta. Speciellt problematiskt brukar detta bli om man "bara" ska ändra "den där lilla grejen som inte påverkar något annat" en fredag eftermiddag eller strax innan man kör igång den där kritiska testsviten innan leverans. Det slutar ofta med gråt och tandagnisslan.

Att testare orsakar instabilitet brukar tyvärr också resultera i att utvecklarnas och projektets förtroende för testresultaten minskar drastiskt och ofta under en lång tid.

Är resultaten kritiska för projektet? Se då till att 1) testa och granska alla förändringar i testramverket ordentligt innan de kommer i produktion och 2) gör inga kritiska förändringar i till exempel centrala delar i ramverket precis innan några extra viktiga tester ska köras. Jag hoppas att jag inte har skrämt bort alltför många med mina exempel på allt som kan gå fel... Det viktiga är att du ser på testutveckling på samma sätt som du ser på utveckling av produktionskod. Då kommer säkert även ditt projekt att bli ett lyckat exempel på testautomatisering!

Informator erbjuder flera spännande kurser inom Kravhantering och Testmetodik. Se alla våra kurser inom Krav och Test här

/Daniel Johansson, Test Automation Engineer