Testautomatisering – det bra, det dåliga och den stora frågan

16 maj, 2017

Robert Gistvik, tidigare konsult på Frontit, benar ut vad som är vad inom testautomatisering och hur den förhåller sig till den manuella testningen i sin artikel “Testautomatisering – det bra, det dåliga och den stora frågan”.


Hård konkurrens och en allt mer snabbrörlig värld ställer nya krav på att kunna leverera snabbare och i allt högre takt än tidigare och det verkar inte finnas någon gräns över hur långt vi ska pressa det. Som testare i en sådan värld kan man lätt bli överväldigad.” Lär dig automatisera eller gå under” har jag hört många testare få som råd, men kan vi verkligen ersätta manuella tester med automatisering?

Jag försöker här bena ut vad som är vad inom testautomatisering och hur den förhåller sig till den manuella testningen.

Kontinuerliga leveranser förutsätter automatiserade tester

I en värld där DevOps, CI, CD och liknande termer blir allt vanligare (läs min artikel om DevOps) håller utvecklingen en takt där det byggs nytt, eller till och med levereras, flera gånger om dagen och därmed finns behovet av att testa i samma takt. Med manuella metoder känns det rätt hopplöst att försöka hänga med i det tempot och ur detta föds tanken att låta maskiner göra testarnas jobb.

Olika nivåer av automatisering

Att prata om testautomatisering som ett enskilt begrepp är inte helt trivial. Det finns flera olika nivåer och de tjänar alla olika syften och dessutom finns det en del gråzoner om ett test tillhör en viss nivå eller inte. På det stora hela brukar testerna delas in i tre större grupper, oftast i en pyramidform – där vi nu börjar nerifrån.

Enhetstester

Detta är tester som oftast programmeraren själv skriver och jobbar man med testdriven utveckling så är det dessa som skrivs först. I andra fall behöver dessa skrivas i efterhand. Testerna skrivs i samma språk som programmeringen görs i och syftar till att kontrollera att specifika delar av koden (metoder eller komponenter) beter sig på ett förväntat sätt och körs varje gång ett bygge görs. På så vis säkerställs att kodändringarna inte har påverkat funktionalitet i någon annan del av kodbasen. Det är ofta i detta sammanhang man pratar om code coverage, dvs hur mycket av koden som har testats igenom.

Exempel på verktyg för denna nivå: TestNG, JUnit, NUnit. I princip alla programmeringsspråk har ett bibliotek för att hantera enhetstester.

Integrationstester

Kärt barn har många namn heter det och för denna nivå förekommer benämningar som acceptanstester, API-tester, komponenttester och servicelager. Här handlar det om att testa de APIer och den funktionalitet som integrerar med andra system eller delsystem. Till den här nivån räknas även olika typer av prestanda-och säkerhetstester.

Exempel på verktyg för denna nivå: SoapUI, JMeter, Postman

Gränssnittstester

Till sist har vi nivån ligger närmast det som vi normalt kallar testning. På den här nivån körs testerna mot det slutliga användargränssnittet och tanken är att det är en riktig användares beteende som ska simuleras.

Exempel på verktyg för denna nivå: Selenium, AutoIt, Sikuli

Det bra

Automatisering ger oss möjligheten att snabbt få feedback på ett systems status och om vi råkat ha sönder något. Maskiner utför operationer snabbare än vad en människa gör och kan göra saker som vi människor inte alls kan, som till exempel simulera tusentals samtidiga användare i ett kontrollerat testsystem. Snabbare feedback gör att vi kan ta oss framåt snabbare och i slutändan få ut vår produkt snabbare.

Testerna blir exakt reproducerbara eftersom det är samma kommandon som utförs varje gång ett test körs.

Att ha tester på samtliga nivåer gör att vi snabbare kan identifiera ungefär var i systemet ett fel uppstått vilket underlättar felsökningen och vi kan snabbare hitta och åtgärda problemen.

Det dåliga

Automatisering är dyrt. Ju högre upp i pyramiden vi kommer desto dyrare blir testerna att underhålla då ett gränssnitt har en större tendens att ändras och påverkas än enskilda funktioner nere i botten. Ordentligt automatiserade tester tar tid, tid som kanske skulle kunna användas till att utveckla fler funktioner istället.

Riktiga användare beter sig inte som maskiner utan kan göra något oväntat eller med en annan timing.

Testare kan upptäcka problem utanför den tänkta vägen genom att faktiskt titta på hela användargränssnittet istället för att bara följa de förutbestämda instruktionerna.

Den stora frågan

Så, kan vi ersätta all manuell testning med automatisering?

Absolut inte är mitt klara svar på det! Vi kan än så länge inte få maskiner att fatta beslut som en människa och kan därmed inte förstå och utforska ett system på samma sätt som en duktig testare kan med hjälp av sin kunskap om systemet i sig och sina erfarenheter av metoder och verktyg. Det som automatiseringen ger oss är att vi kan utnyttja tiden på ett bättre sätt. Istället för utförliga, tidskrävande (och ofta tråkiga) regressionstester kan vi få djupare insikt inom nya områden och kända problemområden.

Testautomatisering blir snarare ett viktigt stöd och komplement till den manuella testningen och ytterligare ett verktyg i vår testlåda i vår jakt på bättre kvalitet.

I de allra flesta fall finns det vinster i att åtminstone ha en grundnivå av automatisering så den stora frågan visar sig inte vara om vi kan eller ska ersätta manuella tester med automatisering utan snarare vilka och när.

Komma igång med automatisering

Hur man ska bete sig för att komma igång med automatisering är svårt att ge en generell beskrivning för. Det beror helt enkelt på vad förutsättningarna är, vilken kompetens som finns tillgänglig och vad ens system har för syfte. En generell rekommendation är att börja från botten av pyramiden och att faktiskt börja överhuvudtaget. Allt måste inte komma på plats direkt utan arbeta in det område för område tills önskad automatiseringsgrad är uppnådd. Det är bättre att göra något litet än att inte göra något alls.

Analysera förutsättningarna

Det finns mycket att ta hänsyn till när det kommer till automatisering, men en början är att fundera över detta:

  • Vad gör vårt system? En enkel kampanjwebbplats har antagligen helt andra kvalitetskrav än ett stridsflygplan.
  • Gör en riskanalys. Vilka områden har vi historiskt haft problem med?
  • Vad har vi för kompetens? Kan någon redan en metod eller ett verktyg kan det vara idé att börja där innan man tar det vidare. Behöver vi ta in experthjälp?
  • Hur mycket ändrar vi? Ändras användargränssnittet mycket och ofta kanske den typen av automatisering är direkt olämplig.

På Frontit arbetar vi med agila processer, test och kvalitet. Vill du diskutera detta ämne eller jobba med oss? Hör av dig till lars.linderoth@frontit.se


 

Dela artikel
Facebook
LinkedIn
E-post