Tenåring med identitetskrise
Marianne Wiik Øberg
03.10.2019
Test og Testledelse

Marianne har de siste årene bygd opp og ledet et av norges største testmiljø innen systemutvikling.

I denne bloggposten skriver hun om hva som skjer med testrollene i dagens systemutviklingsprosjekter.

 

Bloggposten ble første gang publisert i Computerworld nr. 7 - September 2019.

Hva skjer med testrollene i systemutviklingsprosjekter?
 

Små autonome team er i vinden. Teamet er selv ansvarlig for produktet, fra behov til krav, inkludert kvalitet. Samtidig har ny teknologi banet vei for en mer effektiv og automatisert testing.

 

"Er det rom for testledere og rene testspesialister i fremtidens prosjekter?"

 

Som leder og testentusiast har jeg både stilt og fått spørsmålet om hva som skjer med testrollene i denne nye verden? Er det rom for testledere og rene testspesialister i fremtidens prosjekter?

 

Testfaget er en relativ ung profesjon i den norske systemutviklingshistorien. Jo visst testet man på 80- og 90- tallet. Men det virkelig store fotfestet som profesjon, fikk test utover 2000- tallet. Den første ISTQB-sertifiseringen kom for eksempel i 2002.  Altså fortsatt som en tenåring å regne.

 

Gjennom livet har testfaget utviklet seg. Fra lange testfaser og manuelle tester i tunge testverktøy, der vi stort sett lekte alene etter at de andre i prosjektet hadde gjort sitt.

 

"Nå er vi i en posisjon der flere og flere unnlater å invitere testere med i teamene"

 

Gjennom smidigrevolusjonen der vi endelig fikk leke sammen med de andre barna (utviklerne). Til kontinuerlige leveranse der vi vi også fikk leke med lekene til de andre, og vi selv også fikk bruke kodebasen gjennom automatiserte tester.

 

Nå er vi i en posisjon der flere og flere unnlater å invitere testere med i teamene. Utviklerne og fagspesialistene mener de kan teste selv.

 

"Alle med interesse og IT-kompetanse kan sette seg inn i og lære seg testfaget, og utføre det på en utmerket måte"

 

Men kan eller bør de det?

 

Det er klart de kan! Alle med interesse og IT-kompetanse kan sette seg inn i og lære seg testfaget, og utføre det på en utmerket måte. Om vedkommende er en person med tittel tester, utvikler eller produkteier spiller ingen rolle.

 

Testfaget er imidlertid likefullt et fag og har en metodikk. Uavhengig om man tenker fullautomatisering eller kun funksjonell testing, må det ligge en strategi og plan bak, hvis testingen skal gjennomføres med et godt resultat.

 

Dette krever kunnskap.

 

For å forstå dette, og for å forklare noe av kompleksiteten, følger under en forenklet oversikt over metodikken.

 

"Det viktige, uavhengig av prosjekt, er at man har et bevisst forhold til hvilke krav man har til systemet, og at man har stålkontroll på hva som testes når"

 

Testplanlegging handler om å lage en mest mulig effektiv plan for din testing, der ønsket resultat er å minimere sannsynligheten for feil.

 

Testing handler om å gjennomføre testingen så effektivt og riktig som mulig, enten det er manuelt eller teknisk (for eksempel gjennom automatisering).

 

For å strukturere opp dette har man i metodeverket til ISQTB blant annet:

 

  • 4 ulike testnivåer, som sier noe om hvor i koden man tester. På laveste nivå har vi de bittesmå enhetene i kodebasen, til sammenkoblinger av moduler, sammenkobling av systemer, til det komplette systemet, som sees på som høyeste nivå.
  • 7 ulike egenskaper man kan teste. Egenskaper beskriver hva vi ønsker å teste. Dette inkluderer ytelse, belastning, stress, brukbarhet, vedlikeholdbarhet, pålitelighet og portabilitetstesting.
  • 13 ulike måter (testteknikker) å teste på, handler om hvordan man tester, alt ettersom hva som er mest effektivt for å oppnå ønsket resultat.
     

Enkel kombinatorikk gir 4*7*13 = 364 ulike måter man kan teste de ulike egenskaper i de ulike nivåene på. For hver enkelt lille modul du lager. Det er altså ikke noe “one size fits all” når det kommer til teststrategi

 

Hva som passer ditt system best, avhenger av kompleksitet på løsning, risikovilje fra produkteier og hvilke krav man har til programvaren. Det viktige, uavhengig av prosjekt, er at man har et bevisst forhold til hvilke krav man har til systemet, og at man har stålkontroll på hva som testes når.

 

"Som team må man ha å tydelige føringer på hvem som gjør hva og når knyttet til testing"

 

Det er umulig å teste alt, så prioritering av tester er et veldig viktig. De som tester, må kjenne til hvordan dette skal gjøres. Noen må ha en strategi for hva som skal testes når, og de som tester må vite hvordan testingen gjennomføres.

 

Som team må man ha å tydelige føringer på hvem som gjør hva og når knyttet til testing. Dette fordi ting skjer samtidig og ting skjer fort. Men med dagens takt innen utvikling med kontinuerligere leveranser og automatiserte tester, blir dette stadig viktigere. Grunnpilarene i metodikken består, selv om verden rundt forandrer seg.

 

Så jeg sier ja takk til at utviklere skriver automatiserte tester i takt med utvikling av programvaren. Jeg sier ja takk til at fagsiden går inn og tester at løsningene både er brukervennlige og dekker alle vanlige og sære bruksmønster funksjonelt.

 

Økt kunnskap til testfaget for alle som jobber med systemutvikling, vil være med å heve kvaliteten på det vi leverer.

 

"Som testleder inviterer jeg meg selv med på vorspiel, men jeg trenger ikke være med på hele festen"

 

Som testleder har jeg faktisk gjort min jobb, hvis strategi, prosesser og retningslinjer for prosjektet er satt, og andre på prosjektet deretter tar eierskap for å holde i testingen videre. Om det er testere eller utviklere er ikke avgjørende, så lenge de vet hva de gjør og kan faget. Som testleder inviterer jeg meg selv med på vorspiel, men jeg trenger ikke være med på hele festen.

 

Og på samme måte som andre fagområder må lære seg testfaget for å kunne bistå med test, må vi som brenner for testfaget våre åpne for å få innblikk i nye fagområder for å fylle nye roller. Men at testkompetanse er en etterspurt og viktig ressurs i dagens samfunn, er det ingen tvil om. Det vil det også være i uoverskuelig fremtid.

Del denne artikkelen:
Marianne Wiik Øberg
Konsulentleder og Testleder