Testautomatisering og kvalitetskontroll

I 2015 stod jeg i et mindre rom på Odin konferansen og snakket om hvordan TestComplete kunne brukes til å lage automatiske tester. Det er nesten ti år siden.

De siste par årene har Cypress og Playwright blitt mer og mer populære blant de som automatiserer GUI tester. Det er flott, jeg ønsker meg mer testautomatisering. Ingen ønsker å gjøre repeterende oppgaver, selv ikke vi på test heller ;)

Men er det sånn at alle kan sette i gang med å automatisere test? Kan de bare bruke testcase som grunnlag? Egen magefølelse? Risikobasert automatisering? Kanskje vi også kan få med litt AI som hjelper til å finne områder som bør automatiseres basert på kodeendringer og manglende enhetstester? Jeg har mange flere spørsmål, men det holder for nå.

Testautomatisering med med kode og kodegjennomgang?

Jeg lærte meg å programmere på universitetet, og vi ble lært opp til å ha god kodestruktur og følge kodestandarder. Vi lærte oss å skrive koden på en strukturert og vedlikeholdbar måte. Da jeg begynte å jobbe som utvikler kom TDD-bølgen (TDD = testdrevet development) og vi skrev enhetstester til den store gullmedaljen. Med scrum og svimlanes i Jira ble koden nøye kontrollert med utviklertest og kodegjennomgang.

Men har alle fokus på dette når de utvikler tester? Enhets- og integrasjonstestene blir kvalitetssikret gjennom kodegjennomgangen. Men hva med GUI tester?

Jeg ser mange som bare setter i gang og automatisere. Mange som er nye til testautomatiseringsverktøyene, skriver eller tar opp lange tester i en “pakke”. Pakken er uten struktur og uten noen særlig mulighet for gjenbruk. Koden sendes til versjonshåndteringssystemer og kjøres i systemtestmiljøer og akseptansetestmiljø, uten at noen i det hele tatt tenker på kvalitetskontroll.

Tenke seg til at noen skulle finne på å kontrollere noe vi på test har laget :D

Heldigvis er det ikke slik alle steder. Jeg spurte kollegaene mine i Systek om hva som skjer med automatiske tester i prosjektene de jobber med. Mange kjører kodegjennomgang og har god struktur i testkoden også.

For en stund siden var jeg på Frøya 2024 hvor noen påpekte at selv om vi tror at utviklerne er flinke til å lage tester, er det nok dessverre slik at noen av disse skriver enhetstester kun for å få koden sin godkjent. Noe som i enkelte tilfeller resulterer i dårlige tester. Når jeg hører sånt blir jeg bekymret. Og jeg blir ikke noe mindre bekymret når det å skrive enhetstester beskrives som en “kjedelig” oppgave.

Da jeg jobbet med foredraget jeg selv holdt på Frøya 2024, kom jeg over ordtaket:

Hvis man ikke kjenner fortiden, forstår man ikke nåtiden og egner seg ikke til å forme fremtiden. (Simone Weil)

Ganske fint ordtak som jeg føler også kan legge føringer for hvordan vi bør jobbe med testautomatisering. Jeg tror at hvis vi ikke kjenner til testing eller programmering (ikke kjenne fortiden), kan vi egentlig ikke utvikle gode tester (forstå nåtiden), og i hvert fall ikke utvikle tester som kommer til å overleve lenge (forme fremtiden). Dette gjelder automatiske tester laget både med og uten kode. Det betyr også at vi ikke bør sette testautomatisering ut til en ren utvikler og tro at det holder. For å ta gode avgjørelser, må vi kunne vurdere flere perspektiv (som jeg nylig lærte på Oda Inspiration day). Når en utvikler bruker utvikler-perspektivet, blir det dessverre ikke laget gode nok tester. Når en testressurs recorder en test og kun bruker test-perspektivet, blir det heller ikke en god test. Det er kreftene som ligger i ulike perspektiv som får frem det virkelige gullet. Derfor må vi bruke folk som har erfaring og kjennskap til begge områdene. Så har vi de som ønsker at deres ansatte skal bli testutviklere. For å bli en god testutvikler trenger du kompetanse innenfor både test og utvikling, og denne kompetansen må videreutvikles med ny læring fra begge fagfeltene. Her er det derfor viktig å delta på kurs og konferanse hvor du kan kombinere eller fylle på kunnskap om områdene hver for seg.

Så har vi et håp om at kan AI mulig kan hjelpe oss. Vil den skrive gode tester, kanskje men…

Min flinke kollega Hager Debech vil snakke om hvordan kriser endrer vår brukeradferd på Odin 2024. Det får meg til å lure på hvordan vi kan lage automatisert tester som tester brukeradferd under stress? Næh, kriser og menneskets brukeradferd er nok ikke det første AI blir ekspert på.. Vi har med andre ord nok å gjøre, også i de kommende årene. :)

Ønsker du å høre om Systek og hvordan det er å være konsulent hos oss, ta gjerne kontakt med meg, eller besøk www.systek.no