När vi skriver automatiserade tester vill vi skapa största möjliga värde till lägsta möjliga kostnad eller tidsåtgång. Det totala antalet testfall som krävs för att verifiera att ett stort, modernt och komplext system är felfritt är nästan oändligt. ”Allt” går inte att automatisera. I det här inlägget tittar vi närmare på vad som inte kan eller bör automatiseras, och varför.
Vi måste tänka strategiskt för att välja ut ett begränsat antal tester att automatisera. Dessa tester bör täcka en så stor del av systemet som möjligt, vara enkla att implementera, stabila och tillförlitliga samt billiga att modifiera och underhålla.
Testautomatisering handlar om att effektivisera delar av testarbetet, åtminstone de delar som lämpar sig bäst för det. Därför finns det vissa kategorier av tester som vi inte bör automatisera.
En dator saknar helt intelligens, smak och känsla. Därför är det inte möjligt att skapa bra, automatiserade tester för att utvärdera saker som till exempel följande:
Lägg inte tid och energi på att ens försöka verifiera delar av någon av dessa aspekter. En dator saknar förmågan att utvärdera dessa aspekter. Testerna blir komplexa och opålitliga och kan, även teoretiskt sett, endast verifiera en försumbar del av det vi önskar.
Tester som interagerar med applikationen via det grafiska användargränssnittet (GUI) är mycket känsliga för förändringar. Till synes små förändringar i applikationens användargränssnitt gör att testerna slutar fungera. Därför är det ingen bra idé att automatisera tester mot en applikation som ännu inte är stabil. Det faktum att den inte är stabil innebär att den kommer att ändras, modifieras eller korrigeras, vilket gör att testerna slutar fungera.
Tester som interagerar med applikationen via det grafiska användargränssnittet är, jämfört med andra typer av automatiserade tester, komplexa, omfattande, tidskrävande och svåra att ändra. Därför är det en bra idé att vänta med att implementera dessa typer av tester tills systemet har börjat stabiliseras och inga fler störande förändringar förväntas.
Ibland stöter vi på komponenter eller delar av ett system där det är mycket svårt att implementera automatiserade tester. Det kan bero på olika saker. Ett exempel är säkerhet, där hela syftet är att undvika botar eller oönskad automatiserad manipulation. Ett annat exempel är proprietära komponenter, där implementeringsdetaljerna är okända eller hemliga.
Att implementera kreativa (ofta komplexa) lösningar för att kringgå problemet är vanligtvis en dålig idé på lång sikt. Testerna blir oförutsägbara och komplexa. Lägg därför inte för mycket tid på att kämpa med tester i nästan omöjliga situationer där resultaten kommer att bli dåliga.
63+++
Lägg istället tid och energi på att implementera automatiserade tester där det är enkelt och ger bra resultat. Det som ger nytta och värde är tester som körs snabbt, är tillförlitliga, robusta och lätta att ändra och underhålla.
Om vi har tester som inte gick bra när vi körde dem manuellt betyder det att applikationen inte är riktigt stabil ännu. Till synes små ändringar i applikationens användargränssnitt gör att testerna slutar fungera. Därför är det ingen bra idé att implementera automatiska tester via det grafiska användargränssnittet (GUI) för en applikation där de manuella testerna inte gick bra.
Å andra sidan gäller detta inte automatiserade tester via ett API (t.ex. webbtjänster som REST eller SOAP). Automatiserade tester via API är nämligen, jämfört med automatiserade tester via GUI, relativt enkla, korta och snabba att implementera samt lätta att modifiera.
Om vi kan testa systemet via API tidigt i utvecklingscykeln är det en bra idé att börja implementera uttömmande tester på den nivån. När systemet har börjat stabiliseras och inga ytterligare genomgripande förändringar förväntas är det mycket framgångsrikt att komplettera med ett mindre antal automatiserade tester via applikationens grafiska användargränssnitt.
Det mest framgångsrika sättet är att genomföra de automatiserade testerna parallellt med implementeringen av systemet. De automatiserade testerna bör ligga på en så låg testautomatiseringsnivå som möjligt (enhetsnivå, API-nivå, GUI-nivå) för att upptäcka fel så nära källan (där de uppstår) som möjligt.
Testautomatisering på GUI-nivå sker relativt sent i utvecklingskedjan. Vi vill att utvecklingen av systemet ska ha stabiliserats och att inga radikala förändringar eller omkonstruktioner förväntas. Detta beror, som nämnts ovan, på komplexiteten och omfattningen hos dessa tester samt på kostnaden och tiden för modifieringar och underhåll.
Det är viktigt att de som skriver de automatiserade testerna har detaljerad kunskap om hur systemet är tänkt att fungera. Om denna kunskap saknas och teamet, organisationen eller någon annan inte kan förmedla den informationen, blir det mycket svårt att skapa meningsfulla automatiserade tester.