Automatiserte tester er viktig - gode krav er en nødvendighet

Vi bruker store ressurser og kostbare verktøy til å finne feil i systemene våre. Vi forsøker å lage automatiske tester, ha oversikt over kodedekning og testdekning, vi lager gode rutiner for eksplorativ test osv. Til tross for bedre verifisering og mer kontroll, oppdager vi stadig feil i systemene. Jeg hører stadig om prosjekter hvor man har innført testautomatisering, men hvor man fortsatt sliter med mange feil og misfornøyde sluttbrukere. 

Viktigheten av krav

Testautomatisering utført på enhets-, integrasjons- eller GUI-nivå må utføres korrekt i henhold til krav. Dette krever ikke bare at kravene er beskrevet riktig, men også blir oppfattet korrekt. Får å få til dette, krever det kvalitetsikring over hele linjen. Jeg har selv vært med på at krav er beskrevet korrekt for et gitt formål, utført i henhold til bestilling men hvor resultatet gir nye A-feil på grunn av manglende virksomhetsforståelse. Andre ganger kan kravene bli endret på underveis etter muntlig diskusjon og uten at spesifikasjonen er blitt oppdatert.

Forståelsen

I et møte med en kunde nylig, kjørte jeg en liten test. Møtedeltakerne bestod av personer som har ansvaret for å ta imot og kvalitetssikre nye bestillinger fra sluttbrukere før disse oversendes til utviklingsteamet. Disse fikk to spørsmål:

  • Hvor skapes feilen?
  • Hvordan kan man unngå at feilen skapes?

Post-it lapper

Deltakerne fikk lov til å bruke noen minutter på å skrive svarene ned på post-it lapper. Svarene jeg fikk på spørsmålene overasket meg litt, samtidig som de forklarte hvorfor vi har så mange feil som vi har i våre systemer. 

Noen av møtedeltakerne mente at utvikleren eller utviklingsprosessen var årsaken til problemet og at løsningen kunne være kode gjennomgang og sjekklister.

Tja, ikke helt korrekt altså!

Andre møtedeltakere la til grunn min rolle som testleder før de besvarte spørsmålene. En møtedeltaker svarte at feil kunne oppstå på grunn av manglende test fra utviklingsteam og for få negative tester. Vedkommende traff ikke blinken heller, men var inne på noe, nemlig mer involvering av brukerne – også kjent som "fagsiden".

Post-it lapper

Finnes det en fasit på disse spørsmålene? Nei, det gjør det ikke, men det finnes likevel svar som er bedre enn eksemplene illustert ovenfor.

Hvor skapes feilen?

Feilen skapes i hodet til en person, og så kan den forplante seg videre og "forgifte" systemet. Hvor i verdikjeden denne personen sitter avgjør hvor dyrt det vil bli å korrigere feilen.

For noen år siden ønsket saksbehandlings enheten hos en kunde at man fikk lagt inn et felt for opphørt dato på kontaktkortet for virksomheter i et gitt system. Et lignende felt fantes fra før på kontaktkortet til virksomhetene. Noen tok en beslutning om at dette feltet skulle brukes til å registrere opphør. En bestilling ble opprettet, det ble laget en god testbeskrivelse til denne saken og bestillingen ble sendt til utviklingsavdelingen. Utvikleren som utførte oppgave flyttet feltet slik at det ble lettere tilgjengelig for flere parter. Noen måneder senere ble det oppdaget feil i systemet knyttet til dette feltet. Feilen skyldtes at det eksisterte en del virksomheter som hadde opphørt dato fylt inn men som ikke var opphørte i Enhetsregisteret.

Var kravet implementert feil? Nei, systemet gjorde nøyaktig det man hadde bedt om. Feltet ble oppdatert etter ukentlig vask mot Enhetsregisteret og man vasket kun virksomheter som ikke hadde denne verdien satt. Hvor kom da opphørsdatoene fra? Jo, en annen enhet i denne organisasjonen hadde brukt dette feltet for å merke virksomheter som hadde meldt seg ut av forsikringsordningen. Ingen fra denne enheten hadde blitt involvert i utformingen av kravet. Det burde egentlig ha ringt noen bjeller i flere ledd når man tok i bruk et eksisterende felt og ga det et nytt formål, men dette skjedde ikke. Rettelsen ble en dyr affære, og krevde blant annet en del manuell arbeid. Arbeid som ikke hadde vært nødvendig hvis dette for eksempel hadde blitt oppdaget under utformingen av kravet eller før bestillingen hadde blitt oversendt til utviklingsteamet.

Hadde testautmatisering funnet denne feilen? Vel, jeg tror ikke det. En automatisk test for dette tilfellet ville vært laget med samme mengden kunnskap som førte til at man gjorde denne blemmen.

For å produsere gode automatisere tester, bør man ha kunnskap om blant annet hva som skal testes, hvorfor det skal testes og hvordan dette skal testes.

Nivået av kunnskap om et fagfelt og systemet hos de som produserer testene er avgjørende for nytten av de automatiske testene. Dette gjelder særlig GUI automatiske tester hvor man tester systemet i sin helhet. Enhetstester og integrasjonstester er meget enklere å utvikle da man kan fokusere på en mindre del av systemet.

Hvordan kan man unngå at feilen skapes?

Her mener jeg at svaret er at man begynner å snakke mer sammen, gjerne på tvers av for eksempel fagområder, avdelinger, enheter og brukergrupper.

Veldig sjeldent har man prosjektetdeltakere som kan alt og vet alt, også kalt arkitekter, som kan løsningen både teknisk og funksjonelt. Særlig i slike tilfeller må vi bli flinkere med å snakke sammen. Hadde for eksempel saksbehandlingsenheten stilt spørsmålet: "Kan vi bruke dette feltet til å melde opphør" til økonomi/forsikringsenheten hadde man fått et svar som hadde resultert i at man slapp å få feilene som vi fikk. Så enkelt!

Vi må snakke mer sammen

Men å snakke sammen er ikke noe som kommer av seg selv. Man må bruke tid og ressurser på å få til et godt samarbeid. Feilene kan også oppstå etter at man har levert en perfekt bestilling til utviklingsteamet. Utvikleren kan misforstå behovet. Her kommer sånne som meg inn. Enten som tester eller testleder på utviklingssiden eller kundesiden. Det er vår oppgave å forstå behovet korrekt, og verifisere at dette er utført korrekt i samarbeid med bestiller. Etter å ha forstått behovet korrekt, det er først da vi bør lage automatiske tester. Automatiske tester som tester en funksjonalitet på feil måte har negativ verdi og er en kostnad! Vi som lager automatiske tester må lære oss å snakke med folket og ha et overblikk som ingen andre egentlig har.

Hev blikket - se sammenhengen

Mange av oss har i vår barndom vært borti oppgaver hvor man skulle finne et viss antall feil mellom to nesten identiske bilder. For å finne disse feilene var vi nødt til å heve blikket og se på hele bildet. Dette er denne lærdommen vi må fokusere på når vi utfører og automatiserer test. Automatiserer du på GUI-nivå med fokus kun på en del av problemet, skaper du bare et nytt problem.

Finn feil

Jobber du med testing?  Se våre ledige stillinger

 

Del på sosiale medier: