Testavdelingen — Alive and Kicking eller Welcome to my nightmare?
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 legacysystemer. 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
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:
Accelerate — Nicole Forsgren, Jez Humble, Gene Kim
Thoughtworks Technology Radar 2020
Pace layering Application Strategy — Gartner
Top ti software testing sanger
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: