Leiderschap in de praktijk: hulpmiddelen voor testuitvoering

Get Free Access

Get regular tech leadership wisdom for delivering better software and systems.

Sign up with:

LinkedInGoogleMicrosoft

Or sign up with email:

Name*

First name Last name

Seniority*

Select an optionExecutive / C-suiteVPDirectorManagerIndividual ContributorOther

Business email*

Create Password*

This field is hidden when viewing the form

LinkedIn profile

This field is hidden when viewing the form

Company's AI adoption maturity

Select an optionExploring opportunitiesRunning pilotsScaling adoptionEmbedded in the business model

This field is hidden when viewing the form

Free Account Module

Bottom BarLanding PageFooterInlinePop UpSidebarSSO

Wat je wel en niet krijgt met tools voor testuitvoering

Of je nu desktopapplicaties voor Windows, websites of mobiele apparaten test, de principes van testautomatisering, de voordelen en de valkuilen zijn vergelijkbaar. Wat je met tools krijgt, is:

• Een onvermoeibare, naar verluidt foutloze robot die alle gewenste gescripte tests op verzoek en zo vaak als je wilt uitvoert.
• Een nauwkeurige vergelijking tussen de uitvoer en/of uitkomst van tests en vooraf vastgelegde verwachte resultaten, op elk detailniveau dat je in de tool wilt programmeren.

Wat je niet krijgt, is:

• Flexibiliteit en soepele reacties op afwijkingen, fouten of twijfelachtig gedrag.
• De ogen en het denkvermogen van een menselijke tester, die beslissingen kan nemen om het gedrag van het systeem onder test te onderzoeken, ter discussie te stellen, ermee te experimenteren en het uit te dagen.
• Tests voor niets. Je moet bijvoorbeeld nog steeds tests ontwerpen en testgegevens en verwachte resultaten voorbereiden.
• Hoewel tools voor testuitvoering een scala aan functionaliteiten bieden, beschikken ze vaak niet over geavanceerde mogelijkheden voor gegevensopslag. Voor een uitgebreidere oplossing kun je de beste beschikbare databasebeheersoftware bekijken.

Laten we de betekenis van deze voordelen en problemen onderzoeken.

Als je een redelijk bekwame programmeur bent, is het eenvoudig om procedurele tests die door mensen worden uitgevoerd, in de scripttaal van je tool te implementeren als geautomatiseerde procedures die de tool nauwkeurig kan uitvoeren.

Zolang de omgeving en de gegevens die door je testapplicatie worden gebruikt consistent zijn, kun je verwachten dat je tests steeds opnieuw betrouwbaar worden uitgevoerd. Dit is de voor de hand liggende belofte van geautomatiseerde testuitvoering.

Maar geautomatiseerde tests simuleren niet nauwkeurig wat (goede) testers tijdens het testen doen.

Een test die door een tool wordt uitgevoerd, is NIET gelijkwaardig aan dezelfde test die door een mens wordt uitgevoerd.

Een test kan de tester, als deze is gescript, vertellen wat hij of zij moet doen. Maar testers kunnen verder kijken dan de eenvoudige vergelijking tussen een verwacht resultaat en het resultaat dat op een scherm wordt weergegeven.

Testers moeten naar de locatie van de test navigeren en alert zijn op afwijkend gedrag — de reactie op opdrachten, de reactiesnelheid, het uiterlijk van het scherm en het gedrag van objecten die worden beïnvloed door de veranderende toestand van de applicatie.

Wanneer de menselijke tester een afwijking waarneemt, kan die de test pauzeren, de stappen opnieuw doorlopen of dieper in de applicatie of gegevens duiken voordat hij of zij concludeert dat de applicatie wel of niet correct werkt en beslist of de gescripte test moet worden voortgezet, de gegevens en het script van de test moeten worden aangepast of dat de test volgens plan moet doorgaan.

Mensen zijn flexibel, terwijl tools alleen precies doen waarvoor je ze programmeert. Bij een transactie op basis van schermen voert de tool gegevens in, klikt op een knop en controleert op een bericht of weergegeven resultaat – en dat is alles. Bij menselijke testers krijg je zoveel meer dat we als vanzelfsprekend beschouwen. 

In principe is het mogelijk om een tool te programmeren zodat deze alle controles uitvoert die een mens instinctief uitvoert – maar je zult veel code moeten schrijven en tijd moeten besteden aan het opsporen en oplossen van fouten in je tests. Zelfs dan beschik je niet over het vermogen van een mens om te beslissen wat er vervolgens moet gebeuren – pauzeren, doorgaan, de test halverwege wijzigen of een afwijking grondiger onderzoeken.

Nergens is de inflexibiliteit van tools duidelijker dan bij het reageren op het verlies van synchronisatie tussen het script en het systeem onder test. Misschien komt een verwacht resultaat niet overeen, crasht het systeem of wijkt het gedrag van de gebruikersinterface (bijvoorbeeld een gewijzigde volgorde van velden of een nieuw veld) af van wat het script verwacht. Wat doet de tool? Deze probeert door te gaan, waarna een stortvloed aan scriptfouten of crashes ontstaat. 

Ja, je kunt en moet ongeplande gebeurtenisafhandelaars in je script opnemen om testfouten op te vangen. Verlies van synchronisatie, discrepanties tussen de systeemstatus en testgegevens, wijzigingen in de volgorde van velden, nieuwe velden of verwijderde velden zijn zaken die de tester kan herkennen en afhandelen zonder dat het testen volledig tot stilstand komt. Tools kunnen dit niet zonder veel programmeerwerk van jouw kant.

Er kleven ook nadelen aan het gebruik van mensen om scriptgestuurde tests uit te voeren. Testers kunnen geobsedeerd raken door het opvolgen van het script en vergeten hun observatievermogen te gebruiken. Ze kunnen duidelijke afwijkingen over het hoofd zien omdat ze zich concentreren op het volgen van het script. Deze allesbehalve optimale aanpak is precies wat we krijgen met automatisering van de testuitvoering.

Blind vasthouden aan testscripts is een slecht idee voor menselijke testers, maar met testautomatisering is het het beste wat we kunnen doen.

In deze vergelijking tussen testers die scripts volgen en tools die tests uitvoeren, hebben we nog niet gekeken naar wat exploratieve testers doen. De exploratieve aanpak geeft testers de vrijheid om te onderzoeken en te testen waar en hoe ze maar willen. 

Het is duidelijk dat tools deze activiteit niet kunnen simuleren. Belangrijker nog: tools kunnen de functionaliteit en risico's van een systeem niet afbakenen, prioriteren en modelleren, en ook geen tests op basis daarvan ontwerpen.

Testanalyse en testontwerp zijn noodzakelijk, ongeacht of een test door een mens of een tool wordt uitgevoerd.

Er zijn verdere beperkingen aan wat tools voor testuitvoering kunnen doen:

• Tools voor testuitvoering doen precies waarvoor je ze programmeert – niet meer en niet minder
• Tools bouwen en configureren doorgaans geen omgevingen en applicaties en laden geen testgegevens
• Tools ontwerpen geen testgevallen of scripts en bereiden geen testgegevens en verwachte resultaten voor
• Tools kunnen geen weloverwogen beslissingen nemen wanneer zich onverwachte gebeurtenissen voordoen.

Om je processen voor testuitvoering te optimaliseren, kan integratie met robuuste software voor testbeheer gestroomlijnde workflows en uitgebreidere rapportage bieden.

Testautomatisering van grafische gebruikersinterfaces (GUI)

Het is ongeveer vijfentwintig jaar geleden dat tools voor GUI-testautomatisering op de markt kwamen, maar het aantal mislukte implementaties van GUI-testtools is nog steeds hoog. Dit komt vooral doordat de verwachtingen voor automatisering te hoog worden gesteld – en tools die zonder discipline worden gebruikt, zullen daar nooit aan voldoen.

Tools voor GUI-testautomatisering staan erom bekend dat ze als product eenvoudig te gebruiken zijn, maar moeilijk te beheren wanneer de applicaties onder test (en dus de testscripts) moeten veranderen. Deze tools zijn zeer gevoelig voor wijzigingen in de gebruikersinterface. Wijzigingen in locatie, volgorde en grootte, evenals het toevoegen of verwijderen van schermobjecten, kunnen allemaal invloed hebben op scripts. Ook meer technische wijzigingen, zoals het hernoemen van schermobjecten of het aanpassen van ‘onzichtbare’ ingebedde GUI-bibliotheken, veroorzaken problemen.

GUI-testautomatisering werkt het best wanneer er discipline is met betrekking tot:

• Het ontwikkelproces en wijzigingen en releases worden zorgvuldig beheerd. Zo worden wijzigingen bijvoorbeeld geanalyseerd op hun impact en aan testers gemeld. 
• De aanpak voor de ontwikkeling van testscripts. Ervaren specialisten in testautomatisering hanteren systematische naamgevingsconventies, mappenstructuren, modulaire en herbruikbare componenten, defensieve programmeertechnieken enzovoort.

Het scripten van testautomatisering is een taak waarvoor meer nodig is dan basiskennis van programmeren en vooral ervaring met automatisering en de gebruikte tool. Wanneer tests op grote schaal worden geautomatiseerd, zijn er ook ontwerpvaardigheden nodig. 

Hoe tools ook door leveranciers worden omschreven – ‘zonder scripts’, ‘bruikbaar voor niet-programmeurs’ of ‘gebruikers kunnen ook automatiseren’ – je hebt nog steeds een programmeursmentaliteit, ontwerpvaardigheden en een systematische aanpak nodig.

Testautomatisering van API's en diensten

Wanneer er componenten of functionaliteit zijn die als diensten zijn geïmplementeerd en door dunne clients of mobiele clients worden aangeroepen, wordt het testen uitgevoerd met behulp van een API of via aanroepen van diensten. Deze testmethode wordt uitgevoerd met aangepaste code die door ontwikkelaars is geschreven of met speciale tools voor API- of diensttests. Hoe dan ook is de gebruikelijke aanpak om het testen op de een of andere manier te automatiseren.

Omdat de API ‘dichter’ bij de te testen code staat, kunnen tests veel gerichter worden gemaakt voor de te testen functionaliteit. De complexiteit van het navigeren door de gebruikersinterface en het testen via de gebruikersinterface zelf kan zeker worden omzeild. Daarom geldt als algemene regel:

Als de functionaliteit die wordt getest (op code- of componentniveau) kan worden getest met een functieaanroep, een API- of serviceaanroep, dan zal automatisering eenvoudiger zijn – en wordt deze aanbevolen.

Testen via de API heeft duidelijke voordelen.

• Hoewel je code moet gebruiken of schrijven, zijn de tests zelf veel eenvoudiger uit te voeren (er is geen gebruikersinterface om rekening mee te houden).
• Zodra een API-aanroep is gescript, hoef je alleen nog de reeks testgevallen die je wilt uitvoeren in kaart te brengen. Er is geen limiet aan het aantal tests dat je kunt uitvoeren.
• Tests op basis van API's worden doorgaans veel sneller uitgevoerd, waardoor deze testmethode zeer geschikt is voor benaderingen van continue levering, waarbij de implementatiepijplijn sterk geautomatiseerd is en snel moet kunnen reageren.

De ‘piramide van testautomatisering’ (een zoekopdracht in Google levert honderden voorbeelden van de afbeelding op) is vrijwel universeel overgenomen om de aanbeveling weer te geven dat inspanningen op het gebied van testautomatisering zich meer moeten richten op tests door ontwikkelaars of via API's dan via de grafische gebruikersinterface.

• Gebruik tests van de gebruikersinterface wanneer de gebruikersworkflow moet worden doorlopen, maar in beperkte mate omdat tests duur zijn en langzaam kunnen worden uitgevoerd.
• Gebruik API- of serviceaanroepen wanneer de te testen functionaliteit kan worden geïsoleerd en snelheid en eenvoudige automatisering essentieel zijn.

Regressietesten

De klassieke toepassing van geautomatiseerde tools is het uitvoeren van regressietests. Deze tests worden eenmaal uitgevoerd en vervolgens vertrouwd als nauwkeurige weergaven van het verwachte gedrag. Wanneer de geteste applicatiecode, de bijbehorende herbruikbare bibliotheken of de testomgeving verandert, bieden deze tests enige zekerheid dat de vereiste functionaliteit niet nadelig door de wijziging is beïnvloed.

Je kunt je de geautomatiseerde tests voorstellen als een mal waarin het te testen systeem past. Uiteraard moeten de tests ‘slagen’ voor alle controles die eerder zijn uitgevoerd. Door ze opnieuw uit te voeren, probeer je aan te tonen dat de nieuwe softwareversie functioneel gelijkwaardig is aan de vorige versie. Er zijn enkele eenvoudige principes die je moet volgen:

• Ten eerste moeten de uit te voeren tests en controles zo worden geselecteerd dat je erop kunt vertrouwen dat ongewenste gedragswijzigingen niet aanwezig zijn. Deze tests fungeren als een ‘struikeldraad’ om verschillen in gedrag te detecteren.
• Wanneer bugs worden opgelost of andere softwarewijzigingen worden aangebracht, kunnen er gedragingen zijn die (terecht) veranderen maar die, wanneer ze door je tests worden aangetroffen, ervoor zorgen dat een controle mislukt. Je moet je tests óf vooraf wijzigen, óf ze laten mislukken en ze achteraf corrigeren. Soms is het sneller om volledig af te zien van falende tests en nieuwe tests vanaf nul te maken ter vervanging ervan. In elk geval moeten deze gewijzigde tests vervolgens volledig worden uitgevoerd en slagen.
• Als het te testen systeem niet stabiel is, veel bugs bevat of tussen releases ingrijpende wijzigingen ondergaat, is het mogelijk niet haalbaar om economisch een reeks geautomatiseerde tests te onderhouden. Hoewel de functionaliteit van het systeem niet verandert, kan de gebruikersinterface zich nog steeds ontwikkelen – een instabiele gebruikersinterface maakt automatisering ook moeilijker te onderhouden. De kosten van het onderzoeken van testfouten en het onderhouden van tests kunnen zwaarder wegen dan hun nut. Het kan verstandig zijn om de minder stabiele onderdelen van het systeem handmatig te testen totdat ze stabiel zijn.

Testen via de gebruikersinterface kan soms omslachtig, duur en langzaam zijn. Voordat je begint met het automatiseren van tests voor de grafische gebruikersinterface, of zelfs maar één script automatiseert, is het verstandig om te overwegen of het testen van de belangrijkste functionaliteit eenvoudiger, sneller en voordeliger zou zijn met behulp van een API.

De klassieke toepassing van geautomatiseerde tools is het uitvoeren van regressietests. Raadpleeg onze lijst met de beste tools voor softwaretests om er zeker van te zijn dat je hiervoor de meest effectieve tools gebruikt

Kaders voor testautomatisering

Testkaders vormen een essentieel onderdeel van elk succesvol geautomatiseerd testproces. Zie ze als een reeks richtlijnen voor het maken en ontwerpen van testgevallen. Het gebruik ervan kan de snelheid en efficiëntie van je testteam verhogen, de nauwkeurigheid van tests verbeteren, risico's verlagen en de kosten voor testonderhoud verminderen. We bekijken nu twee van deze kaders.

Bij het bespreken van kaders voor testautomatisering is het essentieel om rekening te houden met de rol van tools voor QA-automatisering bij het vormgeven van een effectieve teststrategie.

More Articles

• Levenscyclus van softwaretesten: fasen, hulpmiddelen & beste praktijken
• Testdesign: een essentiële QA-vaardigheid
• Kwetsbaarheidsscanning versus penetratietesten

Kaders voor eenheidstests

Eenheidstestkaders bestaan al enkele jaren en worden veelvuldig door programmeurs gebruikt om hun code te testen. Tests van ontwikkelaars zijn doorgaans behoorlijk lokaal – ze testen tenslotte meestal één component, waarbij interfaces met andere componenten of databases worden nagebootst of vervangen door stubs. Hoewel eenheidstests dus stappen voor het instellen en opruimen vereisen voordat tests worden uitgevoerd en nadat ze zijn voltooid, blijven deze taken doorgaans beperkt tot het uitvoeren van tests van één component. Voor elke component bestaan afzonderlijke testsuites.

Unit tests die door ontwikkelaars worden gemaakt, worden doorgaans versiebeheerd en parallel aan de componentcode beheerd. Meestal nemen faciliteiten voor continue integratie de broncode en alle unit tests en voeren deze uit na elke commit van nieuwe code en/of tests. Alle ontwikkelaars zien het resultaat van deze tests, waardoor een testfout in CI zeer zichtbaar wordt. Het oplossen van falende tests en code heeft een hoge prioriteit in teams die CI op deze manier gebruiken, zodat de nieuwste versie van het systeem altijd voor alle CI-tests slaagt.

Automatiseringsframeworks voor integratie- en systeemtests

De afgelopen jaren zijn GUI-testtools geïntegreerd met CI-tools met behulp van gevirtualiseerde testapparaten, omgevingen en uitvoering via opdrachtregelinterfaces. Veel organisaties zijn erin geslaagd de uitvoering van unit-, API-niveau- en GUI-tests volledig te integreren via CI-services.

Veel testteams beheren echter nog steeds hun eigen testomgevingen, gescheiden van ontwikkeling of CI-services. Deze teams bouwen vaak hun eigen testautomatiseringsframeworks, omdat CI-tools te veel op ontwikkelaars zijn gericht of propriëtaire tools tekortschieten.

GUI-tests implementeren meestal end-to-endtests of gebruikersreizen met behulp van verschillende applicaties, hardwareapparaten en omgevingen. Deze tests moeten geïntegreerde testomgevingen en voorbereide testgegevens op verschillende platforms naadloos instellen. Hiervoor zijn geprivilegieerde, complexe procedures en uiteenlopende technische omgevingen nodig. De overgrote meerderheid van de teams die GUI-testautomatisering gebruiken, bouwt eigen unieke, maar effectieve automatiseringsframeworks.

GUI-automatiseringsframeworks variëren in geavanceerdheid van tools die lijken op unit-testtools tot complexe en uitgebreide faciliteiten die nodig zijn voor het beheren van omgevingen, applicatiebuilds, enorme hoeveelheden testgegevens, berichten en synchronisatie tussen platforms en omgevingen, en berichten en meldingen aan teamleden.

Sommige propriëtaire tools worden geleverd met hulpprogramma's of harnassen voor het beheren, uitvoeren en rapporteren van suites met geautomatiseerde tests. Deze hebben wisselende waarde, waardoor veel organisaties hun eigen testautomatiseringsframeworks schrijven om hun functionaliteit uit te breiden. De afgelopen jaren is het toepassingsgebied van automatiseringsframeworks gegroeid en bestaat er niet langer één enkele of eenvoudige definitie. Daarom bekijken we nu wat testautomatiseringsframeworks voor softwareteams kunnen doen.

Een testautomatiseringsframework breidt de functionaliteit van testuitvoeringsengines uit.

Configuratie van testsuites

Het framework integreert geautomatiseerde tests in betekenisvolle verzamelingen of clusters van tests. Deze verzamelingen kunnen worden geconfigureerd, zodat tests kunnen worden uitgevoerd in een hiërarchie van reeksen, groepen of willekeurige selecties. Deze tools kunnen functies bevatten om tests datagestuurd te maken met behulp van voorbereide tabellen met testgegevens. Dit is het eenvoudigste type framework — populaire tools bieden meestal een vorm van configuratie van testsuites.

Instellen en opruimen

Het framework handelt alle activiteiten voor het instellen en opruimen af voor één test, verzameling of volledige suite. Het instellen kan bestaan uit het vanaf nul creëren van testomgevingen, volledige configuraties en het vooraf laden van testdatabases en andere gegevensbronnen. Het opruimen kan het opschonen van testgegevens of het resetten of verwijderen van gedeeltelijke of volledige omgevingen omvatten. Het framework kan integreren met orkestratietools voor pipelines en daaronder vallen.

Afhandeling van uitzonderingen

Een fout in een test – of die nu optreedt in het systeem onder test of het gevolg is van verlies van synchronisatie – kan consistent worden afgehandeld door de gebeurtenis te rapporteren en doorgaans toe te staan dat de resterende tests in die verzameling verder worden uitgevoerd. Het framework kan worden geprogrammeerd om fouten bij testcontroles, verlies van synchronisatie, time-outs tijdens de uitvoering en andere geselecteerde testresultaten af te handelen, elk met aangepaste procedures.

Logboekregistratie en berichten

Het framework registreert de testuitvoering en uitvoeringsstatus consistent voor alle testverzamelingen. Het framework activeert rapporten vanuit de tools die tests uitvoeren of biedt een consistent rapportagedagboek van alle activiteiten voor het instellen, uitvoeren en opruimen van tests. Het framework kan communiceren met ChatOps-bots om het team over uitzonderingen te informeren en teamleden de mogelijkheid te bieden testsuites te pauzeren, te stoppen, te herhalen of opnieuw te starten.

Testabstractie met domeinspecifieke taal

Er zijn twee verschillende typen frameworks op de markt verschenen die de code voor testuitvoering abstraheren naar modellen of naar voor mensen leesbare of niet-technische tekst:

• Frameworks die op trefwoorden zijn gebaseerd, maken het mogelijk tests te definiëren met behulp van trefwoorden. Aanroepen van functies van de uitvoeringsengine worden geïmplementeerd als op het Engels lijkende opdrachten met plaatshouders voor parameters of gegevens. Door de gebruiker gedefinieerde, herbruikbare modules kunnen op dezelfde manier worden gedefinieerd en aangeroepen met opdrachten in gewone tekst. Er bestaan frameworks voor allerlei interfaces, waaronder GUI, services, API's, opdrachtregelinterpreters enzovoort. Scripts kunnen functionaliteit uitvoeren op verschillende besturingssystemen en apparaatplatforms.
• Frameworks voor gedragsgestuurde ontwikkeling (BDD) maken het mogelijk verhalen en scenario's (voorbeelden) waarin het gedrag van functies wordt beschreven, vast te leggen met behulp van een domeinspecifieke taal (DSL). De populairste taal is het zogenaamde Gherkin, dat de taalstructuur “given … when … then …” gebruikt om voorbeelden vast te leggen. Given/when/then vertegenwoordigen effectief de precondities, stappen en postcondities van testgevallen. BDD-tools zetten de tekst met given/when/then om in ‘stapaanroepen’ in een programmeertaal. De ontwikkelaar (of tester) moet de ‘testvoorzieningen’ of code implementeren om aanroepen naar een testuitvoeringsengine mogelijk te maken. Op deze manier kan de taal van een vereiste (het verhaal) rechtstreeks worden verbonden met de tekstuele uitvoeringscode.

Modelgebaseerde frameworks

In dit geval maken tools het mogelijk om een model van het systeem onder test te creëren. Dit kan automatisch worden afgeleid van een webpagina, waarbij de tool de HTML scant, formulieren en velden detecteert en een model opbouwt waaruit paden door de formulieren automatisch kunnen worden gegenereerd of door de tester kunnen worden geselecteerd. Objectmappings voor mobiele apps of andere slimme apparaten kunnen ook handmatig worden opgebouwd. Met behulp van de paden door de objectmapping worden aanroepen naar de functies van de testuitvoeringsengine gedaan op een vergelijkbare manier als bij BDD- en sleutelwoordgestuurde tools. In principe kunnen tests grafisch en zonder code worden opgebouwd. Tools in dit domein zijn relatief nieuw en worden snel verbeterd. Verwacht dat het gebruik ervan in de toekomst zal versnellen.

Schrijf je in voor de nieuwsbrief van The QA Lead om een melding te ontvangen wanneer nieuwe delen van de serie verschijnen. Deze berichten zijn fragmenten uit Pauls cursus Leiderschap in testen, die we ten zeerste aanbevelen voor een diepgaandere behandeling van dit en andere onderwerpen. Als je dat doet, gebruik dan onze exclusieve kortingscode QALEADOFFER om $60 korting op de volledige cursusprijs te krijgen!

Gerelateerd artikel: 10 BESTE TOOLS VOOR WEBSERVERMONITORING