Flödesschema för testautomatisering

Flowchart for test automation

2022-04-21

21:st of April 2022

Ofta får jag frågan om när det är värt att sätta i gång med testautomatisering. Jag har gjort några tjog olika utvärderingar för att hjälpa team eller hela organisationer identifiera testautomatiseringsapproach eller om de är redo för testautomatisering. I ett försök att vara pedagogisk producerade jag ett Flödesschema för att hjälpa organisationer identifiera testautomatiseringskandidater.

En påminnelse: Detta är en modell. Alla modeller är per definition en förenkling av verkligheten. Detta måste verkligen understrykas här. Det kan finnas mängder av randfall där testautomatisering ändå kan vara relevant. Mer om detta under själva Flödesschemat.

I often get asked about when it's appropriate to get started with test automation. Personally, I've participated in a few dozen different test automation assessments to help teams or whole organizations identify test automation approach or making sure they are in a state ready for test automation. In a pedagogic attempt I produced the flowchart below to visualize the flow and to help organizations identify possible test automation candidates.

Gentle reminder: This is a model. A model is a simplification of the real world per definition. I really need to highlight this in this context. There are a range of other factors affecting test automation appropriateness for better and for worse. More on that below the actual flowchart.

Under något decennium har jag underhållit och byggt på en Checklista för testautomatiseringsinförande. Den har dock varit svår att förmedla till andra eftersom den i mångt och mycket bygger på att jag vet vad som döljer sig bakom varje delpunkt. Nedanstående schema är ett försök att visualisera några av huvudpunkterna i denna checklista (som också existerar som mer formell Excel med ROI-beräkningar).

During the last decade I've maintained and expanded the Test automation introduction checklist. One problem with the checklist has been that it's hard to communicate to others since it's only myself who knows what hides behind each part in it. The flowchart below is an attempt to visualize some of the main points of the checklist. The checklist itself also exist in an Excel form with two different types of ROI calculations.

Flödesschema för när testautomatisering är relevant att komma igång med. — Flödesschema för när det är relevant att initiera testautomatisering

Flowchart for test automation readiness. — Flowchart for test automation readiness

Värt att notera är att det kan finnas speciella förutsättningar för flera av dessa flöden, och att det då kan bli aktuellt att införa testautomatisering även om detta schema skulle påvisa annat. Detta schema är blott att se som en ledstång för den osäkre. Den erfarne och rutinerade kan se bortom detta.

It's worth noting that there could be specific situations where the flows below are challenged. The flowchart is only meant as a guide rail to hold onto when unsure.

Några väntade invändningar

A few expected objections

Detta måste väl bara gälla tester ovanför enhetstestnivån?

The flowchart must only be valid for tests above unit tests?

Nej.

No.

Men de olika delstegen underlättas såklart av att man har mindre kod att testa, och mindre miljöberoenden, för varje testfall.

But overcoming the different steps and thresholds get easier with less code to test and less dependencies to environmental factors for each test.

Det finns ju skriptfria testautomatiseringsverktyg!

You know there are script less automation tools!

Det är lätt att invända att det ju finns skriptfria testautomatiseringsverktyg, och det stämmer. Trots leverantörernas yrkanden på att vem som helst då kan skapa testautomatisering är min erfarenhet att det måste det vara väldigt speciella omständigheter för att få till fungerande testautomatisering.
Oavsett så behöver man tänka som en programmerare när man automatiserar tester, i procedurer, variabler och tillstånd. Det är också en stor fördel om den som ansvarar för att ta fram och förvalta en testautomatisering är tekniskt bevandrad.

That's correct. Despite of that the vendors claim that anyone can create test automation with these tools in my experience the test automation still fails or is ineffective unless used by coding capable people.
It is true these kinds of tool give you some help in structuring the test automation. Regardless, you need to be able to think like a programmer when automating tests, in variables, procedures and loops. It's also a solid advantage if the test automation people are technically skilled.

Varför just releaser en gång i veckan? Och vilken typ av releaser?

Why releases once a week? And what type of releases?

Nja, där klämde jag bara till med en tidsrymd. Det viktiga är att tänka på hur ofta man tänker sig få värde av att exekvera sina tester. Jag möter ibland team som vill automatisera tester för inköpta system som kommer med nya relaser en gång i halvåret. Det kommer förmodligen att vara ändringar i den releasen, men man kan inte få detaljinformation om dessa ändringar i förväg så att man kan uppdatera testerna innan själva testexekveringen, så första gången efter ny release så exekverar man testerna för att se hur testautomatiseringen behöver uppdateras. Därefter exekverar man många gånger medan man uppdaterar testerna - för att se så att uppdateringarna blir rätt. Det konsumerar mycket testdata och blir väldigt tidsödande. Ju oftare man tänker sig exekvera testerna, desto mindre underhåll är det varje gång.

Well, no I just gave a time span. The important thing is to think about how often you expect to get value from executing your tests. I sometimes meet team who want to automate tests for systems out of their own control, with new releases twice a year. This release will contain changes, but the information sent out before the release will not be detailed enough to update the test automation beforehand, meaning you have to execute the tests several times only while adjusting the scripts for the new release. This consume vast amount of test data and is probably way more time consuming than manual tests. The more often you expect to execute your test automation, the less maintenance effort for each time getting potential value from execution.

Men API-tester då?

But what about API testing?

Detsamma gäller dessa, men vissa saker - som t.ex. underhållet, blir väldigt mycket enklare.

The same goes for API level testing but some things, like the maintenance burden get a lot easier with fewer dependency points to the system under test.

Ett litet undantag är att det faktiskt finns en del tillgängliga verktyg där man inte behöver ha programmeringskunnande för att testautomatisera API-tester, som t.ex. ReadyAPI eller Postman. Det hjälper såklart om man är någorlunda teknisk så att man förstår vad alla konfigurationsmöjligheter gör.

One small exception is that there exist a range of accessible tools where you don't need to have programming knowledge to automate API test, like ReadyAPI/SoapUI, or Postman. However, testing with these tools are not automation by default since automation require robust test data provisioning and some mean of automatic triggering of tests to be repeatable. Even with these tools it helps to have technical knowledge for ease of configuration.

Testautomatisering är en sådan specialistkunskap så vi har en central organisationsfunktion för det

Test automation is such a specialist role that we've got a central organizational function for that

Det fungerar inte.

This won't work.

Ingen blir nöjd. Feedback-looparna blir enormt långa och testautomatiseringen väldigt reaktiv.
Verktygen blir stora och otympliga Enterprise-verktyg eftersom det bara är de som kan hantera alla möjliga typer av tekniska miljöer. Dessa verktyg kräver ännu mycket mer av sina användare, och användarna kommer längre ifrån systemen de ska testa - vilket i sin tur gör testdatasituationen krångligare. Den mesta tiden kommer att gå åt till väntan på externa parter för behörigheter, tillrättaläggande av testdata, svar på frågor om tolkning av testfall o.s.v.

No one get happy with this setup. Feedback loops become annoyingly long and test automation so reactive that most deviations identified by the test automation are both known and fixed by the dev team before it gets reported.
The tools used in this setup are the Enterprise solutions marketed by the big vendors since those are the only tools capable of all technologies. These types of tools are huge and demand a lot from their users. The tool users get further away from the object under test which make the whole testing situation way more cumbersome. Most time end up being spent on waiting for user access, test data, and replies to questions about interpretation of test cases.

Mer läsning om testautomatisering

Är du mer intresserad av att sätta dig in i testautomatisering rekommenderas följande länkar:

The test automation landscape
Kursmaterial för testautomatisering och teknisk testare
Laborationer för att lära sig testautomatisering
Checklista för testautomatiseringsinförande