- Hva skal vi testere gjøre, nå som utviklere automatiserer alt selv?

- Skal vi i legge ned? spør Marianne Falkenås i Sparebank 1.

Marianne Falkenås mener det fortsatt er behov for testere, selv når utviklere skal oppdage mange av feilene selv. 📸: Privat / Sparebank 1
Marianne Falkenås mener det fortsatt er behov for testere, selv når utviklere skal oppdage mange av feilene selv. 📸: Privat / Sparebank 1 Vis mer

Er test på vei til å dø ut som egen profesjon? Kan vi i SpareBank 1 Utvikling legge ned testavdelingen, som flere andre innenfor bransjen har gjort?

Vi jobber jo innenfor et regulert domene og må forholde oss til IKT-forskriften og pålegg og føringer fra Finanstilsynet. Er det et mareritt vi på test skal inn i eller er det en spennende reise vi skal på?

Fagmiljøet for test og kvalitet i SpareBank 1 Utvikling har endret seg mye de siste årene. Endringsreisen er langt fra over, og vi har gradvis entret ukjent farvann.

Help, I need somebody med The Beatles beskriver kanskje en kjent følelse for flere innen testfaget nå om dagen? «Fail fast» er et uttrykk som vi på IT benytter. Vi tester ut hypoteser i raskt tempo, A/B-testing er normalen, og vi kan ta høyere risiko fordi vi oppdager våre egne feil raskt og retter dem så fort at kundekonsekvensen er ingen eller minimal.

Men — hvis vi oppdager feilene våre så raskt at kundene ikke merker det, kan vi ikke bare kjøre all koden rett i produksjon og tenke som Gloria Gaynor: Samma det, I will survive?

Welcome to my nightmare…

Vi på test kjenner litt på en følelse som sikkert inspirerte David Bowie med flere til å skrive Under pressure. Hva skal vi gjøre nå som utviklerne skal automatisere alt selv?

Er det virkelig slik at Bruce Springsteen hadde rett; My best was never good enough? Står vi på test igjen på stasjonen, mens resten av IT-bransjen suser av gårde?

Hvis du har lest boka Accelerate, stoppet du kanskje opp på avsnittet der det skrives at en av kjennetegnene til suksessfulle team er at det er utviklerne selv som skriver alle automatiske tester, inkludert akseptansetestene. Da er det virkelig Welcome to my nightmare for oss på test. Men er du glad i å lese og har litt utholdenhet (og samtidig litt optimistisk på vegne av test-profesjonen) så flyttet du blikket til neste avsnitt:

«None of this means that we should get rid of testers. Testers serve an essential role in the software delivery lifecycle, performing manual testing such as exploratory, usability, and acceptance testing, and helping to create and evolve suites of automated tests by working alongside developers.» Forsgren, Humble, Kim

Vi har da også testere i nesten alle teamene, og det er ikke ofte vi innrømmer det, men vi blir nok litt lykkelige av å Break stuff. Og fortsatt er det sånn at når det brenner på do i noen av prosjektene vi fortsatt kjører, så kommer IT-direktøren og ber om en erfaren testleder. Da er det han som synger Help, I need somebody!

Jeg har i en lang periode fått høre: «Vi trenger ikke flere testledere nå, Marianne». Så det er nok fortsatt behov for å jobbe med å øke forståelsen for at det er nødvendig med erfarne testledere tidlig i prosjektfasene. Og samtidig biter vi oss i tunga og forsøker å ikke si som Keith Urban I told you so, når noen kommer og ber om hjelp.

Konteksten avgjør

Testerne og testlederne i SpareBank 1 Utvikling, som designerne og utviklerne våre, trives best i tverrfaglige team der vi sammen jobber mot forretningsmessige mål. Hadde SpareBank1 Utvikling vært en musikal så kunne tittelmelodien vært We are family og Sister sledge hadde vært husbandet.

Samtidig har vi innsett at ikke alt lar seg løse i ett team, og at også test i SpareBank 1 er avhengig av hva slags system det er man utvikler på eller mot.

Også er vi jo veldig glad i API-er om dagen! Vi vil heller utvikle et API eller mot et API enn å forholde oss til gamle legacy-systemer. Da kan vi bestemme farta selv.

Gartner har en modell som kan brukes til å klassifisere systemene etter endringshastighet: Pacelayering. Den gir mye mening i en kontekstsbasert tilnærming til test. Samtidig må du ikke se deg blind på ulike «lag» i arkitekturen, fordi endringer skjer ofte i flere lag og systemer samtidig.

Må teamet forholde seg til lange verdikjeder og gamle legacysystemer, som endrer seg sjelden — men mye — når de først gjør det, må de ha en annen testprosess enn et team som stort sett kan iterere på frontend-koden sin og basere videreutviklingen kun på tommel opp eller tommel ned fra kundene.

Vi vil altså at det skal være fast and easy, i motsetning til hva Whitesnake prediker i Slow an’ easy. Slow hos oss i SpareBank 1 Utvikling betyr høy risiko og kompliserte releaser.

Vi har kommet til den erkjennelsen at test og kvalitetssikring av software er kontektsbasert. Når vi blir spurt om hva er teststrategien i SpareBank 1 Utvikling så er svaret enten «det kommer an på»:

Vis meg systemet ditt/forretningsmålene dine så skal jeg si deg hva strategien er

«Vis meg systemet ditt/forretningsmålene dine så skal jeg si deg hva strategien er.»

Eller kort oppsummert:

«Riktig kvalitet til rett tid.»

Tiden for å fokusere på å ha den beste testmetodikken beskrevet og dokumentert er forbi. Nå gjelder det å tenke at verden er dynamisk og vi dokumenterer det vi må.

Vi har fokus på automatisering og det neste på lista er automatisert sikkerhetstest. Og med «infrastructure as code» og «pipeline as code» blir vi ikke arbeidsløse med det første. Testavdelingen er definitivt Alive and kicking!

Kilder og inspirasjon:

Noen Twitter-folk det er verdt å følge:

  • Maaret Pyhäjärvi — @maaretp
  • Lisa Crispin — @lisacrispin
  • Michael Bolton — @michaelbolton
  • Ministry of testing — @ministryoftest

Favorittspillelisten for testere på Spotify - Alive and Kicking:

image: - Hva skal vi testere gjøre, nå som utviklere automatiserer alt selv?

.