Mellom Kode og Kontroll: Samspill for Suksess

Jeg er gammel nok til å ha vært med på prosjekter utviklet etter fossefalls metoden hvor man skrev lange dokumenter, delegerte testcaser og hadde lange perioder med test. Jeg er erfaren nok til å ha endret rollen min til å fokusere mer mot analysering, kvalitetssikring av krav og automatisering av test knyttet til funksjonelle og ikke funksjonelle krav som ytelse, sikkerhet og universell utforming. I tillegg har jeg med årene også blitt mer interessert i logger enn tidligere.

Alt dette skyldtes endringer i utviklingsmetodikken, fra fossefall til smidig. Jeg er veldig fornøyd med akkurat det, for hvis ikke det hadde skjedd endringer, hadde jeg nok ikke vært en del av dette fagfeltet særlig lenge. Jeg tror tiden fremover kommer til å bli kjempespennende, selv også for oss som har vårt hovedfokus på test og kvalitet.

Men alt er ikke helt perfekt i dag. Jeg har hørt at kvalitet er teamets ansvar. Dette teamet har ofte masse automatiske tester, det må vel holde?! Nei. Teamet må holdes fokusert på kvalitet. En person må være der for å minne på, veilede og stille krav til hele teamet. Ellers faller korthus før eller siden. Vi må bli bedre. Vi kan ikke tro at automatiske tester er nok. Det må være noen som “tester” testene også. Testene må lages riktig.

Utvikler misforståelser og testressursens verdifulle bidrag

Jeg jobber ofte tett på utviklingsteam og får en sjelden gang mulighet til å bidra med å gi råd om hvordan de skal jobbe testdrevet eller hvordan de skal skrive tester for en spesifikk brukerhistorie. Beklageligvis skjer ikke dette alltid. Mulig det er jeg som misforstår, men veldig ofte tror utviklere at vi som jobber med test, ikke forstår det de driver med. De forstår at vi er flinke til å finne feil. Men de forstår ikke at vi også er eksperter på å avverge feil eller at vi har kontroll på hvor risikoen for å få feil er størst. Mange av dem forstår ikke at mange av oss har en bakgrunn fra utvikling og kan lese kode. Når utviklingsteamet ser på testressursen som en mindre teknisk eller også en mindre kompetent person, blir det et naturlig skille mellom enhetsttestene som utvikles og testene på de andre nivåene i testtrekanten.

Jeg har sittet i prosjekt hvor jeg inkluderes mer i utviklingsløpet. Jeg har verifisert at enhetstestene som er laget er riktig. I slike prosjekter kan jeg også være heldig nok til å få tid til å jobbe med automatisering av test på integrasjonsnivå og GUI nivå. Da lager jeg ikke tester som tester det samme som ble testet på enhetstestnivå. Ingen tjener på at testkodebasen består av repetitive tester.

Men nå har jeg og en litt annerledes bakgrunn, ikke alle testressurser har utviklerbakgrunn. Hva gjør man da? Vi må involveres mer i kvalitetssikring av krav, hvis vi ikke allerede gjør det. Jeg var på et prosjekt en gang hvor vi hadde et møte med utvikler, bestiller og kvalitetsansvarlig i forkant av utvikling av en gitt brukerhistorie. I møtet diskuterte vi hva som var akseptansekriterier til brukerhistorien. Disse kriteriene danner ofte grunnlaget for enhetstestene når funksjonaliteten ble implementert. I etterkant av implementering kunne de mest tekniske testressursene gå inn og sjekke koden og enhetstestene, en ekstra verifisering. Dette ga oss på test informasjon om hva som var testet på laveste nivå og vi kunne dermed ta med denne informasjonen til integrasjonstestansvarlige, og få opprettet integrasjonstester basert på informasjonen vi hadde. Videre ble de automatiske testene produsert på en slik måte at vi prøvde å teste noe annet enn det som ble testet på enhetstest- og integrasjonstestnivå.

Kodefokus vs. Helhetstenkning

Ofte møter jeg utviklere som sier at de ønsker å lære seg å skrive bedre tester. Mitt råd er å ta kontakt med testressursen i teamet. Utviklere er ofte meget fokusert på den ene brukerhistorien de har fått ansvaret for å implementere. Dette vil påvirke hva slags enhetstester som blir laget. Når vi leverer en funksjonalitet må vi huske på at den ofte er en del av et større system. Den gjennomsnittlige utvikleren har ikke kjennskap eller mulighet til å fokusere på alle aspekter, som for eksempel hva skjer i forkant av at funksjonaliteten tas i bruk eller i etterkant. De har lite eller ingen kunnskaper om risikoen “ytre” faktorer som for eksempel annen funksjonalitet, miljø og data kan ha på funksjonaliteten som skal leveres. Så testen som utvikles, blir nok ikke den beste.

Testutviklingen som blir gjort på en dårlig måte vil gi mer og mer feil, som fører til tidspress, som igjen fører til at utvikler heller vil fokusere på å gjøre seg ferdig med å levere funksjonalitet enn å teste at funksjonaliteten er grundig testet. Man havner i en dårlig sirkel.

Hva er løsningen da?

Sitter du i et prosjekt hvor teamet har ansvaret for kvaliteten, og kvaliteten ikke er helt på topp. Sørg for å få tak i en ressurs som kan samspille og håndtere alle nivåer i testtrekanten for en helhetlig tilnærming til testing.

Ressursene dere velger skal ikke bare sørge for en helhetlig og effektiv testautomatisering på alle nivåer, men også fungere som en veileder mot de som spesifiserer krav og de som utvikler nye funksjoner. Denne ressursen bør også kunne følge med på at kodegjennomgangen utføres i henhold til organisasjonen krav og få lagt inn at enhetstester skal bli produsert, og at enhetstester som ikke lenger har livets rett blir fjernet. Ressursen skal ta med seg kunnskapen videre oppover til integrasjonstestingen og testingen på GUI nivå. Denne ressursen må også veilede fagteamet med å kunne teste mer eksperimentelt, for vi klarer nok ikke få en testdekning på 100% uansett hva vi gjør. Ressursen dere velger bør på kort tid sørge for målbar kvalitetsforbedring. Noen kaller en slik ressurs for testleder eller kvalitetsleder. Andre kaller vedkommende for testutvikler/testansvarlig. Alle team trenger en slik ressurs.

Enig eller uenig? Ta gjerne kontakt med oss i Systek hvis du har innspill til innlegget eller ønsker å vite hva våre testeksperter kan tilby dere.

Besøk oss på https://systek.no/