Verbeter de softwarekwaliteit & bespaar tijd met infrastructuurtesten
Opmerking van de redactie: Welkom bij de serie Leiderschap in testen van softwaretestexpert en consultant Paul Gerrard. De serie is bedoeld om testers met enkele jaren ervaring—vooral degenen in agile teams—te helpen uitblinken in hun rollen als testlead en manager.
In een eerder artikel heb ik uitgelegd hoe je prestatietests beheert. Nu bespreken we IT-infrastructuursoftware, infrastructuur voor tests en testomgevingen.
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 voor $60 korting op de volledige cursusprijs!
Infrastructuur is de term die we gebruiken om alle hardware, clouddiensten, netwerken, ondersteunende software en onze applicatie onder test te beschrijven die nodig zijn om onze systemen te ontwikkelen, testen, implementeren en beheren.
Het is echter logisch om onze definitie niet te beperken tot technologie. Datacenters, kantoorruimte, bureaus, desktops, laptops, tabletcomputers en mobiele telefoons met hun eigen geïnstalleerde softwarestacks maken allemaal deel uit van het ecosysteem dat nodig is om systemen te ontwikkelen, testen en implementeren.
Als je ontwikkeltools, DevOps-tools en -procedures, testtools en de vereiste bedrijfsprocessen en vakinhoudelijke expertise meetelt, komt er nog veel meer bij kijken.
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
De meest alledaagse zaken—zoals de toegangscodes of smartcards die worden gebruikt om toegang tot gebouwen te krijgen—kunnen kritiek worden als ze niet beschikbaar zijn.
Infrastructuur, in al haar verscheidenheid, bestaat ter ondersteuning van de ontwikkeling, het testen, de implementatie en de werking van je systemen. Ze is ofwel kritiek voor het testen, of moet zelf worden getest.
In het volgende artikel bekijken we tools voor ontwikkeling, testen en samenwerking. In dit artikel bespreken we wat de meeste mensen als testomgevingen beschouwen en kijken we kort naar wat vaak infrastructuurtesten wordt genoemd. Ik behandel:
- Testomgevingen
- Ontwikkelomgevingen
- Testomgevingen op systeemniveau
- Dataomgevingen
- Infrastructuurtesten
Laten we beginnen.
Testomgevingen
Bij alle tests wordt impliciet en kritisch de vereenvoudigende aanname gedaan dat onze tests in een bekende omgeving worden uitgevoerd.
Wat is een omgeving?
Alle systemen moeten in hun context worden getest. Om een test betekenisvol te maken, moet het systeem worden geïnstalleerd, ingesteld, geïmplementeerd of gebouwd in een realistische omgeving die de echte wereld simuleert waarin het zal worden gebruikt.
We kunnen bijvoorbeeld testscenario's gebruiken die de mogelijkheden van systemen op het gebied van functionaliteit, prestaties of beveiliging zwaar belasten, maar dit zijn eigenschappen van de tests, niet van de omgeving.
Een realistische omgeving zou alle zakelijke, technische en organisatorische omgevingen nabootsen. Een groot deel hiervan bestaat uit gegevens die worden gebruikt om bedrijfsprocessen aan te sturen, het systeem te configureren en referentiegegevens te leveren.
Maar perfect realistische omgevingen zijn meestal onpraktisch of veel te duur (zelfs testers van systemen met een hoge kritikaliteit, zoals vliegtuigen, kernreactoren of hersenscanners, moeten op een gegeven moment concessies doen). Bijna alle tests vinden plaats in omgevingen die de echte wereld simuleren met een bepaald aanvaardbaar compromisniveau.
Auto's worden getest op rollenbanken, in windtunnels, op trilbanken en op privétestbanen voordat ze op de openbare weg worden getest. Computersystemen worden in softwarelaboratoria door programmeurs en softwaretesters getest voordat eindgebruikers worden ingeschakeld om ze uit te proberen in een productieachtige omgeving.
Om ervoor te zorgen dat je testomgevingen aan de industrienormen voldoen, kun je overwegen een van deze best beoordeelde testbeheerplatforms te integreren.
Testen in realistische omgevingen
Gesimuleerde omgevingen zijn feilbaar, net als onze vereisten en testmodellen, maar daar moeten we mee leven.
We moeten tests opzetten die betekenisvol zijn in de omgevingen die voor ons beschikbaar zijn, en testresultaten betekenen wat wij interpreteren dat ze betekenen.
De betrouwbaarheid van testresultaten hangt af van de omgeving waarin de tests worden uitgevoerd. Als een test wordt uitgevoerd in een omgeving die onjuist is ingesteld:
- Een test die mislukt, kan erop wijzen dat het systeem defect is, terwijl het in werkelijkheid correct is.
- Een test die slaagt, kan erop wijzen dat het systeem correct is, terwijl het in werkelijkheid defect is.
Beide situaties zijn natuurlijk zeer ongewenst.
Omgevingen tijdig instellen en opleveren
Zelfs met de opkomst van cloudinfrastructuur kunnen testomgevingen moeilijk en duur zijn om in te stellen en te onderhouden.
Wanneer ondersteuningsteams aan de nieuwe productieomgeving werken, eisen testers testomgevingen (en misschien meerdere daarvan). Later tijdens het testen hebben ondersteuningsteams vaak concurrerende prioriteiten.
Ontwikkelomgevingen of een latere testactiviteit kunnen te laat of helemaal niet worden opgeleverd, of ze zijn mogelijk niet geconfigureerd of beheerd zoals vereist. Dit zal onvermijdelijk het testen vertragen en/of het vertrouwen in een testresultaat ondermijnen.
Een kritieke taak is om de behoefte aan en vereisten voor een omgeving die voor testen wordt gebruikt vast te stellen, inclusief een mechanisme voor het beheren van wijzigingen in die omgeving—zo snel mogelijk.
Infrastructuur als code is een recente ontwikkeling in de manier waarop omgevingen kunnen worden geconstrueerd, met tools die procedures volgen en declaratieve code gebruiken om de inrichting van de omgeving te definiëren.
Hoewel basisplatforms voor besturingssystemen (servers) eenvoudig in de cloud of als virtuele machines in uw eigen omgeving kunnen worden gemaakt, vergen volledig gespecificeerde servers voor speciale doeleinden met alle vereiste software, gegevens, configuraties en interfaces meer inspanning.
Bij het instellen van uw testinfrastructuur is het cruciaal om betrouwbare software voor databasebeheer te integreren voor optimale prestaties
Zodra ze zijn ingesteld, bieden ze echter een zeer efficiënte manier om omgevingen te creëren. Infrastructuurcode kan net als applicatiecode onder versiebeheer worden geplaatst en via wijzigingen worden beheerd.
Een belangrijk uitgangspunt van continue levering is dat er zo snel mogelijk software—zelfs als die niets nuttigs doet—door de leveringspijplijn moet worden gestuurd om te bewijzen dat de processen werken.
Hiervoor zijn uiteraard geschikte omgevingen nodig voor builds, tools voor continue integratie, testen op systeemniveau en implementatie. Het doel is om test- en productieomgevingen zonder beperkingen te implementeren. Zodra de omgevingsdefinities en implementatieprocessen aanwezig zijn, wordt het genereren van omgevingen een geautomatiseerde en routinematige taak.
Onder alle omstandigheden zijn de definities van deze omgevingen een vroege oplevering van het project.
Ontwikkelomgevingen
Testen door ontwikkelaars richt zich op het construeren van softwarecomponenten die functies intern in de applicatie of op de gebruikers- of presentatielaag leveren.
Tests worden doorgaans gestuurd door kennis van de interne structuur van de code en maken mogelijk geen gebruik van ‘realistische’ gegevens of vereisen deze niet om te worden uitgevoerd. Tests van componenten of services op laag niveau worden meestal via een API uitgevoerd met behulp van speciaal gebouwde of propriëtaire stuurprogramma's of tools.
Het aanbod aan ontwikkeltools, platforms en zogenaamde geïntegreerde ontwikkelomgevingen (IDEs) is enorm. In dit artikel kunnen we slechts enkele van de belangrijkste testgerelateerde vereisten en functies van omgevingen bespreken.
Om de ontwikkeling en het testen binnen de scope van ontwikkelaars te ondersteunen, moeten omgevingen de volgende activiteiten ondersteunen. Dit is slechts een selectie—afhankelijk van uw situatie kunnen er aanvullende activiteiten zijn of variaties op deze activiteiten:
- Een ‘Sandboxomgeving’ om met nieuwe software te experimenteren. Sandboxes worden vaak gebruikt om nieuwe bibliotheken te testen, wegwerpprototypecode te ontwikkelen of programmeertechnieken te oefenen. Alle gangbare programmeertalen hebben honderden of duizenden softwarebibliotheken. Sandboxes worden gebruikt om software te installeren en te testen die nog geen onderdeel is van de hoofdstroom van de ontwikkeling, om deze te evalueren en ermee te leren werken. Deze omgevingen kunnen worden beschouwd als wegwerptomgevingen.
- Lokale ontwikkelomgeving. Hier onderhouden ontwikkelaars een lokale kopie van een deel van of alle broncode voor hun applicatie vanuit een gedeelde coderepository en kunnen ze systeembuilds maken voor lokaal testen. In deze omgeving kunnen ontwikkelaars wijzigingen aanbrengen in de code in hun lokale kopie en hun wijzigingen testen. Sommige tests zijn ad-hoc en worden misschien nooit herhaald. Andere tests zijn geautomatiseerd. Geautomatiseerde tests worden doorgaans altijd behouden, vooral als ze een testgestuurde aanpak volgen.
- Gedeelde omgeving voor (continue) integratie. Wanneer ontwikkelaars erop vertrouwen dat hun code klaar is, sturen ze hun wijzigingen naar de gedeelde, beheerde coderepository. De CI-omgeving voert geautomatiseerde builds uit en voert geautomatiseerde tests uit met behulp van de repository. Op dit punt is de nieuwe of gewijzigde code geïntegreerd en getest. Het CI-systeem voert op verzoek, elk uur of dagelijks geautomatiseerde tests uit, en het hele team ontvangt meldingen en kan de teststatus van de laatst geïntegreerde build bekijken. Fouten worden snel zichtbaar gemaakt en met de hoogste prioriteit aangepakt.
Een ontwikkel- of CI-omgeving ondersteunt het testen door ontwikkelaars, maar andere applicatieservers, webservices, berichtenservices of databaseservers die het systeem completeren, zijn mogelijk niet beschikbaar.
Als deze interfacesystemen niet bestaan omdat ze nog niet zijn gebouwd, of omdat ze eigendom zijn van een partnerbedrijf en er alleen een live systeem en geen testversie is, moeten ontwikkelaars deze interfaces stubben of mocken om hun eigen code op zijn minst te kunnen testen.
Mockingtools kunnen geavanceerd zijn, maar gemockte interfaces kunnen doorgaans geen tests ondersteunen waarvoor geïntegreerde gegevens uit meerdere systemen nodig zijn.
Als er voor ontwikkelaars een interface naar een testdatabaseserver beschikbaar is, zijn hun testgegevens mogelijk minimaal, niet geïntegreerd of consistent, en niet representatief voor productiegegevens.
Ontwikkeldatabases die door een team worden gedeeld, zijn doorgaans onbevredigend. Als er geen goed beleid is voor het beheer van deze gedeelde bron, kunnen ontwikkelaars elkaars gegevens opnieuw gebruiken, beschadigen of verwijderen.
Testomgevingen op systeemniveau
Testen op systeemniveau richt zich op de integratie van componenten en subsystemen in samenwerking.
Deze omgevingen bieden een platform ter ondersteuning van de doelstellingen van grootschaligere integratie, functievalidering en systeembeheer in de context van gebruikers- of bedrijfsprocessen.
Omgevingen kunnen ook worden gereserveerd voor de niet-functionele aspecten van het systeem, zoals prestaties, beveiliging of servicemanagement.
Een van de meest voorkomende valkuilen bij het testen ontstaat wanneer een systeemtester in zijn omgeving een bepaalde fout ervaart, maar de ontwikkelaar of tester de fout, hoe hard die ook probeert, niet kan reproduceren in de ontwikkelomgeving.
“Het werkt op mijn machine!”
“Ja, natuurlijk werkt het dat.”
Dit wordt vrijwel zeker veroorzaakt door een gebrek aan consistentie tussen de twee omgevingen. Het verschil in gedrag kan worden veroorzaakt door de configuratie, verschillen in softwareversies of een verschil in de gegevens in de database.
Verschillen in gegevens die problemen veroorzaken, zijn het eerste wat moet worden gecontroleerd. Ze zijn doorgaans gemakkelijk te identificeren en kunnen vaak snel worden opgelost.
Wanneer er sprake is van een verschil in softwareversie of configuratie, kunnen testers en ontwikkelaars veel tijd verspillen aan het achterhalen van de oorzaak van het verschil in gedrag.
Wanneer deze problemen optreden, betekent dit vaak dat er een communicatiestoring is tussen de ontwikkelaar en de testomgeving. Het kan ook wijzen op een verlies van configuratiebeheer in de inrichting van de ontwikkel- of testomgeving of in het implementatieproces.
Infrastructuur als code en geautomatiseerde inrichting van omgevingen zullen problemen met de consistentie van omgevingen tot het verleden laten behoren.
Typen speciale testomgevingen
Ter ondersteuning van systeemtests, acceptatietests en niet-functionele tests moeten omgevingen de volgende activiteiten ondersteunen (mogelijk zijn er meer binnen jouw organisatie):
- (Functionele) systeemtestomgeving. In deze omgeving wordt het systeem gevalideerd aan de hand van de vereisten die voor het systeem als geheel zijn gedocumenteerd. Vereisten kunnen grote tekstdocumenten zijn met getabelleerde testgevallen die voor een systeemtest zijn gedefinieerd. In agileprojecten kan deze omgeving nodig zijn om testers het geïntegreerde systeem te laten verkennen zonder hen te beperken tot specifieke functies.
- Omgeving voor end-to-endtests. Waar de CI-omgeving het mogelijk maakt om componenten met subsystemen te integreren, kunnen de bedrijfsprocessen vereisen dat andere interfacesystemen (die niet onder controle van ontwikkelaars staan) beschikbaar zijn. Om integratie op grote schaal, bedrijfsprocessen of algemene acceptatietests uit te voeren, zijn omgevingen met een volledige scope nodig. Doorgaans zijn de gegevens een kopie van de productiegegevens, of op zijn minst van een passende omvang. Wanneer integratie op grote schaal moet worden bewezen, worden de gegevens- en besturingsstromen getest met behulp van langere gebruikersreizen en onafhankelijke afstemmingen van de gegevens in de geïntegreerde systemen. Gegevensbeheer in testomgevingen is cruciaal. Als je Jira al gebruikt, kun je overwegen je mogelijkheden voor gegevensbeheer uit te breiden met geavanceerde testbeheertools die voor Jira zijn ontworpen.
- Prestatieomgeving. Deze omgevingen moeten een zinvol platform bieden voor het evalueren van de prestaties van een systeem (of geselecteerde subsystemen). In de architectuur kunnen compromissen mogelijk zijn wanneer er sprake is van redundantie of het klonen van servers. De gegevensvolumes moeten echter de omvang van productie hebben, zelfs als de gegevens synthetisch zijn. De omgeving moet uiteraard voldoende schaal hebben om productievolumes aan transacties te ondersteunen, zodat de prestaties van systemen in productie nuttig kunnen worden voorspeld.
- Omgevingen voor beschikbaarheid, veerkracht en beheerbaarheid (ARM). In sommige opzichten lijken deze omgevingen op prestatieomgevingen, maar afhankelijk van het testdoel kunnen variaties onvermijdelijk zijn. Beschikbaarheidstests zijn bedoeld om te verifiëren dat het systeem gedurende langere perioden kan werken zonder uit te vallen. Veerkrachttests (vaak failovertests genoemd) controleren of het uitvallen van systeemcomponenten geen onaanvaardbare verstoring veroorzaakt van de geleverde service. Beheerbaarheids- of operationele tests zijn bedoeld om aan te tonen dat administratieve procedures, beheerprocedures en procedures voor back-up en herstel van het systeem effectief werken.
Gegevens in omgevingen
In sommige zeer grote projecten kunnen er wel 20 of zelfs 30 grootschalige omgevingen zijn die zijn gewijd aan verschillende aspecten van testen, training, gegevensmigratie en proefmatige omschakelingen. In kleinere projecten zijn er minder omgevingen, misschien slechts één gedeelde omgeving of een regime voor continue levering — en alle tests kunnen automatisch worden uitgevoerd in omgevingen die voor eenmalig gebruik worden geïnstantieerd en daarna weer worden afgebroken.
Alle omgevingen hebben gegevens nodig, maar de omvang en mate van realisme van die gegevens kunnen variëren. Hieronder staan enkele veelvoorkomende patronen in de manier waarop testgegevens worden verkregen en beheerd. Deze patronen richten zich op eigenaarschap (lokaal of gedeeld), de manier waarop de gegevens worden aangemaakt (handmatig, geautomatiseerd of gekopieerd uit productie) en de schaal:
- Lokale, handmatig aangemaakte gegevens op kleine schaal — geschikt voor ad-hoctests door ontwikkelaars of testers.
- Lokale, automatisch aangemaakte synthetische gegevens. Geschikt voor geautomatiseerde tests door ontwikkelaars of omgevingen waarin de functionaliteit van specifieke modules of functies kan worden afgedekt.
- Gedeelde, handmatig aangemaakte gegevens. Gebruikt in integratie- en systeemtestomgevingen, vaak wanneer testgegevens zich parallel aan handmatig uitgevoerde tests hebben ontwikkeld. Er wordt indien nodig een back-up van gemaakt en deze wordt teruggezet.
- Gedeelde, automatisch aangemaakte gegevens. Gebruikt in integratie- en systeemtestomgevingen waarin testgegevens zich parallel aan geautomatiseerde of handmatig uitgevoerde tests hebben ontwikkeld. De gegevens worden gegenereerd en/of indien nodig uit back-ups teruggezet.
- Gedeelde grootschalige synthetische/willekeurige gegevens. Voor prestatie- en ARM-tests zijn samenhangende gegevens in grote hoeveelheden nodig. Deze gegevens hoeven doorgaans niet betekenisvol te zijn — willekeurige gegevens werken prima en worden gegenereerd wanneer dat nodig is, of aanvankelijk gegenereerd en vanuit back-ups teruggezet.
- Gedeelde grootschalige betekenisvolle gegevens. Voor end-to-endtests, acceptatietests of gebruikerstests zijn doorgaans betekenisvolle gegevens op schaal nodig. Soms worden kopieën of extracten van livegegevens gebruikt. Let er echter op dat je niet in strijd handelt met regelgeving omtrent gegevens als je de gegevens niet door elkaar haalt of anonimiseert.
- Hertesten en regressietesten. Je hebt een bekende, gecontroleerde gegevensset in een bekende toestand nodig, dus deze wordt doorgaans vanuit back-ups teruggezet. Dit geldt voor elk van de bovenstaande omgevingen, omdat deze tests opnieuw moeten worden uitgevoerd met gegevens in een bekende toestand om fouten betrouwbaar te reproduceren.
Infrastructuurtests
Aan het begin van dit artikel hebben we bekeken wat infrastructuur omvat en sindsdien hebben we ons voornamelijk gericht op de technische componenten, namelijk de softwaresystemen, en zijn we ervan uitgegaan dat de hardware — fysiek of virtueel — beschikbaar is.
Wanneer we systemen aanvankelijk bouwen, gaan we ervan uit dat de infrastructuur bestaat en correct functioneert, goede prestaties levert, veilig en veerkrachtig is, enzovoort.
We kunnen al deze aspecten testen wanneer we onze applicatie hebben geïntegreerd, en ongetwijfeld tekortkomingen in de infrastructuur in een relatief late fase van onze projecten aan het licht brengen. Maar het ontdekken van infrastructuurproblemen in zo'n late projectfase is meestal uiterst verstorend.
- Wijzigingen om storingen in de infrastructuur op te lossen, kunnen een ingrijpend herontwerp en aanpassingen in onze applicatie vereisen.
- Resultaten van tests van onze applicatie of van het volledige systeem moeten opnieuw worden uitgevoerd.
- Als componenten van derden, zoals database-, web-, netwerk- of berichtendiensten, uitvallen, zijn we overgeleverd aan de leveranciers (of de opensourcegemeenschap) die deze ondersteunen.
Om ervoor te zorgen dat ons vertrouwen in infrastructuurcomponenten goed onderbouwd is, kunnen we ons baseren op onze eigen ervaring (of die van anderen) met het gebruik ervan in het verleden. Of we moeten hun betrouwbaarheid vóór onze toezegging om ze te gebruiken bij het ontwerp en de bouw van ons systeem door middel van tests beoordelen.
Afhankelijk van de infrastructuur die wordt onderzocht, kan de omgeving die we gebruiken variëren van één server tot een vrijwel volledig infrastructuurplatform.
Hoewel sommige tests handmatig zullen worden uitgevoerd, zullen we meestal tools, stuurprogramma's of robots gebruiken om de transactielast te simuleren die onze applicatie zou genereren. We zouden deze interfaces moeten nabootsen of van stubs moeten voorzien:
- Interfaces die momenteel niet beschikbaar zijn
- Interfaces naar componenten die we vertrouwen en die eenvoudig te simuleren zijn
- Interfaces die buiten de scope vallen en geen invloed hebben op de infrastructuur die wordt getest.
Infrastructuur werkt doorgaans, vanzelfsprekend, niet via een gebruikersinterface of GUI.
De integratie van onze applicatie met de infrastructuur zal voornamelijk de vorm aannemen van berichtenverkeer of aanroepen van externe diensten. Vaak vereist het te simuleren verkeer API-aanroepen naar web- of applicatieservers, bericht- of databaseservers, of diensten die via de cloud of vanaf externe locaties worden geleverd.
Prestatie- en ARM-doelstellingen zijn mogelijk bekend; in dat geval kunnen tests worden uitgevoerd om te controleren of aan deze doelstellingen wordt voldaan.
De infrastructuur wordt echter vaak gedeeld met andere applicaties dan die van ons. Inzicht in de uiteindelijke capaciteit helpt daarom om in te schatten hoeveel capaciteit overblijft wanneer onze applicatie wordt geïmplementeerd.
In dit geval richt infrastructuurtesten zich op het risico voor onze eigen applicaties en wellicht voor andere applicaties die er in de toekomst op worden gebaseerd.
Schrijf je in voor de nieuwsbrief van The QA Lead om een melding te ontvangen wanneer nieuwe delen van de reeks online komen. 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 voor $60 korting op de volledige cursusprijs!
Aanbevolen om te lezen: 10 BESTE OPENSOURCEHULPMIDDELEN VOOR TESTBEHEER
