Vanliga frågor om QA-verktyg

Vid monorepo har du all kod på ett ställe jämfört med kanske en mikrotjänstarkitektur där man bryter ut i smågrejer så då har du redan en automatisk uppdelning.

Men det finns verktyg som man kan använda men det är oftast lite beroende på vad du använder i övrigt. Om vi tar exemplet Azure DevOps, där kan man styra att när man checkar in vissa delar, då kör man vissa saker men kanske inte alltid göra riktigt, riktigt allt. I slutändan så kommer man ändå behöva någon form av extern taggning eller någonting på testfallen för att kunna säga att ”nu har jag ändrat de här delarna i koden och då ska jag köra de här testfallen” så den mappningen kommer inte out of the box, den behöver man oftast sätta upp själv.

Man får också fundera lite grann på om man vill ha snabba tester eller om man vill ha mycket tester. Man kanske till och med vill köra hela sin testsvit, så i stället för att du lägger ner mycket energi på att säga ”jag har de här delarna och då kör jag bara de testerna i mitt monorepo”, eller som någonting annat, att kan jag snabba upp de testerna som jag har så att man spenderar den tiden i stället på ett sånt arbete och ser till att man exekverar alla sina tester. Då behöver man inte hålla på och mappa.

Har ett exempel på när användning av vi väldigt mycket taggning när vi checkade in. Vi använde Git i bakgrunden och hade en commit som vi gjorde och taggade den på ett specifikt sätt och den taggen triggade testfall. Vi hade då förutbestämt ett visst område och varje gång taggadning av incheckning med det området skedde så kördes de testerna. Men själva mappningen var någonting som vi då behövde sätta upp manuellt innan.

De flesta känner kanske till Git men vill ändå nämna det som ett första steg till exempel för de som kanske inte är jättevana med att jobba i devteam och som är intresserade av att göra det. Så är versionshantering och Git väl värt att titta på. Bra med just strategi  men även operationer i Git som triggar pipelines eller assembly lines som rasslar igång och utför tester. Det finns mycket att prata om men det är associerat till vilken teststrategi man har, om man ska testa allting på slutet om man har ett monorepo eller om man kan testa delar innan. Även mycket rapportering, dashboards och liknande.

Är man student och ska ut i arbetslivet så tycker jag att det finns en del grundläggande saker som är väldigt viktiga.

Det ena är Git versionshanteringssystem. Lär dig Git och se det som ett pussel. Sitt hemma, gör en branch, merge:a för skoj… alltså ta det till dig till 100 %.

Det andra är Linux-terminalen eller någon form utav Shell scripting och terminalen över huvud taget, att använda terminalen. Vad ska man säga?

De två sakerna är fundamentet. Och ett annat fundament, återigen om man är student och ska ut i yrkeslivet, det är att fingrarna möter tangentbordet så att lär er maskinskrivning. De som kan skriva och skriver snabbt med fingrarna på tangentbordet har det förspänt. Det är tre väldigt, väldigt grundläggande saker. 

För QA specifikt så passar till exempel Cypress på det systemet som många testar idag. Men det är inte så att det passar överallt så även om det är en favorit och vi skulle gärna använda det överallt så är det olika och då måste du faktiskt använda något annat. Vi kan ha favoriter, absolut, men samtidigt måste du tänka på vilket verktyg som passar just där du befinner dig. 

Sitter man med moderna applikationer, det vill säga de som är byggda på React, JavaScript, då är det JavaScript-verktyg bland annat Cypress, Playwright som många använder nu. De två verktygen passar utmärkt för just React-utveckling och för dagens applikationer och webbläsare. Så just trenden är framförallt om man kör webbaserad testning, men om det är A/B - test då är det givetvis något annat. Men när det gäller Frontend-automatisering och webbaserade tjänster, då är Cypress en av dem som trendar just nu skulle jag säga.

Om man däremot skulle lära sig scripta är det Power shell som gäller för det kan man använda överallt. Vi har kommit så pass långt nu så man kan köra det både i Windows och Linux och på Mac. Väldigt enkelt att komma igång med också. När det kommer till API, så om ett verktyg ska klara av lite mer än bara en sak så någonting liknande JMeter för det kan man både göra funktionella tester och systemtester med. Man kan lasta ett system med ett och samma verktyg och inte behöva skriva om saker hela tiden. Postman är ett annat verktyg som utvecklare mer sitter och skjuter enstaka API:er med och kanske gör lite enklare grejer men vill man ha lite tryck på det hela, då är Postman inte ett alternativ. Då är JMeter bättre, man kan köra funktionella grejer, lastgrejer och systemtest med ett och samma verktyg. Så det är väl ett API-verktyg som man bör titta på. Sen är Selenium en personlig favorit när det kommer GUI-testning. Det är mer utvecklingsnära, man får mer flexibilitet, man kan koppla upp sig mot databaser och på så sätt hämta in testdata utan att behöva bygga in det i testfall på ett annat sätt som man kanske inte direkt gör med Cypress när du kör i en browser. Så Selenium och Cypress ifall man ska göra någon form utav GUI-testning, JMeter, Postman, kanske SoapUI ifall man gör API-testning och sen så Power shell ifall man ska scripta någonting.

Ja, Playwright  är ett sådant som vi gärna skulle vilja utforska lite mer.

Ja, det finns en trend också inom GUI-tester som inte är så hårdkodat till att scripta och skriva själva testfallet utan mer GUI-baserade verktyg, som typ Tosca eller något liknande. Så det är någonting om man kanske inte är så jätteduktig på att koda.

I princip är det verktyg som spelar in när man klickar och skapar allting i bakgrunden som man egentligen då skulle göra själv i ett verktyg som Cypress exempelvis. Utifrån det byggs sen testfall så man ser egentligen ingen kod utan får som ett flöde ungefär. Man kan koppla det på lite olika sätt, så det blir lite drag and drop och på så sätt bygger man upp ett GUI-test. Nackdelen där blir att det blir jobbigt sen när man tänker på verkligheten och börjar jobba med mer tabeller och såna saker kanske. Att få till riktigt bra testfall med det och då hamnar man ändå tillbaka till någonting som Cypress eller Selenium eller något annat verktyg. Så just nu så känner jag att de verktygen kanske inte riktigt är där men det kan vara en inkörsport om man inte kan så mycket kodning, men då skulle jag nog kanske rekommendera att ta ett programmeringsspråk och lär dig bara grunderna i det. Man behöver inte vara en expert på det för att kunna skriva testfall, men att man kan lära sig ganska snabbt och läsa vilket programmeringsspråk som helst grundläggande och skapa testfall, utifrån det snarare än att använda såna verktyg.

Tipset är väl att aldrig vänta med att uppdatera. 

Om på något sätt känner att man har en väldigt stor verktygslåda, då blir det väldigt mycket att uppdatera. Då kanske man ska ta sig en titt i sin verktygslåda och fundera på att ”behöver jag alla de här 32 verktygen eller skulle jag klara mig med kanske hälften utav dem”. Då blir det bara hälften utav den här lasten att sanera bort och uppdatera.

Exempelvis både Selenium och Cypress, de gör samma saker egentligen. Vissa har bra funktionalitet för en sak, den andra har kanske lite bättre funktionalitet på något annat område. Men behöver jag ha de två och kanske ett tredje och ett fjärde verktyg. Man får kanske begränsa lite och säga att vi kör Cypress och Selenium eller bara Cypress så minskar man underhållsbördan av sina verktyg. Och kontinuerligt uppdatera betyder små förändringar. Stora hopp, då kanske du behöver göra större ingrepp i det hela så det gäller att hålla life cycle på det där som allting annat som man gör.

Verktyget ska hjälpa dig i ditt arbete och stödja din process. Det är inte det att du ska jobba för verktyget, utan verktyget ska jobba för dig. Så om man utgår ifrån sin utvecklingsprocess och sin metodik man har, så alla de stegen som man gör, gör man ju för hand de första fem gångerna sen går det över i att du börjar bygga in det mer i en automatisk pipeline för då har man satt det rutinmässiga arbetssättet och det är då man kan börja jacka in de där grejerna.

[Tips om verktyg som används i utvecklingsteam hittar du i denna artikel]

Och då vet man redan ”jag har byggt upp mina enhetstestfall på det här sättet, då lägger jag in det som ett automatiskt steg som alltid kommer med alla mina pipelines. Då har jag det överallt och då missar jag inte några enhetstest”.

Sen tar man kanske nästa kliv och börjar fundera  ”jag vill ha statisk kodanalys också”, då skohornar man in SonarQube eller något liknande verktyg som tar hand om den biten. För den feedback som man får från verktygen sen, det är den jag kan använda för att stoppa min process också, att inse: ”Här spottar den ut så att jag fyra, fem, sex stycken säkerhetshål. Då kanske det inte är den grejen jag vill ska gå ut i min nya BankId-applikation” som kommer redan nedlusad. Då bygger man in det sen.

Det blir lite grann att man har ett verktyg som ger dig någon feedback som ska jag ta mig vidare till nästa steg i pipeline.

Det finns en grej som man kanske inte alltid tänker på när man har sin pipeline men det är det här med loggning. Att få den automatiska feedbacken den vägen. Så även om man tänker på att man bygger in allting i pipeline, man har sina testverktyg och allting ser jättefint ut. Sen glömmer man bort sin egen applikation, hela loggningsdelen som den spottar ur sig, och så tittar man aldrig på den eftersom man litar blint på sitt verktyg.

Den enklaste grejen man egentligen kan göra redan från början, det är att i sin applikation bygga in ett bra loggningsverktyg. Till exempel Elasticsearch eller Splunk eller något liknande som på ett väldigt enkelt sätt aggregerar upp alla loggningar. Hittar den något error exempelvis i testerna, då är någonting fel.

En sak som man också måste tänka på, är att allting ligger inte bara i pipeline utan man ska bygga in saker och ting vid sidan. För i ett DevOps-perspektiv där man har det ut direkt i produktion så har man redan allt det där på plats. Då kan man luta sig tillbaka, dricka kaffe och hålla koll på sin dashboard ungefär. Så det är en sak man också absolut inte ska glömma bort, att allting ligger inte i själva pipelinen.

Ja, det är ju ett återkommande problem. Det bästa är att få ett statiskt id på ditt attribut och har man inte det så måste man prata med utvecklarna och se ifall de kan lägga in det stödet i själva koden. Class kan man också använda så länge det är statiskt och inte rör på sig hela tiden för att skulle man skriva massa testfall som sen vid en uppdatering får helt nya attribut, då blir det problem. Då är det underhållsproblem. Så det är viktigt att ha statisk attribut i dina element och har man inte det så får man antingen lägga in det själv eller så får man med hjälp av utvecklarna i teamet försöka lägga in det. Man ska absolut undvika att ha dynamiskt genererade. På så sätt kan man ha mer pålitliga tester.

Om man tänker som så här, det tar kanske en minut ungefär att lägga till ett id i sin kod och då har man sin statiska grej som man alltid kan lita på och den är unik så att den träffar rätt varje gång. Jämfört med hur lång tid tar det varje gång som man hittar att någon XPath har ändrat på sig och man måste gå in och uppdatera sina testfall på grund av den här ändringen. Man kommer väldigt snabbt tjäna på det. Vill man slippa mycket underhåll i sina GUI-tester, då är det statiskt id som man använder.

Vanliga för- och nackdelarna är att man har ingen support på open source medan du har det på kommersiella verktyg. Man har väldigt bra support på båda två så haka inte upp dig på en sån sak utan titta snarare på vad man får ut av verktyget och hur mycket man är beredd att själv investera i verktyget. För väljer man ett open source-verktyg så kanske det inte innehåller allt du behöver men vill man ta en liten utvecklingsresurs kan man specialanpassa ett sånt verktyg. Det kan du inte normalt sett göra på ett större verktyg. 

Man kan se det lite grann ungefär som en objektorienterad del i själva dom:en som inte syns normalt.  Man accessar den via JavaScript-kod i stället. Så alla testverktygen som man använder, de accessar också dom:en och har möjlighet till dem. Då behöver man bara leta reda på det elementet. Favoriten skulle vara att köra det raka spåret i Selenium bara helt enkelt.

Samtidigt finns också stöd i andra verktyg, bland annat Cypress. Egentligen är väl frågan kanske inte vilket verktyg man ska använda, utan vilket verktyg har du i dag för det finns stöd i de flesta för att använda Shadow Dom.

Det kan vara så att Shadow root:en är dold. Att om man som testutvecklare vet att den finns där och försöker accessa den så kanske man ändå inte kan klicka på den för att den är inte synlig.

Om man tänker alla element i en webbläsare, det är lite beroende på hur dem är implementerade så är de ibland inte synliga eller är accessbara. Då går det inte att klicka helt enkelt. Så det är en sak man behöver hålla koll på i sina tester precis som vanligt när man gör GUI-tester med vilket ramverk som helst. Att ”är objektet synligt, kan jag använda det, är det accessbart”. Det är de här normala checkarna som man får lägga till själv. Om man tänker Cypress, den sköter det här under huven så man behöver inte som testare tänka på att ”kan jag hitta objektet”. Vet jag bara var det finns någonstans så behöver man inte bry sig, då sitter Cypress och väntar tills det är accessbart innan du kan klicka. Medan du själv får kompensera för dessa saker i Selenium där du ändå skriver din kod själv.

Det är fördelen med Cypress, att ha automatiska väntetiderna som i stället för att faila själva stegen väntar den tills den har hittat elementen eller väntar på själva API-anropet tills den har kommit fram och då är allt synligt och då kan man trycka nästa steg.

Man får lite mer out of the box i Cypress som man själv måste ta höjd för att implementera i Selenium som då ligger och exekverar utanför själva webbläsaren. För Cypress kör i själva webbläsaren.

Man kanske inte måste välja det ena eller andra. Samtidigt, framför allt när man ska bygga sitt eget, har man stöd av utvecklarna till exempel så blir det lite enklare än om man skulle ha ett verktyg för rapportering, skriva testfall i ett verktyg och så vidare och så vidare. Så har man stöd av utvecklarna, då blir det enklare just att bygga ett eget i stället.  Men som sagt det beror på vilket stöd man får.

Ett tips är att försöka välja de verktyg som utvecklarna själva använder helst. Det ett väldigt starkt argument, och för man in nya verktyg så vill man ha acceptans för det.

Utveckling och test går hand i hand och det är väldigt viktigt att du har utvecklarna med dig på din sida. Allt ska flyta på. För du behöver deras stöd.

Med ett do-it-all verktyg är fördelarna att man har mycket out of the box från systemet. Man blir lite begränsad kanske. Det är implementerat på ett visst sätt och tanken är att det ska fungera på ett visst sätt för att det ska jacka ihop med alla andra boxar i det systemet och det kanske inte är riktigt så som processen var tänkt från började.

Å andra sidan så slipper man skapa en mindre utvecklingsavdelning som egentligen bara tillverkar just det här verktyget och underhåller just de här verktygen runt omkring. Så om man tänker stora grejer som Azure eller AWS eller vilken molntillverkare som helst, i princip vilken kedja som helst så kan du jacka in saker och ting men man får själv scripta in de små bitarna.