När vi skriver automatiserade tester vill vi tillföra maximalt med värde till minsta möjliga kostnad eller tid. Det totala antalet testfall för att verifiera att ett stort modernt komplext system är felfritt, är i det närmaste oändligt. ”Allt” kan inte automatiseras. Här tittar jag närmare på vad som inte kan/bör automatiseras och varför.
Vi behöver tänka strategiskt för att välja ut ett begränsat antal tester att automatisera. Dessa tester ska täcka en så stor del av systemet som möjligt, vara enkla att implementera, stabila och tillförlitliga och billiga att modifiera och underhålla.
Testautomatisering handlar om att effektivisera delar av testarbetet, åtminstone de delar som är mest lämpade. Därför finns det några kategorier av tester som vi inte bör automatisera.
Tester som kräver intelligens och känsla
En dator saknar helt intelligens, tycke, smak och känsla. Därför går det inte att skapa bra automatiska tester för att utvärdera saker som exempelvis följande:
- Är layouten pedagogisk?
- Är användarupplevelsen behaglig?
- Är det ergonomiskt att använda applikationen?
- Går det lätt att förstå hur man använder systemet?
- Är användargränssnittet visuellt tilltalande?
Lägg inte tid och energi på att ens försöka verifiera delar av någon av dessa aspekter. En dator saknar möjlighet att utvärdera dessa aspekter. Testerna blir komplexa och inte tillförlitliga och kan, även rent teoretiskt, bara verifiera en försumbar bråkdel av vad vi önskar.
Applikationer som ännu inte är stabila (för tidigt i livscykeln)
Tester som interagerar med applikationen via det grafiska användargränssnittet (GUI) är väldigt känsliga för förändringar. Till synes små förändringar av applikationens användargränssnitt får testerna att sluta fungera. Därför är det ingen bra idé att automatisera tester mot en applikation som ännu inte är stabil. Att den inte är stabil betyder att det kommer att förändras, modifieras eller rättas, vilket leder till att testerna kommer sluta fungera.
Tester som interagerar med applikationen via det grafiska användargränssnittet är, i jämförelse med andra typer av automatiserade tester, komplexa, stora, tidskrävande och svåra att modifiera. Därför är det en god idé att vänta med att implementera dessa typer av tester tills systemet har börjat stabilisera sig och inga omvälvande förändringar längre är att vänta.
Applikationer som verktyget har svårt att stödja (API, GUI)
Det händer ibland att vi stöter på komponenter eller delar av ett system som är väldigt svåra att implementera automatiserade tester för. Det kan bero på olika saker. Ett exempel är säkerhet där hela syftet är att undvika botar eller oönskat automatiserad manipulation. Ett annat exempel är proprietära komponenter där detaljer i implementationen är okänd eller hemlig.
Att implementera kreativa (ofta komplexa) lösningar för att arbeta sig runt problemet är oftast en dålig idé i längden. Testerna blir oberäkneliga och komplexa. Lägg därför inte oproportionerligt mycket tid på att kämpa med tester i nästintill omöjliga situationer där resultatet kommer att bli dåligt.
Lägg istället tiden och energin på att implementera automatiserade tester där det är enkelt och framgångsrikt. Det som ger nytta och värde är tester som går att köra fort, som är pålitliga, robusta och som är enkla att modifiera och underhålla.
Testfall som inte har gått bra manuellt
Har vi tester som inte går bra när vi kör testerna manuellt betyder det att applikationen inte är riktigt stabil än. Till synes små förändringar av applikationens användargränssnitt får testerna att sluta fungera. Därför är det ingen bra idé att implementera automatiska tester via det grafiska användargränssnittet (GUI) mot en applikation där de manuella testerna inte går bra.
Å andra sidan gäller inte detta automatiserade tester via ett API (exempelvis WebServices som REST eller SOAP). Detta för att automatiserade tester via API är förhållandevis, i jämförelse med automatiserade tester via GUI, triviala och korta och snabba att implementera och enkla att modifiera.
Har vi möjlighet att testa systemet via API tidigt i utvecklingscykeln så är det en god idé att börja implementera uttömmande tester via den nivån. När systemet har börjat stabilisera sig och inga omvälvande förändringar längre är att vänta så är det väldigt framgångsrikt att komplettera med ett mindre antal automatiserade tester via applikationens grafiska användargränssnitt.
Information om hur systemet fungerar och stöd till testautomatiseraren saknas
Det mest framgångsrika är att implementera de automatiserade testerna parallellt med implementationen av systemet. De automatiserade testerna skall vara på en så låg testautomatiseringsnivå som möjligt (Enhetsnivå, API-nivå, GUI-nivå) för att fånga defekter så nära källan (där de uppstår) som möjligt.
Testautomatisering på GUI-nivå sker relativt sett sent i utvecklingskedjan. Vi vill att utvecklingen av systemet ska ha stabiliserat sig och inga radikala förändringar eller omdesign är förväntade. Detta, som nämnt ovan, på grund av dessa testers komplexitet och storlek samt kostnaden och tiden för modifieringar och underhåll.
Det är viktigt att de som skriver de automatiserade testerna har kunskap om hur systemet är tänkt att fungera i detalj. Saknas den kunskapen och teamet, organisationen eller någon annan inte kan förmedla den informationen så är det väldigt svårt att skapa meningsfulla automatiserade tester.
