Testautomatisering – Att lyckas genom att misslyckas

Så här misslyckas du garanterat

När vi startade ett stort projekt som skulle pågå i två år med sammanlagt 8 iterationer förstod vi på testgruppen ganska så snart att det skulle bli väldigt kostsamt och till och med tråkigt att genomföra manuella regressionstester efter varje leverans. Men det finns ju verktyg för automatiserade tester och efter en kort verktygsanalys köpte vi QTP från HP och skickade en testare på grundkurs och avancerad kurs i verktyget. När första iterationen hade levererats spelade testautomatiseraren in den efter framgångsrikt manuellt test och kunde exekvera dessa tester vid leverans av iteration två. Så fortsatte det framgångsrikt genom samtliga iterationer och vi hade till slut en stor uppsättning automatiserade tester, som vi tänkte använda även i kommande leveranser efter produktionssättning av projektet. Testautomatiseraren drogs därefter in i andra testprojekt utan testautomatisering. När vi åter ville exekvera våra automatiserade tester märkte vi att fler och fler av våra regressionstester inte fungerade längre.

Begångna misstag:

• Det saknades en tydlig definition av vad som ingick i regressionstesten
• Att spela in tester istället för att scripta
• Att bara ha en testautomatiserare, som dessutom används i andra testprojekt som har ingenting med testautomatisering att göra
• Att börja med en testautomatiseringskunnig istället för med en specialist på området
• Att inte ha ordning på Object Repository i QTP som leder till duplicerade objektdefinitioner

Släng allt och börja om från scratch

Med hjälp av en extern testautomatiseringsspecialist började vi analysera vår situation och skapade på en månad en ny strategi för vår testautomatisering. Vår strategi innehåller följande viktiga kapitel:

• Regressionstestningens omfattning och innehåll
• Tidsåtgång och kostnad för manuell regressionstest
• Alternativa strategier för regressionstest och vägval
  • Manuell test
  • Enkel automatisering
  • Förfinad automatisering
• Förutsättningar för att kunna automatisera
  • Förbättrade testfallsbeskrivningar
  • Kunskap om kommande ändringar (krav)
  • Bra hantering av testdata
  • Stabila testmiljöer
  • Val av testfall som ska automatiseras
• Mål med testautomatiseringen och automatiseringsgrad
• Organisation
  • Roller och krav på dem
  • Bemanning
• Riktlinjer för testautomatiseringen
  • Användning av Object Repository, funktionsbibliotek, testdata, dokumentation

Vad skönt att slippa skriva testfall

För att steg för steg realisera vår strategi skapade vi en Roadmap med delmål per halvår och aktiviteter som sträckte sig fram till två år. Vi valde att automatisera enligt Model-based testning vilket har fördelarna:

• Slipper skriva testfallen I textform utan modellerar dem istället, vilket är roligare och överskådligare
• Ändringar görs i grafen (och kod OM det behövs) vilket underlättar underhållet
• Diskussioner om hur ett fel upptäcktes, vägen dit etc. görs med hjälp av grafen och inte genom att studera kod!
• Enkelt att “stänga av” vissa delar av testerna (för applikationsunderhåll etc.)
• Hittar fel innan test under grafmodellering
• Grafen isolerar test från verktyg, d.v.s. samma arbetssätt för Selenium, LR m.fl.
• Arbetsfördelning: Verksamheten kan modellera – testautomatiserare implementerar QTP kod
• Testtäckningen ökar markant med samma insats

Låt en höghastighetsidiot testa det tråkiga

Det finns en rädsla bland somliga testare att de blir överflödiga när man automatiserar test. Visst är det så att maskinen tar över en stor del av det arbete som vi testare gjorde manuellt.

Testautomatisering kan delvis ersätta manuella tester och är snabbare än en manuell testare. Men den kan aldrig ersätta en testare. Datorn är som bekant en höghastighetsidiot och inte kreativ och intuitiv som en duktig testare. Dessutom automatiserar vi för att:

• Hitta fel snabbare i regressionstester
• Snabbare feedback till utvecklare om en release kvalitet
• Lätt och tidseffektivt att köra om tester vid behov
• Ta bort tråkiga, rutinmässiga testaktiviteter för manuella testare och frigör därmed tid för kreativa testaktiviteter, vilket gör våra testare gladare
• Ha en lägstanivå på vad som testas
• Ha en konsekvent testning