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
Ä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
Skicka en kommentar
Trevligt att du vill dela med dig av dina åsikter! Tänk på att hålla på "Netiketten" och använda vårdat språk.