Hoe maak je herbruikbaarheid mogelijk met objectopslagplaatsen bij geautomatiseerd testen?
Als automatiseringsontwikkelaar voelen we toch een gevoel van voldoening wanneer we van het handmatige testteam of de klant horen hoe zij baat hebben gehad bij het gebruik van de automatisering die we hebben gebouwd? Hiervoor staan we garant voor een hoogwaardige automatiseringssuite die niet alleen robuust is, maar zich ook gemakkelijk laat aanpassen aan updates die nodig zijn vanwege veranderingen in zakelijke/technische vereisten. Onderhoud moet eenvoudig zijn—dat blijven we onszelf herinneren. Wat zijn de manieren om hiervoor te zorgen?
Van de verschillende manieren waarop we de hoge kwaliteit van een Test Automation-suite kunnen waarborgen, is één manier het garanderen van herbruikbaarheid—niet alleen door veelgebruikte teststappen opnieuw te gebruiken, maar ook door veelgebruikte UI-objecten opnieuw te gebruiken. In dit artikel leg ik uit hoe we objectopslagplaatsen kunnen gebruiken om het aspect van herbruikbaarheid te verbeteren door objecten opnieuw te gebruiken in een UI-testautomatiseringsproject.
- Wat is een objectopslagplaats in testautomatisering?
- Waarom is dit belangrijk?
- Te volgen best practices bij het gebruik van objectopslagplaatsen
- Objectopslagplaatsen maken (voorbeelden)
Wat is een objectopslagplaats in testautomatisering?
Wanneer je net begint met het ontwerpen van de testautomatiseringssuite, zorgen de meesten van ons ervoor dat we codeblokken niet opnieuw schrijven. Hiervoor bouwen we herbruikbare functies en maken we de herbruikbare codeblokken beschikbaar in codelibraries. Maar heb je veelgebruikte UI-objecten opnieuw gebruikt? Zo niet, laat me dan uitleggen hoe je dit kunt doen door een objectopslagplaats als basis te gebruiken.
Want more from The CTO Club?
Create a free account to finish this piece and join a community of CTOs and engineering leaders sharing real-world frameworks, tools, and insights for designing, deploying, and scaling AI-driven technology.
Have an account? Log In
Een objectopslagplaats is een verzameling UI-objecten die vaak met elkaar samenhangen. Dit verbetert niet alleen de herbruikbaarheid, maar zorgt ook voor de betrouwbaarheid en het beheer van de UI-elementen in de automatiseringssuite.
Tijdens het bouwen van de testautomatiseringsscripts zou je testscriptstappen aan elk van deze UI-objecten hebben gekoppeld. Bijvoorbeeld –
- Typen in een UI-object van het type tekstvak
- De tekst ophalen uit een UI-object van het type label
- Op het hyperlinkobject klikken .. enzovoort.
Hoe kun je nu de herbruikbaarheid verbeteren door de UI-objecten waarop je scripts werken opnieuw te gebruiken?
Als de testautomatiseringstool die je gebruikt een “objectopslagplaats” heeft, is het eenvoudig. Met behulp van een objectopslagplaats kun je de UI-objecten verzamelen en de UI-objecten vanuit die opslagplaats op een georganiseerde manier toevoegen, verwijderen, beheren of bijwerken. Uiteindelijk kun je de objecten opnieuw gebruiken door ernaar te verwijzen.
Laten we een situatie analyseren waarin je geen OR hebt gebruikt in je testautomatiseringssuite. In zo'n geval zou je voor afzonderlijke testautomatiseringsscripts die dezelfde UI-widget gebruiken meerdere kopieën van hetzelfde UI-object aan elk testscript toevoegen om er bewerkingen op uit te voeren.
Laten we nu een situatie bekijken waarin we wel een OR gebruiken. In zo'n geval zou je één locatie/opslagplaats hebben waar je de UI-objecten opslaat. Vervolgens zou elk testscript dat op hetzelfde UI-object/dezelfde widget moet werken, dit koppelen aan hetzelfde UI-object dat in de OR is opgeslagen. Er is slechts één kopie van het UI-object in de testsuite, waarbij meerdere testscripts naar hetzelfde UI-object verwijzen of dit aanroepen. En hier komt herbruikbaarheid om de hoek kijken!
Waarom is dit belangrijk?
Mijn eerste ervaring met het gebruik van een OR deed ik toen ik het IBM Rational Functional Test Automation-tool gebruikte. Sindsdien kijk ik, telkens wanneer ik een nieuwe tool leer kennen, of die tool de OR-functie heeft.
De eerste keer dat ik een OR gebruikte, was toen ons team een uitgebreide administratieve webgebruikersinterfaceconsole met meerdere pagina's automatiseerde. We hadden meer dan 100 testgevallen om te automatiseren. Als we de OR niet hadden gebruikt, zou het een enorme uitdaging zijn geweest om dit te automatiseren. We analyseerden de situatie en kwamen tot de conclusie dat de testautomatiseringssuite die we wilden bouwen het ideale geval was om een OR te gebruiken.
De redenen?
1. Elk testgeval dat we automatiseerden had verschillende subflows gemeen en beschikte daarom over bijbehorende UI-widgets die eveneens gemeenschappelijk waren.
Omdat er gemeenschappelijke subflows waren, waren er in de scenario's vanzelfsprekend gemeenschappelijke UI-objecten. We wilden niet steeds opnieuw kopieën van dezelfde UI-objecten toevoegen en besloten daarom de UI-objecten opnieuw te gebruiken.
Een reeks testgevallen moest bijvoorbeeld door dezelfde navigatiemenu-koppelingen navigeren voordat een reeks stappen werd uitgevoerd. Daarom planden we een opslagplaats met als enig doel alle navigatiekoppelingen op te slaan en te beheren. Vervolgens konden we de navigatiemenu-koppelingen opnieuw gebruiken in een OR-bestand.
2. We werden geïnformeerd dat er in de toekomst situaties konden ontstaan waarin de UI zou worden bijgewerkt—in termen van hyperlinks, labels enzovoort.
Daarom wilden we ervoor zorgen dat de testautomatiseringssuite zich gemakkelijk aan veranderingen kon aanpassen wanneer een dergelijke UI-update plaatsvond, en dat onderhoud snel en eenvoudig zou zijn.
Hier kwam de OR ons te hulp: we hoefden de UI-objectopslagplaatsen niet in elke kopie van hetzelfde UI-object te wijzigen. Wanneer er een verandering was, hoefden we alleen het ene bijbehorende object in de OR bij te werken en zouden de testscripts worden uitgevoerd volgens het bijgewerkte UI-object.
3. We moesten binnen een maand een testautomatiseringssuite met meer dan 100 scripts bouwen!
Hier kwam een ander voordeel van het gebruik van een OR naar voren: door ervoor te kiezen een OR te bouwen en ervoor te zorgen dat we niet allemaal dezelfde UI-objecten opnieuw hoefden toe te voegen, bespaarden we tijd. We bouwden een goed georganiseerde OR en hoefden alleen onze code te bouwen rondom de objecten die we in de OR hadden georganiseerd.
We richtten ons op het doel van de testcase en de bedrijfslogica van de testcases, in plaats van tijd te verspillen aan het opnieuw uitvinden van het wiel door objecten voor elk testscript toe te voegen. We bespaarden tijd en leverden uiteindelijk de testautomatiseringssuite binnen de beoogde termijn van een maand op!
Beste werkwijzen voor het gebruik van objectrepositories
Nu je weet in welke situaties een UI-objectrepository zou helpen, wil je zeker ook weten waardoor het werkt?
1. Stel als team een gemeenschappelijk doel voor herbruikbaarheid op. Begrijp samen waarom dit uiteindelijk je automatiseringsteam, het team voor handmatig testen en de klant kan helpen.
2. Zorg er als team tijdens de ontwikkeling van de testautomatiseringssuite altijd voor dat jullie op één lijn zitten en geïnformeerd zijn over de objecten die jullie bouwen. Stel een reeks groeperingsregels en naamgevingsconventies op waar iedereen zich aan houdt. Wanneer je begint, kun je een plan opstellen voor de manier waarop je elk OR-bestand wilt organiseren en opslaan. Bijvoorbeeld navigatiemenuobjecten in één OR-bestand, UI-objecten van een inlogpagina in een ander OR-bestand, enzovoort. Je kunt ook beslissen over naamgevingsconventies voor de objecten, zodat ze gemakkelijk te vinden zijn.
3. Zorg ervoor dat je de UI-objecten zo benoemt dat de naam leesbaar en gemakkelijk te vinden en te relateren is. Benoem de UI-objecten zo dat iemand anders die de UI-repository doorloopt met de bedoeling deze bij te werken, het UI-object gemakkelijk kan vinden. In het onderstaande voorbeeld laat ik zo’n situatie zien.
Objectrepositories maken (voorbeelden)
Laten we nu praktisch bekijken hoe je snel aan de slag kunt gaan met objectrepositories. Tools zoals UFT, IBM RFT, UiPath Test Automation Suite en Power Automate bevatten objectrepositories. Dus waarom wachten? Geloof me, het is heel eenvoudig!
Hier is een voorbeeld waarin ik een OR voor de QAL-website heb gemaakt:
Bekijk de bovenstaande UI: ik heb alle widgets die verband houden met acties op de widgets van de inloginterface samen gegroepeerd, omdat deze in verschillende testcases hetzelfde zouden zijn. Vervolgens heb ik de navigatielinks samen gegroepeerd. Als we deze objecten in een groep opnemen, zullen alle testscripts deze groep UI-linkobjecten aan het begin van elke testcase gebruiken. Deze objecten kunnen dan worden hergebruikt in plaats van dat ze opnieuw aan de repository moeten worden toegevoegd.
Voorbeeld van het gebruik van de objectrepository in UiPath
Zo ziet de objectrepository eruit in de UiPath-tool:
In dit voorbeeld van de objectrepository heb ik de objecten van de “Inlogpagina” in één set georganiseerd en de “Hoofdnavigatielinks” in een andere set. Als ik hiermee meerdere testscripts zou bouwen om bijvoorbeeld de inlogpagina te testen, zouden alle testscripts dezelfde objecten “aanroepen” die ik in de “Inlogpagina” had geplaatst.
Voorbeeld van het gebruik van de objectrepository in PowerAutomate
Zo ziet de objectrepository eruit in de PowerAutomate-tool:
Zoals ik eerder al aangaf, is de sleutel tot herbruikbaarheid ook dat je de objecten zo benoemt dat je ze later gemakkelijk kunt terugvinden. Bekijk het UI-object “meprmath_quiz”. In tegenstelling tot de andere velden kunnen we niet gemakkelijk herkennen naar welk UI-object dit verwijst. In een geval zoals hierboven zouden we het object, hoewel het veld bij het toevoegen van het UI-object voor het tekstvak “quiz” de veldnaam “meprmath_quiz” kreeg, bijvoorbeeld “login_add” kunnen noemen om het object gemakkelijker te kunnen vinden tijdens het automatiseren en onderhouden van de OR.
Samenvatting
Dus, hoe gebruik jij de OR in je favoriete testautomatiseringstool? We horen het graag.
Ik hoop dat dit artikel je helpt begrijpen hoe een OR het team op de lange termijn helpt. We hebben geluk dat we in een tijd leven waarin de meeste testautomatiseringstools over de OR-functie beschikken. Het enige wat je dus hoeft te doen, is ontdekken hoe deze functie werkt in je favoriete tool!
Iets nieuws geleerd in dit artikel? Als je graag meer artikelen zoals dit wilt lezen, vergeet dan niet je te abonneren op de nieuwsbrief van The QA Lead!
Gerelateerde artikelen:
Gerelateerde lijst met tools: SOFTWARE VOOR PRESTATIETESTS VOOR QA-TEAMS
Ook de moeite waard om te bekijken:
