Utan automatiserade tester, ingen agil utveckling!

Både när jag håller vår kurs Agil test och när jag är ute och besöker våra lite mera agila kunder så skruvar alltid den som ansvarar för testerna lite olustigt på sig när frågan om testautomatisering på någon högre testnivå än komponenttest(unittest) kommer upp. Det är helt förståeligt att dessa personer önskar att de var någon annanstans när testautomatisering på integration- och systemtestnivå diskuteras. De flesta som arbetar agilt inser nämligen att automatisering av systemtesterna är helt nödvändig, men de inser också att det är mycket lätt att misslyckas med en sådan satsning. Det som gör testautomatisering så svårt i agila sammanhang är att objektet som skall automatiseras ständigt förändras och gradvis förfinas. Och är det någonting som en testautomatiserare traditionellt har skytt som pesten så är det ständiga förändringar och det stora underhållsarbetet som förändringarna för med sig.

Trots dessa svårigheter så är ändå den bistra sanningen att utan automatiserade tester, är agil utveckling inte möjlig att införa fullt ut, i varje fall inte med täta produktionssättningar och bibehållen kvalitet. Det stora beroendet av automatisering beror på att omfattningen av systemtest ständigt växer i takt med att ny funktionalitet läggs till i varje sprint. Detta innebär givetvis att den totala mängden funktionalitet/kod som skall testas växer i varje sprint, då ny kod tillkommer medan den gamla fortfarande måste regressionstestas. Detta till skillnad från komponenttest, som nästan uteslutande fokuserar på funktionalitet inom den aktuella sprinten.

Automatiserade tester är helt enkelt det enda sättet att uppnå tillräckligt hög testtäckning i varje sprint och därmed få den höga kvalitet och den snabba feedback som vi eftersträvar när vi inför ett agilt arbetssätt eller för att dra det till sin spets, agila projekt utan testautomatisering är egentligen etappindelade vattenfallsprojekt. Detta beror på att vi manuellt helt enkelt inte hinner regressionstesta tillfredsställande i varje sprint, och därmed skjuter upp regressionstesterna och produktionssättningen till en regressionstest-period efter var 3-6 sprint. En viktig del av feedbacken och buggarna kommer med den lösningen upp till 6 månader efter det att funktionaliteten utvecklades, alltså precis som i etappindelade vattenfallsprojekt!

Vad skall vi automatisera först?

När vi väl har bestämt oss för att automatisera så är det lätt att tro att man skall automatisera samtliga regressionstester och det på en gång. Det är förstås inte ekonomiskt försvarbart att automatisera allt. Manuella tester kommer även fortsättningsvis att spela en stor roll. Det gäller att avgöra vad som skall automatiseras och vad som skall automatiseras först för att få så stora vinster som möjligt av automatiseringen.

Det är många faktorer som avgör vad som skall automatiseras först, men några av dessa områden brukar det vara framgångsrikt att börja med:

• Verksamhetskritisk funktionalitet
• Ofta använd funktionalitet
• Repetitiva testfall
• Testfall som körs mot en stor mängd olika konfigurationer
• Testfall som körs ett flertal gånger med olika testdata eller förutsättningar

Är det lönsamt att automatisera?

För att övertyga ledningen om att få resurser till att göra en testautomatiseringssatsning så brukar det vara en framgångsfaktor att ha en väl underbyggd kostnads-/nyttokalkyl som visar om och när en sådan satsning blir lönsam i rena pengar. Ett bra scablonvärde är att en automatisering bli lönsam efter 4-8 iterationer. För att kunna göra en sådan kalkyl så behöver vi räkna på kostnaden för automatiseringen. Vi upptäcker då snabbt att inom testautomatisering så finns det självklara kostnader som testfallsexekvering och testfallsunderhåll, men vi måste även ta hänsyn till ett stort antal ”dolda” kostnader som licensiering, infrastruktur, support och utbildning.

För att kunna beräkna nyttan av automatiseringen så måste vi titta på fördelarna. Tiden som vi sparar när vi via automatisering exekverar testfallen istället för att exekvera dem manuellt är en uppenbar fördel. En annan fördel är att testautomatisering kan göra det möjligt att testa mer uttömmande, dvs. att exekvera samma test flera gånger med mer varierad testdata och mot olika miljöer. Den största vinsten med testautomatisering är dock att förtroendet för systemet och systemets kvalitet ökar genom att mera heltäckande tester kan utföras. Detta förtroende skapar även möjlighet att förbättra och förändra systemet efter verksamhetens behov så som det krävs i ett agilt projekt. Förutom detta så frigör du även dina testresurser från att testa om redan befintlig funktionalitet till att lägga energin på den nya funktionaliteten där den mänskliga fingertoppskänslan verkligen behövs.

Hur hanterar vi de ständiga förändringarna?

Tack och lov så har vi idag lärt av våra misstag och hittat angreppssätt för automatisering som på ett effektivt sätt hanterar ständiga förändringar. Lösningen till att kunna hantera dessa ständiga förändringar är att funktionsuppdela så att de olika testfallen bygger på samma funktioner i botten så att du bara behöver ändra på ett ställe när en förändring sker. När du knyter ihop de underliggande funktionerna till testfall så kan du använda dig av en lång rad olika tekniker. Några av dessa tekniker är visuella där du visuellt kan se hur testfallen bildas av de underliggande funktionerna, modellbaserad test är ett exempel på en sådan teknik, BPT (Business Process Testing) är ett annat exempel.

Business Process Testing

Business Process Testing är en teknik för att funktionsuppdela de automatisera testerna på ett sådant sätt att varje steg i affärsprocessen automatiseras var för sig för att sedan kunna återanvändas i stort antal testfall för både denna affärsprocess och likande affärsprocesser. Automatiserarna skapar funktioner för alla steg i processen som sedan kan kombineras ihop till olika testfall av icke-tekniska testare eller verksamhetsrepresentanter.
För att förstå vad detta innebär, låt oss först klargöra vad som menas med “affärsprocess”.

En av de första att beskriva affärsprocesser var Adam Smith i sin berömda (1776) exempel på hur ett stift produceras i en fabrik:”One man draws out the wire, another straights it, a third cuts it, a fourth points it, a fifth grinds it at the top for receiving the head: to make the head requires two or three distinct operations: to put it on is a particular business, to whiten the pins is another … and the important business of making a pin is, in this manner, divided into about eighteen distinct operations, which in some manufactories are all performed by distinct hands, though in others the same man will sometime perform two or three of them.”

Så en affärsprocess kan representeras av ett antal steg som tillsammans skapar värde för konsumenten av bolagets produkt. Låt oss se hur Adam Smiths exempel leder till några steg:

1. Draw Out Wire
2. Straighten Wire
3. Cut Wire
4. Point Wire
5. Grind Wire Top
6. Make Pin Head
7. Attach Pin Head to Wire
8. Whiten Finished Pin

Strukturen på listan ovan ser bekant ut, det borde den göra, eftersom vi också beskriver strukturen av ett testfall. Om vi organiserar testfall under affärsprocesser så kan även verksamhetskunniga människor som inte till fullo förstår kod eller testverktyg ändå styra vad de automatiserade testerna skall testa.

Sammanfattning

För att säkerställa kvalitén i agila projekt så behövs det testautomatisering på alla nivåer och detta är fullt möjligt om man tänker efter före hur man bygger upp automatiseringen och hur man tänker hantera de ständiga förändringarna. Rent ekonomiskt så brukar en automatisering bli lönsam efter 4-8 iterationer, medan de riktigt stora vinsterna, högre testtäckning och förtroende att förbättra och förändra systemet efter verksamhetens behov, visar sig redan från första iterationen.

Nästa steg

Det som avgör om testautomatisering är lämplig att införa eller inte är framför allt 3 faktorer.

• Hur ofta och antalet gånger funktionaliteten kommer att behöva testas
• Antalet önskade indata varianter
• Hur lätt applikationen är att automatisera rent tekniskt