Testautomatisering met HP Unified Functional Testing

Tijdens mijn periode bij een voorgaande opdrachtgever ben ik in aanraking gekomen met HP UFT (Unified Functional Testing, voorheen QTP). Ze waren daar begonnen met testautomatisering en hadden al verschillende scripts geschreven die vooral op basis van Record en Playback gemaakt waren. Deze scripts waren snel gemaakt maar zeer onderhoudsonvriendelijk.

HP UFT slaat alle objecten die op een scherm gebruikt worden tijdens de test op in een zogeheten “Object Repository” om de objecten bij het afspelen van een test script weer te kunnen vinden. Dat werk natuurlijk heel goed als de software die je test niet verandert.

Maar ja… we testten juist veranderde software en dat betekende vaak dat de scripts niet of niet meer goed werkten. De zogeheten Properties (eigenschappen) van een object bij een update van de software veranderde, vandaar dat deze methode zeer onderhoudsintensief was.

Scripts waren ook allemaal apart gemaakt. Als men 20 keer dezelfde schermen gebruikte, stond dit ook 20 keer apart in de code (en de Object Repository), dus van herbruikbaarheid was geen sprake.

De eerste stap die ik heb gezet was om code herbruikbaar te maken, zodat code bij fout lopen maar 1 keer gewijzigd moest worden, in plaats van op 20 verschillende plaatsen. We creëerden zogeheten Functie Libraries waar herbruikbare code stond.

De volgende stap was om de Object Repository te manipuleren tijdens het testen zodat objecten ook bij wijzigingen makkelijker gevonden werden. Hierbij bleef je wel nog steeds afhankelijk van deze Object Repository.

De volgende stap was ook logisch maar nog niet eerder aan de orde gekomen. De automatisch testscripts moeten ook nog goed en effectief herbruikbaar zijn. Dat betekent dat de gebruikte data instelbaar/flexibel moeten zijn. Belangrijke velden worden dan ook niet gevuld met een vaste waarde maar met waardes die je vooraf in een Excel sheet kan invoeren. Op deze manier kan je bijvoorbeeld aanmaken van een nieuwe opdrachtgever 10 keer achter elkaar uitvoeren en worden er 10 verschillende opdrachtgever met verschillende informatie ingevoerd.

De laatste stap was het loslaten van de Object Repository. Objecten kunnen ook worden gecreëerd op basis van de eigenschappen van het object die je kent. Door de eigenschappen van een object te gebruiken, die bij een software update meestal hetzelfde blijven, zijn de geautomatiseerde scripts veel gemakkelijker te onderhouden.

Een WebButton bijvoorbeeld, heeft eigenschappen als X en Y coördinaat, maar heeft ook een naam van de button die meestal gelijk blijft. Deze gebruiken we dan om de button te vinden op het scherm.

Bij mijn huidige werkgever werk ik als HP UFT testautomatiseerder en heb voor alle type objecten standaard Functie Library functies geschreven die verschillende acties kunnen uitvoeren.  Een script bestaat nu alleen uit aanroepen van standaard Functie Library Functies die de objecten genereren. Voor standaard acties zoals inloggen en navigeren zijn daarnaast aparte Library Functies geschreven om in te loggen of te navigeren naar een website.

Het blijft mooi om te zien hoe afdelingen reageren op de testen die geautomatiseerd zijn en de winst is natuurlijk gigantisch, omdat afdelingen zelf veel minder tijd hoeven vrij te maken om te testen en de doorloop tijd gaat bij dit bedrijf van 6 – 8 weken naar 2 weken.