MobileBrains Blog - Automated UI Testen deel 2

In dit tweede deel van mijn blog over de inzet van testautomatisering is een verdieping van de situatie die ik schetste in deel 1 van het blog over Automated UI testen.

Breekbaarheid

Een van de belangrijkste kwaliteitseisen van een testset is de breekbaarheid. Willen we kunnen vertrouwen op de automatische tests zonder dat er meer onderhoud in gaat zitten dan het geval zou zijn bij handmatig testen, dan zoeken we naar een testset die niet zomaar ‘omvalt’ bij het minste of geringste.

In de praktijk kunnen testen om allerlei redenen falen.

• De locatie of volgorde van UI-elementen kunnen veranderen. Een broze test zou omvallen, maar een correcte test zou hier geen last van hebben.
• Gegevens kunnen op het moment dat de testset wordt geschreven correct zijn, maar als de test een tijdje draait zijn verouderd. Een breekbare test zou dit niet afvangen, maar een veerkrachtige test wel.
• Een korte hik in het netwerk zou een breekbare test kunnen laten falen, een goede test is hierop voorbereid.

Zoals je begrijpt kost het opzetten van een goede, veerkrachtige test meer tijd (zie grafiek), maar als we in de grafiek meerekenen wat het kost om een breekbare testset te onderhouden, dan begrijp je het resultaat. Op het moment van de scherpe knikken in de lijn van de breekbare testen, praten we over ‘test death’. Oftewel, al de geïnvesteerde tijd is voor een (groot) deel weggegooid geld.

De ervaring leert dat de grafiek misschien zelfs nog wel een onrealistisch beeld schetst van de breekbare testen. Het komt namelijk vaak genoeg voor dat deze al hun einde bereiken voordat ze de kosten van een handmatige test geraakt zouden hebben.

Single Point of Success / Failure

Het schrijven van een goede verificatie voor een test is een belangrijkste fundament voor een testset met waarde. En gelijk ook de lastigste. De belangrijkste uitgangspunten hierbij zijn de volgende twee stellingen: 

• “De test slaagt enkel als het geteste component ook daadwerkelijk voldoet aan alle gestelde eisen.”
• “De test faalt enkel in de gevallen dat het geteste component niet voldoen aan één (of meerder) van de gestelde eisen."

Een test die voldoet aan deze eisen is helder en helpt duidelijk vertrouwen te krijgen in de kwaliteit van de software. We noemen deze eigenschap ook wel de testeffectiviteit. Schrik niet, maar het is niet ongebruikelijk dat een automatische testrun met 100% geslaagde testen eindigt, om later op de dag te ontdekken dat alle teksten dwars door elkaar staan. Overduidelijk bevat de software dan een issue, maar de testrun heeft er dwars overheen gekeken, terwijl een handmatige (menselijke) test dit gelijk had opgemerkt. En is dat onderaan de streep niet het doel van alles waar we het over hebben? 

Het punt hier is dat testen geschreven kunnen worden met sterke of zwakke verificatie kracht. Aan de ene kant kan er een test geschreven worden die simpelweg op alle knoppen klikt en kijk of er geen crash optreed. Dit zou een snelle (lees: goedkope) test zijn om te maken, maar het voegt relatief weinig vertrouwen toe. Aan de andere kant van het spectrum staan dan testen die een manueel tester nabootsen. Deze zijn uiteraard duurder om te implementeren. Daarom is het belangrijk altijd af te wegen:

• welke typen testen nodig zijn;
• welke effectief zijn voor de testset en;
• welke testen krachtig genoeg zijn om de issues in de software te kunnen detecteren.

Nog een laatste noot. Ook bij een correct opgebouwde testset is onderhoud niet gratis. Testen zullen altijd gemonitord moeten worden. Hoe robuuster de set, hoe complexer deze vaak worden. Er zal altijd een risico blijven dat een test breekbaar worden. Door afhankelijkheden met andere systemen, veranderende infrastructuur of aangepaste testdata.

Het is daarom van belang om bij het opzetten van de testomgeving goed te kijken naar de doelen die gesteld zijn. In deel drie van deze post geven we daar een handvat voor. We onderzoeken de test strategie en proberen te bepalen voor elke doel of er een positieve ROI behaald kan worden voor automatisering t.o.v. handmatige testen.