På dagens frokostmøte ble det ytret frustrasjon rundt testere i ett prosjekt som så det som sin oppgave å finne flest mulige feil i applikasjonen. Og det er greit nok det, om man har rigget prosjektet sitt på en måte som gjør at det er mulig å implementere feil i utgangspunktet. Kollegaen min refererte hele tiden til “oss” og “dem” når vi snakket om situasjonen. Noe som forsterket muren som stod mellom utviklere og testere i dette prosjektet.
Dette er fra et prosjekt med den klassiske designe-alt-utvikle-alt-teste-alt-produksjonsette-alt-tankegangen (også kjent som vannfall). Ett av problemene er jo selvsagt strategien som er valgt, men hovedproblemet til min stakkars kollega er at utvikling kommer før test i et slikt sekvensielt løp. Det må jo være bedre om utviklere og testere samarbeider i større grad, tenker jeg? Noe man kan dra nytte av helt uavhengig av metode og strategi.
Mange med test som fagfelt er ikke-tekniske personer som klikker seg gjennom brukerscenarioer og manuelt sjekker om systemet oppfører seg som forventet. Denne type verifisering er nødvendig, og teknologien i dag tillater større grad av automatisering av slike tester. Men ikke vær redd for å gjøre deg selv arbeidsledig ved å ha større grad av automatiserte funksjonelle regresjonstester. Sørg heller for å bruke tiden der det er vanskelig å automatisere. Vær med tidlig i utviklingsløpet og test så tidlig som mulig. Vær gjerne med å spesifisere funksjonaliteten. På denne måten kan du som tester bidra til å bygge kvaliteten inn fra starten av og ikke bare avdekke dårlig kvalitet i etterkant. Du kommer til å få en mer givende hverdag enn å melde feil på feil på feil inn i et eller annet ticket-system, for så og måtte re-teste dem igjen etter flere uker (kanskje måneder og år). Du kommer til å gjøre deg selv uvurderlig i markedet som den testeren som tilfører mest kvalitet til systemene du er med på å lage.
For at vi skal komme dit at de tradisjonelle test-diktatorene der ute kan omfavne tanken om å forhindre feil fremfor å finne feil, og på den måten jobbe mer sammen med utviklere har jeg et forslag:
Vi lønner testere etter hvor mange feil de ikke finner!
The Iterate Blog 
Interessant relatert diskusjon her:
https://groups.google.com/d/topic/lonely-coaches-sodality/WqOiSfkHyT8/discussion
God tanke. Det er mye stigmatiserende rundt dette med rollen “tester” som øker skillet mellom utviklere og testere.
Sålenge rollen heter “tester” og arbeidet defineres som “å teste” så vil nok insentivet være knyttet opp mot å avdekke feil – i etterkant.
Kanskje vi må gi rollen et nytt navn før vi kan gi det et nytt innhold. Det handler vel om at man skal bidra til å bygge inn kvalitet så tidlig som mulig. Quality architect? Quality developer?
Jeg tror også at denne eldre generasjonen med “testere” vil se positivt på å kunne bidra i utforming også (ikke bare få “dritten” i fanget).
Kjør debatt!
Interessant tema. Jeg er helt enig i at det handler om å bygge inn kvalitet så tidlig som mulig, men jeg tviler på at det hjelper å bytte navn. Testing vil alltid skje i etterkant av utvikling, enten det skjer i store eller i små steg. Vi bør derfor fokusere på å gjøre testingen, med det navnet faktisk har, til en positiv del av prosessen. Hvordan kan vi gjøre det? Jeg tror i hvert fall at kortere iterasjoner, eller kanskje helst løpende utvikling og testing uten bruk av iterasjoner i det hele tatt, vil bidra i positiv retning. Mindre inkrementer fører til tettere samarbeid mellom utviklerne og testerne, som igjen bidrar til å bedre forståelsen av viktigheten av hverandres arbeidsoppgaver. Målet bør jo være at testerne blir en del av teamet – på linje med utviklerne.
P.S.: Dersom jeg *måtte* finne et nytt navn på en tester, så hadde det nok blitt… … …utvikler!
Jo, det kan nok være vanskelig å omdefinere en så definert rolle som testeren allerede er. Jeg liker Quality Architect. Endel prosjekter og firma har en QA-rolle, eller QA-avdeling. I den grad det ikke bare er et nytt navn på den gamle test-funksjonen, så har man da mulightene på å se på kvalitet fra A til Å.
Det er heller ikke bare testerens ansvar å henge seg på tidlgere i prosessen, men et stort ansvar for å få dette til ligger hos de som rigger prosjektet fra starten av. Oppfordring: Hør på @JornHunskaar, og slutt å lage store bolker med trøbbel!