I “gode gamle vannfallsdager” (sagt med knirkestemme) var typisk rollen som tester eller testleder en slags gatekeeper for kvalitet, som til og med hadde en egen fase rett før leveranse.
I en smidig verden liker vi å si at kvaliteten er hele teamets ansvar, trengs det da noen som har kvalitet og test som sitt hovedfokus? Jeg tror det, og for meg er dette tett knyttet til bevissthet om hva kvalitet egentlig er, og hvordan vi bruker fellesskapet i et autonomt team til å skape god nok kvalitet på det vi leverer.
Som konsulent er vi som oftest leid inn i et oppdrag som “tester” eller “testleder”. Når jeg presenterer meg sier jeg ofte noe generisk a la “jeg jobber med test”, men er det egentlig det jeg gjør?
Slik gjør du kjedelig testdata gøy, med Jsonnet
For meg er det viktigste å forstå mest mulig av hvordan systemet vi lager fungerer, gjøre gode målinger underveis i utviklingen, og ikke minst jobbe sammen med resten av teamet for at det vi lager skal fungere som forventet og fylle behovene for dem som skal bruke det. Dette innebærer mange aktiviteter som ikke nødvendigvis kan plasseres i båsen “test”. Min gode kollega Aud Jorun bruker å få litt rare blikk når hun sier at hun liker ikke å finne feil, er det ikke det en tester skal gjøre da?
Jeg mener det viktigste oppdraget vårt er å hjelpe teamet til å eie kvaliteten på det vi lager – og foreslår at vi skal begynne å presentere oss som kvalitetspådrivere!
Så hva driver vi med, egentlig? For å svare litt bedre på det må vi en sving innom kvalitetsbegrepet, hvordan test henger sammen med kvalitet og hvordan gode team fungerer som et lag.
Hva er nå egentlig kvalitet?
Min favorittdefinisjon av kvalitet er fra boka “An Introduction to General Systems Thinking”. Den sier at “Kvalitet er verdi for noen” , altså må vi hele tiden vurdere om det vi leverer gir riktig verdi til interessentene våre.
Vi må fokusere på å bygge kvalitet (i hele systemet), i tillegg til å monitorere og evaluere kvaliteten.
Kvalitet kan ikke testes inn, da er det allerede for seint!
Monitorere/teste
Testing er en aktivitet som innhenter informasjon (reaktivt). Dette må gjøres smart og gi rask tilbakemelding til de som trenger den. Poenget er å avdekke overraskelser så tidlig som mulig og testing må derfor være en kontinuerlig og transparent aktivitet. For at vi skal kunne handle som resultat av den informasjonen vi til enhver tid har må den deles og være tilgjengelig for flere!
Automatiser manuell testing: - Fant noe som passa perfekt
Hva gjør kvalitetspådrivere i våre prosjekter? Jo, i tillegg til å faktisk teste så jobber vi for at teamet skal ha gode retningslinjer. For eksempel:
- Automatiser det som skal gjentas og har forutsigbare resultater, gjerne basert på testpyramiden
- Bruk et kreativt hode (altså et menneske) til å teste det du trenger en hjerne til å utforske, utfordre og evaluere
- Bruk gjerne flere kreative hoder samtidig, de inspirerer og spiller hverandre gode, for eksempel ved par- eller mob-testing (samme konsept som mob-programmering, bare med testfokus)
Bygge
Bygg systemet slik at du får tilbakemeldinger raskt og hele tiden (proaktivt)! Dette gjelder helt fra en idé unnfanges til systemet er klart for leveranse. Slike tilbakemeldinger kan for eksempel komme fra felles beskrivelser av akseptansekriterier i form av brukerhistorier, monitorering/testing, BDD/TDD-praksis, Pull Requests og Continuous Integration.
Hva gjør vi som kvalitetspådrivere? Vi bidrar til å jobbe smart for å få korte tilbakemeldingssløyfer, for eksempel:
- Del opp oppgavene slik at du får avslørt de potensielt største problemene først
- Reduser unødvendigheter (for eksempel feil, overleveringer, eller langvarig venting på testdata)
- Fokuser på testbarhet hele tiden slik at det er enklere å få den tilbakemeldingen man trenger så tidlig som mulig (for eksempel noe så konkret som å være nøye med navngiving av DOM-elementer for å gjøre det lettere å automatisere tester)
- Gjør bruk av all kompetansen som ligger i teamet ved å være forkjemper for samarbeid og synlighet (for eksempel parprogrammering, Tres amigos - møter for avklaringer, felles Kick-off på nye oppgaver)
Sparebank 1 deler sitt eget mock-verktøy, Troxy
Autonome team og samhandling
God samhandling er selve kjernen i en god og effektiv arbeidsdag for meg.
Klarer vi å utnytte den verdien det ligger i å sette sammen autonome og tverrfaglige team? De beste teamene har til sammen kompetansen som trengs for å løse oppgaven, og jobber smartere sammen.
Det vil si at de jobber som et “ishockeylag“, for å bruke en analogi fra Kristin. “Vi lager produktet sammen, med hver våre ferdigheter.”
T-kompetanse
Å få på plass et “ishockeylag” for å lage et system er enklere dersom teammedlemmene har forståelse for hverandres spesialdisipliner, og kan ta i et tak utenfor sin hoveddisiplin når det trengs.
På samme måte som utviklere ofte har T-kompetanse ved at de kan mye om kundens behov, testing og drift i tillegg til å være systemutviklere, er testere ofte gode generalister i tillegg til å ha en fordypning i kvalitet og test. Mange kvalitetspådrivere har utviklerbakgrunn slik at vi kan lese kode, utvide eksisterende testkode, eller diskutere tekniske utfordringer på “utviklersk”.
- Hva skal vi testere gjøre, nå som utviklere automatiserer alt selv?
Mange er opptatt av å se kundens perspektiv: hvordan vil dette systemet fungere i hverdagen for en bruker og hvordan får vi beskrevet det perspektivet på en måte slik at teamet forstår det? Mange er opptatt av at test skal være effektivt, og foreslår automatisering av gjentagende oppgaver eller får på plass lett tilgjengelige testdata. Med bakgrunn i testfaget har vi et godt utgangspunkt for å bidra med nysgjerrighet og spørsmålstilling og utfordre det som er usagt.
Komplekst eller enkelt prosjekt?
Noen prosjekter kan være så forutsigbare og gjenkjennelige at det er mulig å lage den riktige løsningen effektivt ut fra en beskrivelse. Problemet er bare at de aller fleste utviklingsprosjekter ikke faller inn under denne kategorien.
Sannsynligheten er stor for at prosjektet du jobber i er uforutsigbart og komplekst (uordnet), og da er det lurt å vurdere hva som kan gjøres for å redusere risikoen.
Hypotesedrevne prosjekter der prosessen kan beskrives som (Bygge - Måle - Lære) kan ha spesielt godt utbytte av å ha en kvalitetspådriver om bord, det er jo akkurat dette vi er gode på!
Slik skriver de testene sine i Sparebank 1
Rollen som kvalitetspådriver
Hvordan er det med deg, har du tenkt at du trenger en tester/testleder/testcoach i ditt team? Eller at det hadde vært fint med noen som har kvalitet som sitt viktigste fokus i utviklingen av det nyeste nye?
Da vil jeg anbefale deg å få tak i en kvalitetspådriver med T-kompetanse og ambisjon om å spille på verdens beste utviklings-ishockeylag! Kanskje har du til og med en på ditt team nå, det er bare det at rollen heter noe annet?
Neste gang jeg blir spurt om hvilken rolle jeg har og hva jeg gjør, skal i hvert fall jeg si at jeg er en kvalitetspådriver - jeg hjelper til for at hele teamet skal eie kvaliteten på det vi lager!