{"id":27702,"date":"2024-05-29T14:41:51","date_gmt":"2024-05-29T12:41:51","guid":{"rendered":"https:\/\/www.solvinity.com\/?post_type=blog&p=27702"},"modified":"2025-06-19T13:30:02","modified_gmt":"2025-06-19T11:30:02","slug":"software-ontwikkelen-voor-infrastructuur","status":"publish","type":"blog","link":"https:\/\/www.solvinity.com\/nl\/blog\/software-ontwikkelen-voor-infrastructuur\/","title":{"rendered":"Software ontwikkelen voor infrastructuur"},"content":{"rendered":"

\"De<\/a><\/p>\n\t\t

\n\t\t\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t

<\/i> Home<\/span><\/a><\/span><\/span><\/p>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t

\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t
<\/div>\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t
\n\t\t\t
<\/div>\n\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t
\"\"
\n Vincent van Beek<\/span>\n Hoofd Software Engineering en Distinguished Engineer<\/span>\n <\/div>\n <\/div>\n <\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t29 mei 2024\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t
Blogs<\/a><\/div>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t

Software ontwikkelen voor infrastructuur<\/h1>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Het idee over hoe je software ontwikkelt, is in de loop der tijd erg veranderd. Voorheen ging dit volgens de watervalmethodiek, waarbij trapsgewijs van de ene fase naar de andere fase werd gegaan. Daarbij startte ontwikkelaars vanuit een heel uitgebreid ontwerp waarbij pas aan het einde werd gestart met testen. Op een gegeven moment ontdekte men echter dat deze manier van software ontwikkelen nooit leidde tot iets wat een eindklant echt wilde hebben. Bovendien duurden die processen eindeloos lang.<\/strong><\/p>

Hieruit is de agile beweging ontstaan. Door te proberen de scope zo klein mogelijk te houden en te bedenken wat een eindklant echt wil, kan eerst een klein gedeelte gebouwd worden en daarop worden voortgebouwd. Zo ontwikkelen we tegenwoordig vanuit een eerste bouwsteen steeds complexere software. Daarbij zijn twee technieken essentieel om goed werkende software te maken. Test Driven Development (TDD) – waarbij de ontwikkelaars starten met het ontwikkelen van kleine units software – en de Behaviour Driven Development (BDD)-aanpak. Bij Behaviour Driven Development start het bij het vastleggen van de requirements in een voor stakeholders leesbare taal.<\/p>

En dat is best een grote uitdaging. Als je software ontwikkelt, schrijf je dat namelijk op als logica. Alles wordt een expliciete keuze. Waar iets op het scherm moet komen te staan of waar en welke waardes in een veld ingevuld mogen worden. Door dit van tevoren duidelijk vast te stellen maakt de BDD-aanpak een betere samenwerking en communicatie mogelijk tussen alle belanghebbenden van een project.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t

\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t
\n\t\t\t\t\t\t\t
\u201cHet zorgt voor meer automatisering, waarbij kwaliteitsborging zoveel mogelijk naar voren wordt gehaald\u201d<\/div>\n\t\t\t\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\t\t
\n\t\t\t\t\t\t\t\"\"\t\t\t\t\t\t<\/div>\n\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t

Shift-Left<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

De BDD-aanpak heeft ook veel impact gehad op hoe het testproces eruitziet. De ontwikkelcycli zijn korter waardoor nieuwe handvatten nodig waren om de kwaliteit te borgen. En testen is essentieel om ervoor te zorgen dat de software klopt. Want hoewel wij meer complexe software ontwikkelen voor complexe problemen, zoals het automatiseren van processen in de IT-infrastructuur, hebben mensen hetzelfde verwachtingspatroon als bij reguliere applicaties: dat het gewoon altijd werkt. Maar dat is in een complexe omgeving vaak wel wat ingewikkelder. Het blijft gewoon mensenwerk.<\/p>

De <\/span>BDD<\/span>-aanpak<\/span> maakt het mogelijk om het testproces effectief naar links te schuiven, shift-<\/span>left<\/span> testen. <\/span>Bij deze<\/span> benadering <\/span>begint <\/span>testen eerder in de levenscyclus van productontwikkeling. Het zorgt voor meer automatisering, waarbij <\/span>kwaliteitsborging<\/span> zoveel mogelijk naar voren wordt gehaald. <\/span>Hierdoor<\/span> worden defecten in een <\/span>vroeger <\/span>stadium ontdekt<\/span> en<\/span> verholpen door parallel met het ontwikkelingsteam te werken.<\/span> Het voorkomt bovendien dataverlies en haalt ook de security en compliance naar voren. <\/span>En dat is goed nieuws want <\/span>hoe later in het proces er re<\/span>–<\/span>work nodig is of er incidenten zijn, hoe duurder een traject wordt.\u00a0<\/span><\/span>\u00a0<\/span>\u00a0<\/span><\/p>

Testen vindt dus niet alleen plaats aan het eind van het ontwikkelproces (unit test)<\/em>, maar ook tijdens het schrijven van code (code review)<\/em> en op vele andere momenten in het leveringsproces. Zo zijn er onder andere integratietesten, loadtesten, acceptatietesten, testen voor specifieke gebruikersgroepen of securitytesten. Al onze code wordt bijvoorbeeld getest door Securify<\/a>. Zij checken de code op security aspecten en analyseren welk stukje code het grootste risico met zich meebrengt bij een wijziging.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t

Taal<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Het belangrijkste is dat BDD gebruikmaakt van een gemeenschappelijke taal, gebaseerd op eenvoudige en gestructureerde zinnen. Voor testen betekent dit dat zij beschrijven wat je wilt dat er als output komt, als je weet wat je er als input in stopt. Onze stakeholders zijn meestal IT-architecten. Als er een feature wordt bedacht, moeten zij snappen hoe dat getest gaat worden. Als zij die test kunnen lezen en begrijpen, kunnen zij meedenken en aangeven of dit inderdaad is wat zij willen hebben.<\/p>

Daarvoor doorlopen wij heel gestructureerd verschillende stappen in projecten. Voor een klant bouwen wij bijvoorbeeld een private cloudplatform, waar twee verschillende organisatieonderdelen op dezelfde hardware in het datacenter draaien, maar virtueel strikt gescheiden moeten zijn. Om deze omgeving voor de klant te ontsluiten is een serviceportaal ontwikkeld met een standaardproduct van VMware, wat is uitgebreid met verschillende andere functionaliteiten van andere leveranciers. Via software van ons kunnen deze applicaties berichten met elkaar uitwisselen.<\/p>

Om daar grip op te krijgen en <\/span>om dit te kunnen testen, moet je eerst heel goed weten hoe je <\/span>requirements<\/span> op moet schrijven. Deze worden g<\/span>eschreven <\/span>i<\/span>n <\/span>een <\/span>framework<\/span>, want je hebt harde kaders nodig<\/span>, <\/span>waarin drie fases te onderscheiden zijn<\/span>: <\/span>business <\/span>value<\/span>, <\/span>acceptance<\/span> criteria en non <\/span>functional<\/span> requirements<\/span>. <\/span>Het opstellen van de <\/span>functionele <\/span>requirements<\/span> start met het uitsplitsen van drie belangrijke componenten. Waarom bouw je iets, wat is de waarde en context, waarvoor bouw je iets (wat moet het doen?) en voor wie? Dat ziet er als volgt uit: Als een [functienaam], wil ik [<\/span>deze <\/span>feature], zodat [benefit].<\/span><\/span>\u00a0<\/span><\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t

\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t
\n\t\t\t\t\t\t\t
\"Want achter de functionele wereld gaat nog een hele wereld schuil\"<\/div>\n\t\t\t\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\t\t
\n\t\t\t\t\t\t\t\"\"\t\t\t\t\t\t<\/div>\n\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t

Testen<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

In de volgende fase stellen we vervolgens acceptatiecriteria op hoe elke stap moet worden doorlopen. Gegeven deze situatie wil ik dat als dit gebeurt, er deze uitkomst uitkomt. Naast functionele requirements zijn er bovendien ook non-functionele requirements. Want achter de functionele wereld gaat nog een hele wereld schuil. We kijken dus heel concreet naar hoeveel impact bepaalde gebeurtenissen hebben op de performance, of er schalingsproblemen te verwachten zijn en wat een klant van ons verwacht.<\/p>

Pas daarna kunnen we gaan testen. Daarin zijn <\/span>in deze casus <\/span>vier lagen te onderscheiden: unit tests, integratietesten, systeemtesten en end<\/span>–<\/span>to<\/span>-end<\/span> testen<\/span>. Gestart wordt met <\/span>het testen op functieniveau, daarna <\/span>kom je uit op integratieniveau want alle kleine stukjes software samen, moeten ook functioneren. <\/span>Dit gaat uiteraard volledig geautomatiseerd. <\/span>Na de <\/span>systeemtesten <\/span>komen we dan uiteindelijk uit bij de end<\/span>–<\/span>to<\/span>–<\/span>end testen<\/span>. <\/span>En dat is waar het bij <\/span>Behaviour<\/span> Driven<\/span> Design uiteindelijk om draait<\/span>. Als je <\/span>alles bij elkaar zet en met elkaar verbindt, wat moet het dan doen voor de klant?\u00a0<\/span><\/span>\u00a0<\/span><\/p>

Naast dat je alle testen runt, moeten er nog wel meer dingen gebeuren, voordat je kunt zeggen dat een stuk functionaliteit echt af is. Daarvoor gebruiken we de Definition of Done checklist.<\/span>\u00a0<\/span><\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t

\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t

Resultaat<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Het voordeel van deze werkwijze ten opzichte van alleen geschreven documentatie is dat je door de tests uit te voeren, kunt checken of je documentatie klopt. Bovendien kunnen wij een stuk dashboarding en reporting teruggeven aan de klant. Als wij die hele testsuite uitrollen kunnen zij zien waar eventueel een bug is ge\u00efdentificeerd of hoe lang tests hebben geduurd. Het zorgt voor transparantie, want de essentie van testen is dat wij moeten \u00e9n willen bewijzen dat wat wij hebben ontwikkeld, doet wat in de requirements staat.<\/p>

Alle voorgaande stappen hebben invloed op het daadwerkelijk op te leveren eindproduct. De sleutel tot succes daarbij is dat je bij het maken en testen van software van tevoren goed checkt of je wel dezelfde taal spreekt.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t

\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\"\"\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t

Meld je aan voor de Solvinity Nieuwsbrief<\/h4>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t
Ontvang het laatste nieuws, blogs, artikelen en events. <\/h6>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t