Å vurdere Test Automation Results riktig

En regresjonstest kan om morgenen ende med 98 prosent vellykkede tilfeller og likevel ikke være gode nyheter. Kanskje er den mislykkede testen akkurat innloggingen til en storkunde. Kanskje ble 40 tester hoppet over fordi testmiljøet ikke var tilgjengelig. Eller kjøringen var grønn, men sjekket bare om knapper finnes, ikke om en ordre faktisk lagres, en følgeseddel genereres og lageret justeres riktig. Test automation results er ingen kvalitetspåstand så lenge konteksten deres mangler.

For QA-ledelse, utvikling og fagavdelinger ligger det egentlige arbeidet derfor ikke bare i å automatisere tester. Avgjørende er å tilrettelegge resultatene slik at pålitelige beslutninger oppstår: kan en utgivelse rulles ut? Må en feil håndteres umiddelbart? Er feilen ny, gjentatt eller bare et problem i testmiljøet? Og finnes det bevis som også en fagavdeling uten testkode kan følge?

Hva Test Automation Results egentlig sier

Det enkleste nøkkeltallet lyder: bestått eller ikke bestått. Det er nyttig, men sjelden tilstrekkelig. En høy suksessandel kan skape tillit hvis testene dekker kritiske flyter, testdataene er plausible og miljøet ligner den senere driften. Mangler en av disse faktorene, forblir tallet først og fremst et signal om at en automatisert kjøring ble utført.

Ved forretningskritiske applikasjoner veier andre spørsmål tyngre. I en lagerløsning er ikke hvert skjermbilde like viktig. En visningsfeil i en intern hjelpetekst kan vente. En feil som bokfører feil mengde ved varemottak eller genererer en forsendelsesetikett uten mottakeradresse, kan ikke det. Gode testresultater veier derfor risikoer i stedet for å behandle alle tilfeller likt.

Heller ikke en mislykket test er automatisk en produktfeil. Den kan utløses av utløpt påloggingsinformasjon, en sperret testrolle, utilgjengelige grensesnitt, endrede testdata eller et tregt miljø. Den som ikke skiller disse årsakene, produserer støy. Teamet bruker da tid på falske alarmer mens ekte feil forsvinner blant røde statusmeldinger.

Fire statustyper i stedet for én rød liste

I praksis har en tydelig inndeling vist seg å fungere: faglig feil, teknisk testfeil, miljøproblem og forventet endring. En faglig feil betyr at applikasjonen bryter et definert krav. En teknisk testfeil peker heller mot selve testen, for eksempel en selektor som ikke lenger passer etter et bevisst endret grensesnitt.

Et miljøproblem foreligger når for eksempel et testsystem eller et tilkoblet grensesnitt ikke er tilgjengelig. Forventede endringer oppstår når en prosess er bevisst tilpasset, men automatiseringen fortsatt kontrollerer den gamle måltilstanden. Disse kategoriene forhindrer ikke enhver diskusjon. Men de sørger for at diskusjonen begynner på riktig punkt.

Fra testkjøringer til beslutningsklare rapporter

En brukbar rapport svarer ikke bare på at noe mislyktes, men hva som skjedde, hvor alvorlig det er og om feilen virker reproduserbar. Det krever mer enn en liste med testnavn og tidsstempler.

Til hver relevant kjøring hører den kontrollerte builden, testmiljøet, rollen som ble brukt, sentrale testdata samt start- og sluttid. Særlig ved Windows-skrivebordsapplikasjoner eller komplekse nettplattformer trengs denne informasjonen for å avgrense forskjeller. En feil som bare oppstår under en begrenset lagerrolle, er noe annet enn en feil som blokkerer hver pålogging.

Meningsfulle resultater inneholder dessuten sporbare bevis: skjermbilder, innspilte trinn, feilmeldinger og ved behov tekniske logger. Et skjermbilde alene kan imidlertid lure. Det viser et øyeblikk, ikke årsaken. Kombinasjonen av trinnrekkefølge, synlig tilstand og forventet reaksjon er betydelig mer nyttig.

KI-støttede systemer kan omforme disse bevisene til forståelige vurderinger. Hos COCO for eksempel kjøres tester på en egen, selvhostet KI-server. Evalueringen kan forklare at en ordre riktignok ble opprettet, men at den forventede statusendringen uteble, og direkte knytte opptaket av kjøringen til dette. For sikkerhetsbevisste team er det relevant hvor skjermbilder, applikasjonsdata og testtrafikk behandles. Lokal kontroll er ikke automatisk nødvendig, men kan ved interne applikasjoner og sensitive data være den fornuftigere veien enn en ekstern skytjeneste.

Riktig detaljnivå for ulike mottakere

Utviklingsteam trenger feilmeldinger, tekniske trinn og så presise anvisninger som mulig for reproduksjon. En operations manager trenger derimot først den berørte funksjonen, forretningsrisikoen og en klar uttalelse om driftsevnen. Begge perspektiver må kunne oppstå fra samme kjøring, uten at noen manuelt må overføre resultater til presentasjoner.

En god rapport begynner derfor med et kort beslutningsnivå: utgivelse anbefalt, utgivelse med kjente begrensninger eller stopp utgivelsen. Under står de kritiske avvikene med prioritet og bevis. De tekniske detaljene følger først etterpå. Det er ingen forenkling på bekostning av nøyaktighet, men en ren adskillelse av informasjonsbehov.

Måle dekning uten å innbille seg sikkerhet

Testdekning fremstilles ofte som en prosentverdi. Denne verdien er nyttig når det er klart hva den måler. Kodedekning viser for eksempel hvilke deler av programkoden som ble kjørt under tester. Det beviser ikke at en forretningsprosess fungerer riktig. En test kan berøre mange kodelinjer og likevel aldri kontrollere om en feil leveringsadresse dukker opp på dokumentet.

For fagavdelinger er prosessdekning ofte mer talende. Den beskriver hvilke reelle flyter som er beskyttet: registrere en ordre, reservere lager, bokføre en delleveranse, ta imot en retur eller godkjenne en faktura. Spesielt verdifulle er overgangene mellom systemer og roller, for der oppstår ofte feil: ved import av en bestilling, ved utskrift av en etikett eller ved bytte fra kontor til lagerterminal.

Prioriter ikke etter antall mulige tester, men etter skadevirkning og endringsfrekvens. En sjelden brukt prosess med høy økonomisk eller juridisk risiko fortjener ofte automatisering tidligere enn en ofte brukt, men harmløs visning. Omvendt kan en stabil, lite kritisk flyt fortsatt klare seg med en kort manuell kontroll. Ikke hver kontroll må automatiseres bare fordi den kan automatiseres.

Ustabile tester er et eget kvalitetsproblem

Tester som uten gjenkjennelig produktendring av og til består og av og til mislykkes, kalles ofte flaky. De skader tilliten raskere enn en permanent rød test. Så snart team refleksmessig starter røde resultater på nytt, mister automatiseringen sin varslingsfunksjon.

Årsakene er som regel konkrete: faste ventetider, felles brukte testdata, parallelle tilganger, asynkron behandling eller et miljø som ikke tilbakestilles. En kort pause på tre sekunder i testen kan tilfeldigvis hjelpe, men er ingen løsning. Bedre er å vente på en påviselig tilstand, gjøre testdata entydige og isolere flyter fra hverandre.

Ikke all ustabilitet kan unngås helt. Eksterne grensesnitt kan svinge, og reell infrastruktur har utfall. Da bør rapporten tydelig markere om en test ikke lot seg vurdere på grunn av en ekstern avhengighet. En gjentatt kjøring kan være fornuftig for diagnose, men må ikke gjøre det første funnet usynlig.

Et fornuftig forløp etter hver testkjøring

Etter en automatisert kjøring bør ikke hvert resultat umiddelbart behandles likt. Først kontrolleres blokkerende feil og kritiske tester som ikke lot seg vurdere. Deretter følger innplasseringen av nye avvik mot kjente, aksepterte problemer. Først da er en utgivelsesbeslutning holdbar.

Fastsatte terskelverdier hjelper, men de må passe til prosessen. For eksempel kan en mislykket test i betalings- eller tilgangsflyten utløse et umiddelbart stopp. Ved et rent kosmetisk avvik kan et dokumentert unntak være forsvarlig. Slike regler bør ikke først oppstå under tidspress før en utgivelse.

Like viktig er tilbakemeldingen: hver produksjonsfeil som testene ikke oppdaget, er en anledning til å sjekke om et scenario, en testdatavariant eller et kontrollpunkt mangler. Målet er ikke å hope opp flest mulig tester. Det er å bygge bedre sikring, målrettet, ut fra reelle feil.

De mest nyttige testresultatene er til slutt ikke de med den grønneste oversikten. Det er de der en ansvarlig mandag morgen kan forstå hva som ble kontrollert, hvilken risiko som gjenstår og hvilken handling som nå er fornuftig.