Skip to content

Få betalt for feil du ikke finner!

1. March 2012

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!

5 Comments leave one →
  1. 1. March 2012 12:48

    God tanke. Det er mye stigmatiserende rundt dette med rollen “tester” som øker skillet mellom utviklere og testere.

  2. 1. March 2012 12:07

    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!

    • 1. March 2012 13:28

      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!

    • Rune Larsen permalink*
      1. March 2012 21:20

      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!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 86 other followers

%d bloggers like this: