Livet som testutvecklare

"Livet som..." är en bloggserie där vi får träffa olika personer i deras vardag och lära oss mer om deras yrkesroll.

You can find an English version of the article here!

I denna del av "Livet som..." träffar vi Viktor Nilsson som arbetar som testutvecklare på Infotiv.

Viktor har studerat Systems, Control & Mechatronics på Chalmers Tekniska Högskola. Utbildningen är en blandning av el, mekanik, elektronik och programmering. Viktor sommarjobbade hos Infotiv och det var då han kom i kontakt med testning. På Infotiv fick han upp ögonen för testning och insåg att det finns en hel bransch kring testning. Sedan 2014 arbetar Viktor som konsult på Infotiv. Han har även tagit rollen som kompetensledare där han driver kompetensutvecklingssatsningar. Han har även varit ansvarig för utbildningar på IT-högskolan som utbildar just mjukvarutestare. På Infotiv är hans arbetsroll Inhouse Testutvecklare vilket innebär att han är med och projektleder projekt ut mot kund och internt.

Viktor ska berätta om mjukvarutestning och dess olika steg, manuella- och automatiserade tester samt framtidsspaningar.

Mjukvarutest

Mjukvarutest handlar om, i grova drag, två övergripande frågor. Den första är: ”Fungerar produkten som förväntat?”. Detta har att göra med om vad man från början hade tänkt bygga och utveckla. Den andra frågan är: ”Tillför produkten något värde för kunden?”. Det är möjligt att bygga något som fungerar precis som vi förväntar oss, dvs att den inte har några buggar eller fel. Men om det inte finns någon som vill ha produkten, den fyller ingen funktion, eller syfte och tillför inte något värde, är det med största sannolikhet inte ens värt att gå vidare med produkten.

Dessa två frågeställningar är olika från varandra men båda är lika relevanta. Det är samma åt andra hållet; det går att bygga något som gör ett försök till att tillföra värde men som inte fungerar riktigt som den ska. Det är inte heller en komplett produkt. Det är de här frågorna som vi som mjukvarutestare försöker besvara. Sedan tillkommer det självklart detaljer, och det går att gräva djupt i dessa frågor. Men det är alltid det här hållet som man siktar in sig på.

Mjukvarutestningsprocessen

När testning av en produkt ska utföras, finns det ett antal steg att gå igenom. Bilden ovan visar en förenklad och övergripande bild av den processen. Traditionellt sett har detta varit en process som sträcker sig över lång tid. Planeringen ligger då ett halvår eller ett år fram i tiden och ett steg i taget har teamet gått igenom processen. Detta är något som har ändrats på senare år. Ett modernt mjukvaruutvecklingsteam kanske går igenom denna process en gång om dagen eller en gång i månaden. Detta har att göra med att ju snabbare en mjukvara har utvecklats desto kortare vill man göra denna process. För det moderna teamet, krymper tidshorisonten men det är fortfarande flera moment som man försöker göra i mindre och mindre steg.

Planering

Planering är startpunkten i processen. Då besvarar man på frågor som: ”Vad planerar vi att utveckla?” och ”vad ska vi lägga till för funktionaliteter i vår produkt?”.

Övervakning & Styrning

Denna del av processen är något som sker löpande. Detta gäller speciellt om arbetet involverar automatisering. Det kan vara så att det körs tester flera gånger om dagen eller åtminstone varje natt. Vi behöver därmed skapa en bild av det vi testat och ta reda på om vi täckt in de tester som hör till det vi utvecklat. Befinner teamet sig i början av en utvecklingsloop är svaret troligtvis nej. Teamet kommer då behöva gå vidare och börja designa. Det handlar om att titta på sina testresultat och fråga sig om allt fungerade som förväntat. Teamet funderar också på om det finns något ytterligare som behöver testas.

Analys & Design

I dessa steg går vi in i detalj på det som vi bygger och utvecklar. Det kan handla om vilka nya features som planeras att lägga till i produkten som utvecklas. Det kan vara allt från att produkten ska hantera en ny typ av betallösning via vår webbshop eller om vi ska göra en bil självkörande. Detta kommer i sin tur ställa olika krav på testningen. I det här steget tas även det som ska utvecklas med och som testare funderar vi på hur vi ska testa på bästa sätt. Här kommer det in specialiserade förmågor som man som testare har med sig. Det gäller att känna till och utgå ifrån det vi utvecklar för att sedan hitta sätt på hur vi kan säkerställa kvalitén. Denna del handlar även mycket om samarbete. Arbetar teamet i en modern organisation, sker arbetet ofta tät ihop. Testutvecklarna, programmerarna och de som har koll på kundens önskemål är de tre olika delarna i teamet. Det är viktigt att alla tre parterna är involverade för att kunna förstå vad som planeras att byggas, vad som är nytt och vad som inte kommer att ändras. Det är viktigt att de funktioner som redan finns i produkten fortsatt fungerar oavsett om det tillkommer nya funktioner eller ej. Det är inte många kunder som hade accepterar en ny funktionalitet till priset av att det gamla slutar att fungera. Ju större och mer komplex en produkt är desto mer kod och desto mer funktionaliteter finns det som vi behöver säkerhetsställa för att kunna bibehålla kvalitén.

En del av testerfarenheten som blir viktig här är att förstå var det är störst risk att något går fel. Detta kommer också styra hur vi designar och lägger upp vår testning. Om vi sedan tidigare vet att betallösningar är krångliga att få till, då vet vi också att vi kommer behöva lägga mycket krut på att få till en fungerande fakturabetalning. Det kan också vara så att vi kommer behöva lägga mycket tid på manuell testning för att verkligen förstå hur allt fungerar. Här kan de som är experter på att skriva kod komma in och påpeka om något har en tendens att ställa till det för teamet. Då kan man utnyttja det i testdesignen för att kunna testa så effektivt och så bra som möjligt. Som med all utveckling kommer det finnas begränsat med tid och resurser. Det är därför viktigt att göra avvägningar: ”Var ska vi lägga vår insats för att få ut så mycket som möjligt?”. Det är viktigt att försöka tänka utanför det normala användandet av produkten. Det kommer komma kunder som gör på ett helt annat sätt än det som man själv tänkt. Det kommer uppstå scenarion som kanske inte är så vanliga, speciellt under utvecklingsfasen. Om distributionen av produkten sker till 100 000 användare och det är en låg frekvens av ett annorlunda beteende, då kommer ändå detta beteende återkomma ganska många gånger.

Implementation

Här handlar det om att antingen skapa någon form av plan för sina manuella tester eller att implementera automatiserade tester där det är möjligt och lämpligt.

Utförande

Ingår manuella tester i processen, är det i detta steg de ska utföras. Handlar det i stället om automatiserade tester är det snarare att trycka på start och invänta resultat.

Avslut & Feedback

Dessa två steg innebär att knyta ihop säcken. Teamet ska sammanställa resultaten för att kunna utvärdera produkten. Vi ställer oss frågan om produkten är klar eller inte. Sedan börjar denna process om igen och på det sättet fortsätter det.

Många gånger är det inget som blir färdigt utan det kan i stället handla om att ta fram ett nytt feature till exempel. Det kan också behövas gå ett varv till om produkten inte uppfyller de krav som ställts på den. Då tittar vi på om det finns möjlighet att förbättra den eller testa produkten ytterligare. Traditionellt sett har testning alltid varit något som görs i slutet och det har setts som ett nödvändigt ont som bara behövs checkas av. Detta har ofta lett till att om något annat i processen drar ut på tiden, kläms testningen ihop på slutet. I moderna företag, som arbetar med mjukvaruutveckling, är det vanligt att testningen involveras så tidigt som möjligt i processen. Det är något som kan ske löpande för exempelvis varje feature som utvecklas.

Stegen i processen är alltså något som testare går igenom många gånger, speciellt om arbetet sker i snabba, korta loopar och målet är att släppa färdiga produkter kontinuerligt.

När jag skrev mitt examensarbete på Volvo Trucks, uppkom en fråga ofta: ”Hur snabbt måste våra automatiserade tester ge ett resultat tillbaka?”. Det man siktade på var 250 millisekunder. Det var en acceptabel tid för att ge ett första svar. Vi insåg fort att det inte kommer vara möjligt att täcka in allt på 250 millisekunder. Men ett första svar skulle komma på den här tiden, från att någon hade skrivit kod, meddelat att produkten är redo för testning och att sedan återkoppla. Varför det är just 250 millisekunder är på grund av att om det är längre tid då tappar man fokus och andra saker som kaffepaus blir aktuellt i stället. Vi vill kunna ge snabb återkoppling till de som skrivit koden för att de ska få reda på om koden de skrivit var tillräckligt bra eller att den inte funkar som det var tänkt. Skulle vi få våra testresultat en månad senare, kommer det bli svårt att komma ihåg exakt hur vi tänkte. För att denna process ska gå så snabbt som möjligt, behövs det automatisering. Sedan går det inte att automatisera allt, men för att ge ett första svar så är automation en nyckeldel.

Infotiv & Test

Nu ska jag berätta om hur vi på Infotiv arbetar med testning. Detta tillvägagångssätt är inte något som vi själva har kommit på utan det är något som branschen i helhet går mot. De tre stöttepelarna som vi bygger vår testningsverksamhet på är: Metodik, infrastruktur och testsystem. Låt oss börja med metodik-delen.

Metodik

Metodik-delen innehåller vilka teststrategier som behövs som tillhör den långsiktiga planen. Hur bygger vi en produkt så att den faktiskt går att testa? Vi behöver ha en plan hur vi ska ta de ingående komponenterna och sätta ihop dem för att få en färdig produkt.

Aspekten way of working handlar om att arbeta agilt. Detta innebär att arbetet sker i små team och teamet fokuserar på en del av en produkt i stället för att se kodning och testning som två separata aktiviteter. Det handlar också om hur vi kommunicerar resultat och hur vi samarbetar.

Living documentation handlar om vikten av att dokumentera arbetet. Det är viktigt för att kunna förstå vad vi gjorde för tre månader sedan till exempel. Det har också att göra med frågan: ”Vad ställde vi för krav på vår produkt tidigare och hur förväntar vi oss att den ska fungera?”.

Den här delen innefattar också ISTQB-certifiering som är ett organ som har flera olika typer av certifieringar inom mjukvarutestning. Det är alltifrån grundläggande nivåer till mer avancerade nivåer. Vi på Infotiv utbildar och certifierar på den grundläggande nivån. Vi ser det som en viktig del att skapa en grundförståelse hos alla våra konsulter när det gäller mjukvaruutveckling som begrepp.

Infrastruktur

Denna del blir allt viktigare ju mer man arbetar med automatisering, eftersom det finns många kringliggande system som mjukvarutestare kommer i kontakt med. Det handlar om allt från ramverk för testautomatisering till continuous integration. Continuous integration innebär att teamet använder sig av små kodförändringar som sker löpande för att bygga produkten och att produkten testas för att säkerställa att den fungerar som en helhet. Infrastruktur-delen handlar även mycket om analys och mätning av pågående testning. Det kan då handla om övervakning och att tillhandahålla testresultat på ett lättöverskådligt sätt som det går att ta beslut ifrån. Den sista delen, serverarkitektur, är tätt sammankopplad med IT. Eftersom automatiserad testning är en komplex process, kommer det krävas stöd från IT.

Testsystem

Testsystem handlar om det som sitter nära produkten. Det handlar då om hur vi interagerar med en produkt, till exempel. Ett komplext exempel kopplat till detta är en dator i en bil. Datorn i bilen är kanske van att kommunicera 100 andra datorer. Men vi vill testa endast en dator och vi vill kunna göra detta på ett isolerat sätt. Då behöver vi ett system runtomkring som tillåter oss att lura mjukvaran att tro att den sitter i en riktig bil fast den inte gör det. Det handlar om att hur vi interagerar med det vi ska testa på ett så effektivt sätt som möjligt vilket är en viktig del inom just automatisering.

Automatiserade tester vs manuella tester

Automatiserade tester och manuella tester har olika användningsområden. Automatiserade tester ger stor nytta vid tester som behöver göras om och om igen. Det är också användbart när vi behöver bekräfta att vi ska täcka in ett beteende som inte ska försvinna. Om vi testar en webbshop till exempel, kan kunden logga in, titta på beställningar osv. Det är då viktigt att se till att alla nuvarande funktionaliteter fungerar samtidigt som vi introducerar ett nytt. Skulle detta inte fungera, är det något som kan göra att värdet för kunden försvinner.

Den manuella testningen är i stället bra på att hitta buggar i de lite mer krångliga fallen. Den manuella testningen är bäst att utnyttja nära inpå att koden skrivits. Detta är för att kunna hitta kluriga fall som kan befinna sig flera steg in i produkten. I sådana fall är det enklare att göra manuell testning. Att hitta nya buggar, där tillför den manuella testningen mycket medan att se till att man inte förstör något som tidigare skapats då är automatiserade tester mer användbart. Det är ett gränsland också eftersom automation kan tillföra väldigt mycket just i utvecklingsfasen för att kunna ge den snabba feedbacken på det som utvecklas. Det är viktigt att vara medveten om begränsningen med automatiserade tester och vad som faktiskt behöver testas manuellt.

Verktyg inom automatiserad testning

https://digital.ai/periodic-table-of-devops-tools

Ovan visas en övergripande sammanställning över de populäraste verktygen inom automatiserad testning. De olika färgerna indikerar olika kategorier. En utmaning som ofta förekommer är att välja rätt kombination av verktyg för att få en helhetskedja. Det är inte ovanligt att vi kan behöva byta ut verktyg allteftersom vi hittar bättre verktyg, eller så kan det tillkomma nya verktyg som ersätter de gamla. Detta är viktiga delar som man funderar på inom arkitekturdelen på verktygsfronten.

Det är väldigt sällan en person kan alla verktyg som en arbetsgivare efterfrågar. Har en person arbetat mycket inom en viss kategori finns det ofta likheter mellan programmen inom samma kategori. Det kommer alltid att finnas ett visst överlapp; kan jag verktyget Maven då kommer jag känna igen mycket i Gradle till exempel. Jag kommer behöva lära mig nya saker men konceptet och syftet med verktyget kan vara likadant. Detta innebär att det är viktigare att förstå en hel kedja och dess komponenter än att just kunna ett specifikt verktyg.

Att behöva lära sig nya verktyg är en verklighet för konsulter. Kommer man till ett nytt uppdrag är det stor sannolikhet att det finns verktyg som man inte känner till sedan tidigare. Det samma gäller för programmering och olika programmeringsspråk. Kan du någon form av programmering, kommer det finnas en hel del gemensamt och sådant som du kan utnyttja från tidigare programmeringsspråk du använt dig av.

Att arbeta i ett testningsteam och viktiga roller

Att arbeta i team inom testning är en utveckling som tagit stora kliv. Traditionellt sett har det varit en avdelning som kodar och en avdelning som testar. Det blir vanligare och vanligare att de två avdelningarna går samman. Detta medför att konsulterna då kan ha en helt annan bredd än tidigare. Denna utveckling inom testning har inneburit att tre olika specialistkompetenser vävs samman: En kodansvarig, en testansvarig och den som är ansvarig för att kundens önskemål uppfylls. Inom teamet behöver vi svara på följande frågor:

• Vad ska vår produkt göra?
• Hur ska den fungera för att kunna ge värde till kunden?
• Hur ska produkten testas på bästa möjliga sätt?
• Hur ska produkten byggas med en så effektiv kodbas som möjligt?

Personen som är ansvarig för kod behöver vara en duktig programmerare som kan lösa kundens problem med en bra kod. Personen som är ansvarig för testningen behöver ha kunskap inom både automatiserade tester och manuell testning. Teamet måste bygga något som går att sälja, därför behövs en person som förstår kunden behov och som samtidigt förstår interaktionsdesign dvs att det ser tilltalande ut och är lätt att använda bl.a. Det tror jag är lätt att missa om man kommer från en test- och programmeringsbakgrund, där koden är det viktigaste.

En roll som tidigare inte nämnts är en IT-kunnig person. Det behövs någon som kan infrastruktur-biten dvs hur vi får i gång alla verktygen och som ser till att servrarna fungerar som de ska etc. Det här är ofta ett hinder för team. Teamet vill öka sitt tempo men har inte den kompetensen eller stöttningen från IT vilket resulterar i att det blir svårt för teamet att ta sig vidare.

Att kunna väva samman de här specialistkompetenserna är viktigt när vi utvecklar en produkt. Det är även viktigt att ingen del lämnas utanför. Vi kan ha kodat mycket men vi vet inte om produkten fungerar. Vi kan ha skrivit många testfall men vi har ingen produkt som lever upp till dem. Eller så är fallet att vi både har kod och test men vi vet inte riktigt om det är rätt sak vi byggt för att vi inte har haft någon kommunikation med personen som faktiskt vet vad den här produkten ska åstadkomma. Att synkronisera de olika delarna och att i stället ta små steg framåt, där ser jag mycket utmaningar framöver och även där det finns mycket utvecklingspotential.

Framtidsspaningar inom yrket som testutvecklare

Jag tror att arbetet med snabba feedbackloopar kommer att bli ännu viktigare i framtiden. Idag siktar företag att få ut sina produkter på marknaden i snabbare takt än tidigare. En bil ska inte ta fem år att utveckla utan den tiden ska kortas ner och en fungerande mjukvara ska komma ut på marknaden så snabbt som möjligt. Det kommer kräva teknisk kunskap för att få allt detta att fungera. Men det kommer också kräva ännu tätare samarbete mellan testare och experterna som skriver själva produktkoden. Att kunna arbeta ännu tätare i team, för att kunna utnyttja hela verktygskedjan tror jag kommer bli ännu viktigare.

Man brukar prata om att det handlar om att en person behöver ha kompetenser som är t-shaped. Detta innebär att personen behöver ha en bred bas men samtidigt en specialisering. Basen är viktig att dela med sig av mellan testutvecklare och programmerare. Som testutvecklare är det viktigt att förstå hur produkten är uppbyggd för att kunna testa snabbt och effektivt. Jag som testare behöver kommunicera med mina kollegor och lära mig av dem som är bra på att programmera för att kunna förstå hela processen. Detta tror jag är en viktig del. Det är ju så att ju snabbare vi kan få ut en produkt på marknaden desto snabbare får vi betalt och det är ju såklart en stor drivkraft.

Att utbilda sig till testutvecklare

Under min karriär har jag kommit i kontakt med två ytterligheter när det gäller utbildning. Jag har själv studerat fem år på teknisk högskola och känner att jag i och med det har en väldigt bred bas att stå på. Jag har kunnat klara mig bra inom mjukvarutestning, även om jag bara använder lite av det som jag läste under programmeringskurserna. Jag har under min utbildning spenderat fem år på att lösa jobbiga problem i stället vilket är något som jag tar med mig och har användning av i mitt arbetsliv. Flera kollegor som jag arbetat med har studerat på nischade utbildningar mot just mjukvarutestning. De kommer direkt ut till arbetslivet med den specifika verktygskunskapen, som de olika stegen i automationskedjan till exempel. De har också den grundläggande förståelsen för vad testning är och vad testningen tillför. Jag tror att det går att göra karriär med båda bakgrunderna, det handlar snarare om att hela tiden vilja utveckla sig själv. Har man en utbildningsbakgrund som liknar min då kommer man behöva sätta sig in i mer specifika verktyg. Kommer man från en mer nischad utbildning då kanske det handlar om att bygga erfarenhet av problemlösning i stället. Detta beror också på vilket håll man vill utvecklas åt. Vill en person bli en väldigt duktig testautomatiserare till exempel, då anser jag att de som läser en mer nischad utbildning har ett litet försprång. Detta på grund av att de har både programmering och de specifika verktygen för testautomatisering med sig i bagaget.

Finns intresset i stället mer åt teststrategier och ”den stora arkitekturen” då är nog en längre teknisk utbildning ett bra val eftersom den förmodligen ger större förståelse för komplexa system till exempel.

Finns det något område där testning inte används idag, där du ser stor potential?

Jag tror det finns aspekter av testning där det finns områden där det kan vara lämpligt. En grundläggande testaraktivitet och kvalitetssäkringsmetod som används både av testare och programmerare är granskning, även kallat kompiskollen. Man frågar en kollega om de kan dubbelkolla ens arbete för att se till att allt ser bra ut. Efter att ha arbetat som testare och arbetat mycket med kodgranskning, kan jag inte ens skicka i väg ett Excel-dokument utan att en kollega har tittat på det. Det är lätt att göra misstag i kod och det är ännu lättare att göra ett misstag i ett Excel-formulär. Om jag hade fått gissa, tror jag det är många företag där det kan ha jättestor påverkan om det slinker in en nolla för mycket i ett Excel-dokument.

Att samarbeta och arbeta i ett team där man granskar varandras arbete, det är ett område jag tror på. Inom programmering finns det till och med ett koncept med parprogrammering, där man sitter två för att det inte ska bli fel.

Hur hittar jag uppdrag inom IT och testning? 

A Society är den nya tidens konsultbolag och kan hjälpa till att förmedla uppdrag mellan konsulter och kunder som söker efter personer inom IT och testning. Registrera dig på hemsidan så får du en kontaktperson som kontaktar dig för att höra vad du letar efter för typ av uppdrag samt så får du tillgång till uppdrag som annonseras ut i A Societys nätverk. Att gå med i A Societys nätverk är helt kostnadsfritt. 

Läs även avsnittet om Johan Sjögren som berättar om hur det är att arbeta som maskininlärningskonsult samt när Paulina Raymond presenterar hur det är att vara UX-designer.