Att bedöma Test Automation Results på rätt sätt

Ett regressionstest kan på morgonen sluta med 98 procent lyckade fall och ändå inte vara goda nyheter. Kanske är det misslyckade testet just inloggningen för en storkund. Kanske hoppades 40 tester över eftersom testmiljön inte gick att nå. Eller så var körningen grön, men kontrollerade bara om knappar finns, inte om en order faktiskt sparas, en följesedel skapas och lagret justeras korrekt. Test automation results är inget kvalitetsutlåtande så länge deras sammanhang saknas.

För QA-ledning, utveckling och verksamhetsavdelningar ligger det egentliga arbetet därför inte bara i att automatisera tester. Avgörande är att bereda resultaten så att tillförlitliga beslut uppstår: kan en release rullas ut? Måste ett fel hanteras direkt? Är felet nytt, återkommande eller bara ett problem i testmiljön? Och finns det belägg som även en verksamhetsavdelning utan testkod kan följa?

Vad Test Automation Results egentligen säger

Det enklaste nyckeltalet lyder: godkänt eller underkänt. Det är till hjälp, men sällan tillräckligt. En hög andel lyckade tester kan skapa förtroende om testerna täcker kritiska flöden, testdatan är trovärdig och miljön liknar den senare driften. Saknas en av dessa faktorer förblir siffran framför allt en signal om att ett automatiserat flöde kördes.

Vid affärskritiska applikationer väger andra frågor tyngre. I en lagerlösning är inte varje bildskärmsvy lika viktig. Ett visningsfel i en intern infotext kan vänta. Ett fel som bokar fel mängd vid godsmottagning eller skapar en fraktetikett utan mottagaradress kan det inte. Bra testresultat väger därför risker istället för att behandla alla fall lika.

Inte heller ett misslyckat test är automatiskt ett produktfel. Det kan utlösas av utgångna inloggningsuppgifter, en spärrad testroll, otillgängliga gränssnitt, ändrad testdata eller en långsam miljö. Den som inte skiljer dessa orsaker åt producerar brus. Teamet lägger då tid på falsklarm medan verkliga fel försvinner bland röda statusmeddelanden.

Fyra statustyper istället för en röd lista

I praktiken har en tydlig indelning visat sig fungera: funktionellt fel, tekniskt testfel, miljöproblem och förväntad ändring. Ett funktionellt fel innebär att applikationen bryter mot ett definierat krav. Ett tekniskt testfel pekar snarare på själva testet, till exempel en selektor som inte längre stämmer efter ett avsiktligt ändrat gränssnitt.

Ett miljöproblem föreligger när till exempel ett testsystem eller ett anslutet gränssnitt inte är tillgängligt. Förväntade ändringar uppstår när en process medvetet anpassats, men automatiseringen fortfarande kontrollerar det gamla börläget. Dessa kategorier förhindrar inte varje diskussion. Men de ser till att diskussionen börjar på rätt punkt.

Från testkörningar till beslutsklara rapporter

En användbar rapport besvarar inte bara att något misslyckades, utan vad som hände, hur allvarligt det är och om felet verkar reproducerbart. Det kräver mer än en lista med testnamn och tidsstämplar.

Till varje relevant körning hör den kontrollerade builden, testmiljön, den använda rollen, centrala testdata samt start- och sluttid. Särskilt vid Windows-skrivbordsapplikationer eller komplexa webbplattformar behövs den informationen för att avgränsa skillnader. Ett fel som bara uppstår under en begränsad lagerroll är något annat än ett fel som blockerar varje inloggning.

Meningsfulla resultat innehåller dessutom spårbara belägg: skärmdumpar, inspelade steg, felmeddelanden och vid behov tekniska loggar. En skärmdump ensam kan dock vilseleda. Den visar ett ögonblick, inte orsaken. Kombinationen av stegföljd, synligt tillstånd och förväntad reaktion är betydligt mer användbar.

AI-stödda system kan omvandla dessa belägg till begripliga bedömningar. Hos COCO exempelvis körs tester på en egen, självhostad AI-server. Utvärderingen kan förklara att en order visserligen skapades men att den förväntade statusändringen uteblev, och direkt koppla ihop inspelningen av körningen. För säkerhetsmedvetna team är det relevant var skärmdumpar, applikationsdata och testtrafik bearbetas. Lokal kontroll är inte automatiskt nödvändig, men kan vid interna applikationer och känsliga data vara den förnuftigare vägen än en extern molntjänst.

Rätt detaljnivå för olika mottagare

Utvecklingsteam behöver felmeddelanden, tekniska steg och så precisa anvisningar som möjligt för reproduktion. En operations manager behöver däremot först den berörda funktionen, affärsrisken och ett tydligt besked om driftdugligheten. Båda perspektiven måste kunna uppstå ur samma körning, utan att någon manuellt behöver föra över resultat till presentationer.

En bra rapport börjar därför med en kort beslutsnivå: release rekommenderas, release med kända begränsningar eller stoppa releasen. Därunder står de kritiska avvikelserna med prioritet och belägg. De tekniska detaljerna följer först därefter. Det är ingen förenkling på bekostnad av noggrannheten, utan en ren separation av informationsbehov.

Mäta täckning utan att inbilla sig säkerhet

Testtäckning presenteras ofta som ett procentvärde. Det värdet är användbart när det är klart vad det mäter. Kodtäckning visar till exempel vilka delar av programkoden som kördes under tester. Det bevisar inte att en affärsprocess fungerar korrekt. Ett test kan beröra många kodrader och ändå aldrig kontrollera om en felaktig leveransadress dyker upp på dokumentet.

För verksamhetsavdelningar är processtäckning ofta mer talande. Den beskriver vilka verkliga flöden som är skyddade: registrera en order, reservera lager, boka en delleverans, ta emot en retur eller godkänna en faktura. Särskilt värdefulla är övergångarna mellan system och roller, eftersom fel ofta uppstår där: vid import av en beställning, vid utskrift av en etikett eller vid byte från kontor till lagerterminal.

Prioritera inte efter antalet möjliga tester, utan efter skadeverkan och förändringsfrekvens. En sällan använd process med hög ekonomisk eller juridisk risk förtjänar ofta automatisering tidigare än en ofta använd men ofarlig vy. Omvänt kan ett stabilt, föga kritiskt flöde fortfarande klara sig med en kort manuell kontroll. Inte varje kontroll behöver automatiseras bara för att den går att automatisera.

Instabila tester är ett eget kvalitetsproblem

Tester som utan igenkännbar produktändring ibland lyckas och ibland misslyckas kallas ofta flaky. De skadar förtroendet snabbare än ett permanent rött test. Så fort team reflexmässigt startar om röda resultat förlorar automatiseringen sin varningsfunktion.

Orsakerna är oftast konkreta: hårda väntetider, gemensamt använd testdata, parallella åtkomster, asynkron bearbetning eller en miljö som inte återställs. En kort paus på tre sekunder i testet kan av en slump hjälpa, men är ingen lösning. Bättre är att vänta på ett påvisbart tillstånd, göra testdata entydig och isolera flöden från varandra.

Inte varje instabilitet går att undvika helt. Externa gränssnitt kan variera och verklig infrastruktur har avbrott. Då bör rapporten tydligt markera om ett test inte gick att bedöma på grund av ett externt beroende. En upprepad körning kan vara meningsfull för diagnos, men får inte göra det första fyndet osynligt.

Ett förnuftigt flöde efter varje testkörning

Efter en automatiserad körning bör inte varje resultat omedelbart behandlas lika. Först kontrolleras blockerande fel och kritiska tester som inte gick att bedöma. Därefter följer inordningen av nya avvikelser mot kända, accepterade problem. Först då är ett releasebeslut hållbart.

Fastställda tröskelvärden är till hjälp, men de måste passa processen. Till exempel kan ett misslyckat test i betalnings- eller behörighetsflödet utlösa ett omedelbart stopp. Vid en rent kosmetisk avvikelse kan ett dokumenterat undantag vara försvarbart. Sådana regler bör inte först uppstå under tidspress före en release.

Lika viktig är återkopplingen: varje produktionsfel som testerna inte upptäckte är en anledning att kontrollera om ett scenario, en testdatavariant eller en kontrollpunkt saknas. Målet är inte att samla på sig så många tester som möjligt. Det är att av verkliga fel målinriktat bygga bättre säkring.

De mest användbara testresultaten är till sist inte de med den grönaste överblicken. Det är de där en ansvarig på måndagsmorgonen kan förstå vad som kontrollerats, vilken risk som kvarstår och vilken åtgärd som nu är förnuftig.