Automatiserte tester i testpyramiden - En nøkkel til effektive IT-løsninger?

Kan automatiserte tester virkelig revolusjonere måten vi jobber på? I dagens episode har vi med oss vår kollega Kent-Erik Tøllefsen, som deler innsiktene fra sitt arbeid med automatisert testing og kontinuerlig deployment. Kent tar oss med bak kulissene i et prosjekt hvor han har vært en sentral aktør i å implementere testpyramiden på alle nivåer, fra enhetstesting til systemintegrasjon. Denne episoden lover å gi deg en dypere forståelse av hvordan tillit til IT-løsninger kan bygges gjennom høy kvalitet og pålitelighet, og hvorfor dette er avgjørende for vellykkede hyppige deployeringer.

Over tre episoder vil vi utforske også hvordan automatiserte testprosesser kan gi utviklere frihet til å gjøre endringer uten frykt for systemkollaps. Sammen med Kent diskuterer vi utfordringene og gevinstene ved en slik implementering, samt hvorfor en fem-årsplan kan være nøkkelen til suksess. Til tross for kostnader og ressursbruk i starten, er de langsiktige fordelene betydelige, med redusert behov for feilrettinger i produksjon. Bli med oss for å høre om hvordan din organisasjon kan ta skrittet mot mer effektive og pålitelige IT-løsninger.

Episode 1 fokuserer på betydningen av testing og kontinuerlig deployering i programvareutvikling, med særlig vekt på automatisering. Gjennom erfaringer fra Kent Tøllefsen diskuteres utfordringer, strategier, og viktigheten av tillit til teknologi i utviklingsprosessen.
 
 • Introduksjon av dagens gjest, Kent Tøllefsen
 • Hva som menes med deployment og dets betydning
 • Betydningen av tillit til kvaliteten i løsninger
 • Gjennomgang av testpyramiden og dens nivåer
 • Kents erfaring med automatisert testing
 • Overgangen fra utvikler til testutvikler
 • Hvordan automatisering muliggjør hyppige deployeringer
 • Testing som en integrert del av utviklingsprosessen
 • Kostnader forbundet med kvalitetsstrategier
 • Fallgruver og utfordringer i organisasjonsendringer

send oss en melding til testpodden@webstep.no med navn, kontaktinfo og hvilken episode du hørte på sist , så er du med i trekningen av dagens episodepremie :-)

Chapters

• 0:00 Automatisk Testing Og Deployment Med Kvalitetsgladiatorer
• 7:39 Automatisering Av Testpyramiden
• 19:00 Automatiserte Testprosesser I Utvikling

Transcript

Torbjørn Laukvik Host

00:00

Hei, hei og velkommen til nok en episode av Testpodden. I dag er det som vanlig Torbjørn Laukvik som maser her, sammen med

Jan Mjelde Co-host

00:11

Jan Mjelde

Torbjørn Laukvik Host

00:12

og så har vi besøk av 

Kent-Erik Tøllefsen Guest

00:14

Kent Tøllefsen

Torbjørn Laukvik Host

00:15

Yes og det er en kollega av oss som sitter og jobber litt med deployment - og hva som må til for å klare å gjøre dette når man vil - rundt sagt - og det er et interessant tema. Veldig ofte, når man driver og lager en IT-løsning, så må dette etter hvert bygges, releases, slippes ut til noen brukere et eller annet sted, og målet er, å kunne gjøre det her ved behov. Hvordan man gjør det kan gjøres på alt mulig, fra manuell til sånn automagisk. Man er sikker på, at man ikke ha tiltro til løsningen eller kvaliteten må være god.

Jan Mjelde Co-host

01:04

Man er sikker på at man ikke deployer en ny løsning med for mye alvorlige feil.

Torbjørn Laukvik Host

01:12

Ja, det er viktig få feil, og hvordan kan vi løse dette? 

Jan Mjelde Co-host

01:18

ja, det var derfor vi har bedt Kent om å komme da, for han har real life experience med prosjekt hvor man har startet med å finne ut, hvordan kan man komme dit at man kan teste i alle nivåene i testpyramiden automatisk og også klare å deploye hyppig.

Torbjørn Laukvik Host

01:41

Så bra - testpyramiden. Hva legger du i det ordet, jan? 

Jan Mjelde Co-host

01:45

Ja, det er, det er det vi tenker på med at man må teste på på alle nivåer i testpyramiden. Da er vi på en laveste nivå, at man tester enhetene, de små byggestenene som man bygger et system av, og så neste nivå er kanskje modulene, integrasjonene mellom disse byggestenene, og videre oppover i systemintegrasjonene, hvor man da setter disse sammen med andre systemer, og til slutt er det sluttetest, hvor alt sammen skal funksjonelt henge sammen, og det er en sånn pyramide som er kanskje lett for oss å tenke på som gitt. Men det er jo ganske essensielt i det vi skal snakke om Kent, fordi det er vel der kanskje det ofte stopper opp i sånne initiativer med å få til automatisk testing og fiktive testdata og sånn. Det å få til det på alle nivåene i den testpyramiden er ikke det riktig.

Kent-Erik Tøllefsen Guest

Det stemmer ganske bra

Jan Mjelde Co-host

ja, for du har jobbet med dette på ett eller flere prosjekter kanskje?

Kent-Erik Tøllefsen Guest

02:51

Jeg har i hovedsak jobbet med det på ett prosjekt, men jeg har jobbet med det ganske lenge da. Jeg har jobbet med det siden januar 2012,. Hvor det var ganske nytt på markedet, kan man kanskje si. Jeg kom jo da inn som testutvikler og det var vel kanskje ikke en veldig utbredt stilling.

Jan Mjelde Co-host

03:14

Du var litt forbanna over det egentlig? 

Kent-Erik Tøllefsen Guest

03:15

Ja, jeg var rett og slett litt forbanna. Jeg kom inn som en litt sånn hardcore backend-utvikler, og så kom jeg inn hos denne offentlige etaten, hvor man hadde bestemt seg for å gå fra stormaskin til Java, og jeg havna på et enmannsteam da som testutvikler.

Jan Mjelde Co-host

03:35

Bare deg?

Kent-Erik Tøllefsen Guest

03:36

bare meg, og en testleder - han var faktisk fra Simula forskningssenter, som hadde lagt premissene for hvordan dette skulle gjøres da.

Jan Mjelde Co-host

03:47

Men da var det altså en forskningsbasert testleder. 

Kent-Erik Tøllefsen Guest

03:49

Det er forskningsbasert dette de valgte å satse på der da. 

Jan Mjelde Co-host

03:54

Det er interessant at de – OK - og så fortell?
 
 

Torbjørn Laukvik Host

03:58

Det viktigste her akkurat nå er det morsomme som jeg biter meg fast i: En utvikler som kommer inn, og så får du labelen «test» i panna, og så blir du sur over det? Kjempegøy! Hvorfor det?

Kent-Erik Tøllefsen Guest

04:10

Jo, fordi jeg så for meg at test ikke sant - før jeg kom som testutvikler da, fra en backend-utvikler, Java-utvikler, så så jeg for meg test som noe helt annet enn å faktisk sitte og utvikle og lage løsninger for å teste. 
 
 

Jan Mjelde Co-host

04:28

Du var negativ?

Kent-Erik Tøllefsen Guest

04:30

Ja, jeg var det - når jeg kom inn, men etter hvert da som jeg forstod hva det her innebar og hva vi skulle gjøre - så synes jeg det her er veldig mye kulere enn å sitte som ren utvikler i et mer lukka scope, i et vanlig utviklingsteam.

Jan Mjelde Co-host

04:48

Ja, musikk i mine ører!

Torbjørn Laukvik Host

04:51

...Fordi jeg tror jo at..- jeg har jo forsøkt å fronte ordet kvalitetsgladiator som en motvekt til security champion.

05:01

Ikke motvekt, men tillegg da, og jeg synes det er et veldig bra til eller kvalitets kjemper eller bug - skadedyr-bekjemper, for så vidt bug hunter – ikke sant? Og det er litt sånn. Hvordan vil du si, det er et stempel som passer for det du driver med - en kvalitets-gladiator?

Kent-Erik Tøllefsen Guest

05:24

Ja, det er jo det -vi - kan du si – det man hadde bestemt seg for å prøve å satse på der da, og det startet jo opp som et litt sånn prøveprosjekt, og man så, at dette her fungerte veldig bra, og etter hvert da så gikk man jo videre og bestemte seg for å satse på det videre da i denne organisasjonen.

Jan Mjelde Co-host

05:50

Litt farlig uttrykk, da jeg synes jo i hvert fall uten at jeg kjenner så godt til gladiatorene, men jeg inntrykkert, at det er særs høy dødelighet. Så jeg håper ikke, det var det som dere opplevde?

Kent-Erik Tøllefsen Guest

06:02

Nei, ikke for oss utviklere i hvert fall, men bugsene, de døde!

Torbjørn Laukvik Host

06:07

Ja, det er bra. Spennende!

ja, og da driver det altså. Målet er jo da, å kunne, som jeg snakker om, å deploye ved behov.

Jan Mjelde Co-host

06:19

Hvorfor det da?

06:23

Hvorfor vil du deploye ved behov? 

Torbjørn Laukvik Host

06:25

Hva er ønsket med det Hva er? 

06:26

ønsket med det?

Kent-Erik Tøllefsen Guest

06:28

Vi ønsker jo å få kode raskt ut, ha rask turnaround, kunne gjøre endringer fort 

Jan Mjelde Co-host

Det er prodfixer, det er nyutvikling mm. 

Kent-Erik Tøllefsen Guest

06:40

Man slipper å ha disse testperiodene, testukene, etter at en sprint er ferdig. 
 Du kan si det sånn - for å hoppe litt frem - så det det endte med etter at vi hadde etablert dette her- så var det jo slik, at vi kutta ut en egen prodsetting, vi kutta ut testuker - to testuker - som det var før der også - dette ble avviklet. 

07:06

Man beholdt noe av den monkey-testingen på webben, men det vi klarte å få til var at man kunne gjøre denne testingen underveis, i sprinten, med at vi hadde automatisert dette

Jan Mjelde Co-host

07:25

Så det du sier er, at gevinsten er at - det som veldig mange driver med i dag, at de har liksom ja, de har utviklingsperiode eller utviklingssprint, og så har de systemtest, og så har de akseptansetest, som er litt sånn banne i kjerka, hvis man driver smidigutvikling. Men det er veldig mange som er der fortsatt, ikke sant? Det du sier er at nå driver man bare og utvikler og testingen og akseptansetestingen, testingen av det man utvikler - gjøres integrert i utviklingen? Altså som man egentlig skal gjøre i smidigutvikling? Og så deployes det på enden av sprinten?

Kent-Erik Tøllefsen Guest

07:53

Det går kontinuerlig med jobber som er satt opp, og de kjører alt fra hver time til nattlig, litt avhengig av hvilke typer tester det er snakk om.

Jan Mjelde Co-host

08:05

Og da snakker jeg nesten sånn fra JIRA issue til JIRA issue, at da man deployer en sak og ikke venter på hele releasen?

Kent-Erik Tøllefsen Guest

08:11

du deployer en sak, dytter den ut, og så kjøres alle tester hver av seg selv hele røkla, og så vet du, at det fungerer eller så funker det ikke. 

Jan Mjelde Co-host

08:21

Og det er målet at man har så stor tiltro til kvaliteten, altså den grunnleggende kvaliteten, på grunn av at man har testdekning - automatisk testdekning i alle nivåene i testpyramiden, sånn at man vet at hvis man gjør bare en liten endring - hadde det vært noe alvorlig feil som dette trigger, så ville det lyst opp rødt i test-treet vårt, ikke sant? 

08:44

Og siden vi ikke gjør det, så deployer vi

Kent-Erik Tøllefsen Guest

08:46

Absolutt, og det er viktig å teste så nært utvikling som mulig at man har (red. Test-) suiter på forskjellige nivåer, at man har de i utvikling, man har utviklingstestmiljø, man har integrasjonstestmiljø og man har et systemintegrasjonstestmiljø hvor disse jobbene kjører. Og det koster deg veldig lite når du enten kan trigge det manuelt eller de går av seg selv, så du kan bare kjøre gjennom alt dette her og du kan fange opp feil veldig tidlig da.

Jan Mjelde Co-host

09:16

Hva koster det? 

Kent-Erik Tøllefsen Guest

09:17

Det koster deg ressurser, for det koster deg, det er ikke gratis, dette her. 

09:26

Det er ikke noe tvil om det. Du skal jo ha ressurser som lager dette. her følger det opp. Det skjer jo endringer, både i kode under test, som vi tester, eller som testenes tester, og det gjør også, at vi må gjøre endring i testkoden. Så det er jo ikke gratis.

Jan Mjelde Co-host

09:48

Her snakker vi litt sånn for vi hadde jo en heading her, som liksom sånn mange driver med automatisering og liksom får på plass noe. Men ofte så holder man  på en stund, og så stopper det ofte litt opp. Men det du snakker om her er noe som for det første, så stopper man ikke opp, man står og løper helt ut, og det koster - etter det jeg forstod fra innledningsvis, så koster det vesentlig mye mer enn sånne sporadiske initiativer for å få litt automatisk testtekning her eller der. 

Jan Mjelde Co-host

10:22

Her skal man hele testpyramiden opp fra bånd og opp, og det koster vesentlig, mye mer enn.

Kent-Erik Tøllefsen Guest

10:30

Men du henter jo inn veldig mye av dette her på at du slipper å ha disse testperiodene i etterkant så du finner feil tidligere, så koster det mye mindre når du ligger i produksjon. 

Jan Mjelde Co-host

10:41

Men det tar tid for at man kan hente ut den gevinsten men gevinsten er der?

Kent-Erik Tøllefsen Guest

10:46

I starten vil jeg si at det er en kostnad, men som du vil, på en måte tjene inn på sikt da.

Torbjørn Laukvik Host

Og hva må til for å ende opp på et sted hvor hele pyramiden er dekket?

10:57

Må det endres noe fundamentalt?

Kent-Erik Tøllefsen Guest

11:02

Ja, for det første. Så må jo, altså man må bestemme seg for at dette her er noe man ønsker å satse på ikke sant?

11:11

Og gjerne da organisasjonen eller prosjektet må bestemme seg for det her og at nå ønsker vi å satse på dette her og dette skal vi få til. Og man setter seg et mål på at dette her skal vi få til. Og sånn som det ble gjort der jeg var tidligere - der startet man jo, som sagt, med, at man kjørte en pilot på et par prosjekter, og så hadde man noen evalueringer rundt, hvordan dette her hadde fungert. Og man bestemte seg da for å etablere et sentralt testsenter, som hadde en teststrategi og fikk mandat til å si at sånn gjør vi det!

Kent-Erik Tøllefsen Guest

11:51

Ikke sant?

11:52

Det vil da si, at vi ønsker at vi skal automatisere, vi ønsker at vi skal ha sånn og sånn testdekning på de forskjellige nivåene, og vi skal ha automatisert ende-til-ende-test for å sjekke at hele verdikjeder henger sammen på tvers av prosjekter og organisasjoner. Og dette her er noe som alle nye prosjekter må ta stilling til. Og nå er det ikke nødvendigvis gitt sånn at de må gjøre det, for det kan jo være prosjekter som det ikke egner seg for, men de må i hvert fall ta stilling til det, og så må du komme med noen gode argumenter for å slippe å gjøre dette her da. 

Jan Mjelde Co-host

12:31

Men nå har vi snakket litt om et målbilde, som er et eller annet sånn glorious oppi fremtiden der, og så hadde vi kanskje lyst til å prøve å holde litt kortere episoder, slik at vi kanskje tar fortsettelsen i....?

Torbjørn Laukvik Host

12:45

Kanskje?
 Det er med på den - men jeg tenker også, vi må snakke litt om hva er det største fallgruvene? La oss ta det nå!
 Hva er det? 

Hvis du klarer å nevne opp det, og så ser vi hva tida bringer oss?
 I og med at du har et sånt fata morgana, et lysbilde et sted? Her skal vi!

Hva opplever du som det største problemet?

Du har mandat, du endrer organisasjonen, som er stort!

Hva er vanskeligst underveis?

Kent-Erik Tøllefsen Guest

13:14

Det er nok å på en måte få. En ting er, at du har et mandat til å gjøre noe. En annen ting er å få med seg resten av både team og kanskje prosjekt, som kanskje ikke er vant til å jobbe på den måten, for det betyr også, at de må endre litt på hvordan de tenker på test og hvordan man forholder seg til dette her. Så det er liksom å endre litt sånn mindset.

Jan Mjelde Co-host

13:40

Vi snakket litt om det før podcast, før sending, om dette med, for det er jo mandat, og så er det mandat. Og jeg forstod det som at du hadde opplevd eller jeg har selv også opplevd det å ha en teststrategi.

Ja, alle har det, men det er det, å faktisk gå for det og stå og løpe ut, for dette kommer til å koste, det har vi snakket om.

Det kommer til å koste vesentlig mer enn litt sånn klassiske sette på en testutvikler og sånn. Men det er faktisk det, som du sa, du startet som en enmannsteam, men dere utvidet og ble flere etterhvert og så at dette virket og man besluttet seg for å fortsette med det, ikke sant? 

14:24

Og det er vel der i hvert fall min erfaring at veldig mange stopper opp. Ja, nå har vi klapp på skulderen, nå har vi vært flinke, nå har vi fått litt automatisk testindikting, nå kan vi putte en check in the box og si til lederene at vi har gjort det, mens her stoppet de ikke opp. Og det er vel det jeg kanskje synes er litt interessant å høre dine perspektiver på hvorfor stoppet det ikke opp der du var?

Kent-Erik Tøllefsen Guest

14:47

Nei, det som jeg nevnte da, det hjelper ikke, å bare innføre dette her i et prosjekt og så er det bra der. Og da er vi tilbake til dette her med at hele organisasjonen, den må jo bestemme seg for det her og ville dette her. Og da, som jeg også nevnte tidligere her, at man får for eksempel et testcenter da, som sitter på dette mandatet og som får føringer til å bestemme, at denne teststrategien, som da inkluderer disse tingene, dette skal alle nye prosjekter ta stilling til på et eller annet vis. 

15:29

Og det er jo sånn, hvis de får det mandatet, så har de det mandatet, ikke sant? Og da er det det som gjelder, det viktige her også. 

Torbjørn Laukvik Host

15:37

Jeg tenker på, for det du snakker om nå er jo en større virksomhet som har åpenbart flere prosjekter og flere ting gående, og for en sånn virksomhet er det mye ver prosess ender seg og ordner stor risk For et lite startup. Så er ikke det så kostbart, da kan du gjøre det fra begynnelsen også. 

Kent-Erik Tøllefsen Guest

15:57

Og så har du vel kanskje et poeng av. Altså, det er vel en del å si. Hva slags virksomhet er, også kostnader og konsekvensene ved feil. Det er vel ikke. Vi snakker om en stor offentlig aktør som hadde veldig stor samfunns impact, bruker nynorsk ord, ikke sant? så det er jo litt med viktigheten. 

Jan Mjelde Co-host

16:22

Hvis det er en app for levering av ferske brød om morgenen, så kanskje ikke man legger like mye i nei det er jo to forskjellige ting der, og det er jo definitivt mest utfordrende å få til dette her i større organisasjoner og spesielt hvis det er noe som er etablert der fra før av, ikke sant? Da er det kanskje enda vanskeligere, og det kommer an på hvordan kodebasen og applikasjoner og infrastruktur er fra før av. Så det er i alle fall ikke sånn, at du kan sende inn en person som kan være hvor god som helst på dette her og si at, nå skal vi få til dette her. 

Kent-Erik Tøllefsen Guest

17:04

Det her må forankres, for det holder ikke med en rågod testutvikling, her må det gjøres konsertions på arkitektur og egentlig hele måten man utvikler på for å få dette til. 

Jan Mjelde Co-host

17:17

Ja, en testutvikling av seg selv kan ikke gjøre så veldig mye. Det her er jo en sammensetning av flere forskjellige roller og team, egentlig for å få til. 

Torbjørn Laukvik Host

17:25

Så bra. Jeg tenker det er veldig fin kapp på akkurat del 1. Jeg snakket om at for å få til å få, for å få til å få, for å få en god og en fundament, så må du endre virksomheten eller kulturen i selskapet. Og det gjøres ikke enkelt. Neste episode snakker vi litt om typisk feil ikke feil, men fallgruver som du har opplevd. Men bare for å ta det, hva var det første største problemet med å endre organisasjonen du opplevde eller du har opplevd? 

Jan Mjelde Co-host

18:00

Nå har jeg ikke vært sånn voldsomt detaljert involvert i det, men det er jo. Du endrer jo ikke hele organisasjonen sånn sett, men du endrer, hvordan de tenker på test. 

Torbjørn Laukvik Host

18:10

Ja, ikke sant, rett og slett. Og det her med litt sånn endringsledelse med pro size som er settefisert i hvordan får folk til å akseptere en ny endring? 

Jan Mjelde Co-host

18:20

Ja, det er ikke bare bare Nei, det er ikke vanskelig, og det for det første, da det som helt klart, at du må i hvert fall ha en ledelse som ønsker det. Det er nummer én, og så må du få med deg resten. Og det kan være utviklingsteam, for eksempel, fordi det påvirker dem, for en typisk testutvikler vil jo jobbe mot de, ikke sant? 

Torbjørn Laukvik Host

18:46

Mot de eller med de. 

Jan Mjelde Co-host

18:48

Ja, kanskje litt feilformulert, men de jobber jo med de. Ja, kanskje litt feil formulert, men de jobber jo med de. Da kan du si. 

Torbjørn Laukvik Host

18:54

Jeg bare tenkte på den gode si java som Espen Ekspo eller noe annet. Mot arbeidere, mot arbeidere, ja. 

Jan Mjelde Co-host

19:00

Ja, sant, nei, altså, det er noe som jeg har opplevd, at det har vært utfordrende i starten, men etter hvert som man begynte å se verdiene av det. så er det jo sånn at de vil jo ikke gjøre endringer uten å ha disse automatiserte testene til plass. 

Torbjørn Laukvik Host

19:20

Det jeg også har hørt at andre sier, fordelen med å ha en god automatisk tech-tekning er at man kan gjøre hva man vil og endre noe uten å bli bekymret for at ting faller sammen. 

Jan Mjelde Co-host

19:32

Man er trygg, utviklere er trygge, de kan endre på noe som skal ut i produksjon. Du vet at dette skal kjøre gjennom et x antall switter, som koster deg veldig lite å kjøre, for enten kjører de av seg selv eller så kan du bare. Er de grønne, så er det greit, veldig bra. 

Torbjørn Laukvik Host

19:53

Det var en god start til hvor vi er eller hvor vi skal. Og neste episode nå. Så kommer vi om et øyeblikk og litt til. Da snakker vi om hva du har opplevd som vanskelig med å gjøre det rent sånn. La oss si praktisk, det er fint. Hva har vært trøblete? Hva, hvis jeg har en sånn typisk notat til hva skal man gjøre rent praktisk for å klare det her? Veien mot mål. Veien mot mål, ja, fem-årsplanen som jeg snakket om for ikke så lenge siden. Det er viktig, og med det sier jeg takk for episode 1. Det var Torbjørn.