Hoi, ik ben Christopher Berling.

Het NOS-bericht over ernstige beveiligingslekken in PHP ↗ trok direct mijn aandacht. Ik volg ontwikkelingen in softwarekwaliteit met interesse, maar dit onderwerp staat ook dicht bij mijn eigen praktijk: dit testportfolio draait deels op PHP en wordt op mijn eigen NAS gehost.

Ik leer op deze site niet alleen hoe ik functies bouw en test, maar ook wat het betekent om software te beheren. Een website kan prima reageren op de knoppen en formulieren, terwijl er onderliggend onderhoud nodig is. Dat onderscheid vind ik belangrijk.

Wat is er aangekondigd?

Het PHP-beveiligingsteam kondigde op 20 oktober een beveiligingsrelease aan voor twee kritieke kwetsbaarheden, beide met een CVSS v4.0-score van 9,2. De aangekondigde publicatietijd was 21 oktober om 14:00 UTC, oftewel 16:00 Nederlandse tijd. In die vooraankondiging werden de technische details, getroffen versies en gerepareerde versies nog niet volledig gegeven.

Een aangekondigde reparatie is iets anders dan een geïnstalleerde reparatie. Voor een beheerder blijft de vraag welke software daadwerkelijk draait en welke update voor die omgeving beschikbaar is. Daarom zijn de officiële PHP-informatie en de berichten van de leverancier van het hostingplatform belangrijker dan een losse conclusie op basis van een krantenkop.

Stand van dit artikel: 21 oktober 2026, gebaseerd op de geraadpleegde vooraankondiging en het CERT-EU-advies. Dit artikel is geen live overzicht van patchstatussen. Raadpleeg voor latere informatie de actuele bronnen onderaan.

PHP wordt relatief minder gebruikt, maar blijft groot

W3Techs laat tussen 1 oktober 2025 en 21 oktober 2026 een daling voor PHP zien, van 73,4% naar 69,3%. JavaScript stijgt in dezelfde meetreeks van 5,0% naar 8,1% en Ruby van 6,4% naar 7,1%.

Dit betreft websites waarvan W3Techs de servertaal kan herkennen. Het is geen meting van alle software, ontwikkelaars of vacatures; een website kan meerdere talen gebruiken. Een kleiner relatief aandeel bewijst ook niet dat het absolute aantal PHP-websites daalt. De cijfers leggen geen oorzakelijk verband met deze beveiligingsmelding.

Wat betekent dit voor mijn eigen testportfolio?

PHP verzorgt op mijn site onder meer servercontroles, portaalfuncties en het verwerken van aanvragen. Dat betekent dat ik ook de PHP-runtime en het platform waarop die draait moet onderhouden. Alleen de broncode van mijn website bijwerken is daarvoor niet voldoende.

Mijn site gebruikt onder meer aanmeldcontrole en CSRF-tokens. Dat zijn nuttige maatregelen voor de applicatie, maar ze repareren geen kwetsbaarheid in PHP zelf. Ook het feit dat mijn website geen database heeft, neemt het risico van een kwetsbare serverruntime niet weg.

Of mijn concrete omgeving door dit specifieke probleem wordt geraakt, kan ik niet afleiden uit de titel van het nieuwsbericht of uit een geslaagde browsertest. Daarvoor moet ik de actieve PHP-versie, het gebruikte pakket en de relevante leveranciersinformatie naast elkaar leggen. In dit artikel geef ik daarom geen ongecontroleerde verklaring dat mijn omgeving veilig of juist aantoonbaar kwetsbaar is.

Een leerpunt voor mijn portfolio

Een dalend gebruiksaandeel of een beveiligingsmelding maakt een taal voor mij niet automatisch ongeschikt. Het zet wel aan tot kritisch kijken: is de omgeving ondersteund, kan ik tijdig bijwerken en kan ik onderbouwen wat ik heb gecontroleerd? Een overstap naar een andere taal brengt bovendien eigen afhankelijkheden en onderhoud met zich mee.

Dat sluit aan bij wat ik met dit portfolio wil laten zien. Softwarekwaliteit gaat verder dan geslaagde testgevallen. Ook versiebeheer, onderhoud, betrouwbare bronnen en het herkennen van de grenzen van je eigen controles horen erbij. Dit nieuws is voor mij een concrete aanleiding om die verantwoordelijkheid serieus te nemen.

Op dinsdag 20 oktober bezocht ik TechEx Europe in de RAI Amsterdam. Het evenement duurde twee dagen, maar ik heb de eerste dag overgeslagen en ben alleen op dag 2 geweest. Dit verslag gaat dus over mijn bezoek op die dinsdag.

Als Senior Test Engineer met een focus op testautomatisering kijk ik graag verder dan mijn eigen specialisme. Softwareontwikkeling, architectuur, AI, integratie, infrastructuur en hardware maken allemaal deel uit van dezelfde IT-wereld. TechEx was voor mij een mooie gelegenheid om die samenhang te verkennen, demonstraties te bekijken en met mensen bij de stands in gesprek te gaan.

Veel technologie, steeds meer samenhang

TechEx brengt verschillende technologiegebieden samen, van AI en cybersecurity tot IoT, automatisering en data-infrastructuur. Juist die combinatie sprak me aan. Tijdens mijn rondgang zag ik hoe AI steeds vaker onderdeel is van bestaande producten en processen: niet alleen bij softwareontwikkeling, maar ook bij gegevensverwerking, infrastructuur en fysieke robots.

Mijn belangrijkste indruk: nieuwe mogelijkheden krijgen pas waarde als de basis klopt. Je hebt betrouwbare gegevens, voldoende context, goede integraties en een veilige infrastructuur nodig. Dat zijn onderwerpen die ook vanuit softwarekwaliteit interessant blijven.

Mijn hoogtepunt: Spectrum

De kennismaking met Spectrum, dat ik bij de JetBrains Innovation Hub tegenkwam, bleef me het meest bij. Het idee is een levende kennisbank voor een softwareproject: informatie uit code, documenten en issues wordt met elkaar verbonden en bijgehouden. Daarmee wil Spectrum teams én AI-agents helpen om een systeem beter te begrijpen.

Dat herken ik als een relevant vraagstuk. Requirements, technische keuzes, architectuur en de daadwerkelijke implementatie staan vaak op verschillende plekken. Daardoor kost het tijd om te achterhalen hoe iets werkt, waarom het zo gebouwd is en wat een wijziging kan raken.

Ik zie mogelijke toepassingen bij impactanalyses en het uitwerken van testscenario’s. Als de verbanden tussen requirements, ontwerp en implementatie beter zichtbaar worden, kan dat helpen om gerichter vragen te stellen en controles te kiezen. Dat is voor mij een interessante mogelijkheid, nog geen bewezen uitkomst.

Bij de stand heb ik hierover gesproken. We hebben afgesproken dat ik informatie of demogegevens ontvang, zodat ik Spectrum zelf kan uitproberen. Daar ben ik benieuwd naar: hoe actueel en betrouwbaar is het kennismodel, hoe zijn antwoorden onderbouwd en wat voegt het toe bij een bestaand softwareproject? Mijn enthousiasme gaat over het concept; de praktische beoordeling moet nog volgen.

Van inspiratie op de beurs naar mijn eigen testportfolio

Na mijn bezoek werd steeds duidelijker waarom Spectrum me zo aanspreekt. Ook op mijn eigen website wil ik de samenhang tussen software, tests, beheer en documentatie beter zichtbaar houden. De site is mijn testportfolio én mijn leeromgeving. Naarmate die groeit, wil ik kunnen nagaan of de uitleg nog overeenkomt met de software die daadwerkelijk draait.

Die kennismaking heeft me geïnspireerd om geautomatiseerd documentatiebeheer te gaan verkennen. Mijn idee: een dagelijkse taak op mijn NAS die met scripts controleert welke documenten mogelijk verouderd zijn. Denk aan een gewijzigde bestandsnaam, een aangepaste instelling of een beschrijving van een functie die inmiddels anders werkt.

De stands · Boomi, Oracle, MOKOSmart en Cloudflare

Boomi: terug bij een bekend platform

Bij Boomi ben ik bewust langsgegaan, omdat ik in het verleden met het platform heb gewerkt. Boomi biedt een integratieplatform waarmee applicaties, systemen en databronnen gekoppeld kunnen worden: een Integration Platform as a Service, of iPaaS.

Het was interessant om opnieuw kennis te maken met het platform en te zien hoe onderwerpen als API-management, gegevensbeheer en AI terugkomen in het aanbod. In een landschap met veel verschillende systemen blijft de vraag hoe die systemen betrouwbaar samenwerken. Juist die verbinding tussen onderdelen vind ik boeiend.

Oracle: data en context voor AI

Ook bezocht ik Oracle. Bij de stand zag ik materiaal over het Oracle AI Data Platform en het belang van bedrijfscontext bij AI. Voor mij raakt dat aan een eenvoudige maar belangrijke vraag: hoe bruikbaar is een AI-toepassing als de onderliggende informatie onbetrouwbaar is of de context ontbreekt?

Ik vond het interessant om vanuit die invalshoek naar data, cloud en AI te kijken. De technische mogelijkheden zijn groot, maar de aansluiting op processen en bestaande IT-landschappen bepaalt mede de praktische waarde.

MOKOSmart: de fysieke wereld als gegevensbron

MOKOSmart trok mijn aandacht met IoT-technologie, zoals sensoren, Bluetooth-beacons, trackers en gateways. Daarmee worden fysieke objecten en omgevingen verbonden met digitale systemen. Denk aan het volgen van bedrijfsmiddelen of het meten van temperatuur en luchtvochtigheid.

Daar komen andere vragen bij kijken dan bij een scherm of een losse API: wat gebeurt er als de verbinding wegvalt, hoe betrouwbaar zijn metingen en hoe gaan apparaten om met energieverbruik? De combinatie van hardware, netwerken, software en gegevens laat mooi zien hoe breed IT is.

Cloudflare: de infrastructuur achter applicaties

Tijdens mijn rondgang kwam ik ook Cloudflare tegen, met onderwerpen rond netwerkbeveiliging, beschikbaarheid en prestaties. Ik heb het aanbod daar niet uitgebreid onderzocht, maar de aanwezigheid sloot aan bij de bredere thema’s van de beurs.

Applicaties zijn afhankelijk van verbindingen, API’s en infrastructuur. Beveiliging en performance zijn daarom geen losse onderwerpen naast softwareontwikkeling, maar onderdelen van het geheel.

De beursvloer · een humanoïde robot in actie

Robotica van dichtbij

Een opvallend moment was een demonstratie met een humanoïde robot. Voor een groep bezoekers voerde de robot verschillende bewegingen uit. Het was leuk om dit daadwerkelijk op de beursvloer te zien, in plaats van alleen in een presentatie of video.

Daar komen AI, sensoren, besturingssoftware en mechanica samen. Het past bij het onderwerp Physical AI: AI die ook in fysieke systemen wordt toegepast. Vanuit mijn technische interesse vind ik vooral de samenwerking tussen al die onderdelen boeiend. Een demonstratie laat iets zien van de mogelijkheden, maar is uiteraard nog geen volledige beoordeling van de betrouwbaarheid in dagelijks gebruik.

De panels · AI-agents en de volgende generatie datacenters

Architecting AI Agents – From RAG to Agentic Systems

Een van de panels ging over de ontwikkeling van AI-agents. Bij Retrieval-Augmented Generation, RAG, wordt een taalmodel ondersteund met relevante informatie uit externe bronnen, zoals bedrijfsdocumentatie of een kennisbank. Bij agentic systems ligt de nadruk daarnaast op het plannen en uitvoeren van stappen, bijvoorbeeld door tools te gebruiken.

Dat biedt interessante mogelijkheden, maar roept voor mij ook vragen op. Welke acties mag zo’n systeem uitvoeren? Hoe volg je de beslissingen en hoe controleer je het resultaat als antwoorden of gekozen stappen kunnen variëren? Het zijn vragen die raken aan ontwerp, beveiliging en testen.

Building the Next Generation of Data Centres

Een ander panel ging over datacenters. Achter cloud- en AI-toepassingen staat een fysieke infrastructuur met vragen rond energieverbruik, koeling, schaalbaarheid, beschikbaarheid en duurzaamheid.

Dat was een waardevolle aanvulling op alle software en AI op de beursvloer. Een digitale dienst kan nog zo slim zijn: uiteindelijk zijn er ook apparatuur, verbindingen en energie nodig om die dienst te laten werken.

Nog twee beelden · aankomst en beursinformatie

Wat ik meeneem naar mijn eigen werk

Mijn bezoek was breder dan softwaretesten alleen, en juist dat vond ik waardevol. Kwaliteit ontstaat niet binnen één vakgebied. Gegevens, integraties, applicaties, beveiliging en infrastructuur beïnvloeden elkaar. Die samenhang begrijpen helpt mij om betere vragen te stellen en risico’s te herkennen.

Boomi was een vertrouwde kennismaking, de robotdemonstratie maakte technologie tastbaar en de panels brachten bredere vraagstukken in beeld. Spectrum wil ik verder onderzoeken zodra de toegezegde informatie binnenkomt. Eén beursdag was genoeg om met nieuwe ideeën naar huis te gaan, zonder te denken dat ik alle onderwerpen daarmee al volledig heb doorgrond.

Op 14 oktober las ik bij de NOS dat UWV stopt met de ontwikkeling en implementatie van de Bemiddelingsservice, BMS. Dat nieuws kwam persoonlijk binnen. Ik heb in 2022 en 2023 ongeveer twee jaar aan het project gewerkt en besloot destijds zelf te vertrekken, omdat ik het vertrouwen in het project had verloren.

Een project dat ik van dichtbij heb meegemaakt

Zoals ik mijn periode herinner, waren we het eerste jaar vooral bezig met de database en de servicelaag, waaronder REST-API’s. Daarna volgden de aanbesteding en de aanschaf van een BMS-applicatie. In de periode daarna kregen we te maken met applicatieproblemen en problemen rond de gegevens.

Voor mij zat daar een belangrijke zorg: ik zag onvoldoende aansluiting tussen de verwerking van de data en de applicatie die daarmee moest werken. Na bijna een tweede jaar met tegenslagen was mijn vertrouwen zo ver afgenomen dat ik besloot het project achter me te laten.

Dat is mijn persoonlijke terugblik op mijn eigen werkperiode. Ik kan daarmee niet beoordelen wat er na mijn vertrek allemaal is veranderd of welke beslissingen in latere fasen zijn genomen.

Wat nu openbaar is gemaakt

Volgens de openbare toelichting van UWV speelden onder meer de benodigde gegevenskwaliteit en de technische aansluiting op de bestaande omgeving een rol. De organisatie heeft onvoldoende vertrouwen dat BMS binnen een verantwoorde termijn en tegen verantwoorde kosten kan worden ingevoerd.

UWV meldt dat sinds de start in 2021 ongeveer 55 miljoen euro aan het project is besteed. Dat bedrag betreft ook investeringen in infrastructuur. Volgens UWV kan een deel van het ontwikkelde mogelijk worden hergebruikt; de precieze omvang en waarde worden nog onderzocht. Het volledige bedrag simpelweg als verloren beschouwen zou daarom te kort door de bocht zijn.

Ik herken in die openbare toelichting thema’s die voor mij destijds al reden waren om te twijfelen. Die herkenning betekent niet dat mijn ervaringen het hele verloop verklaren. Mijn perspectief is dat van een voormalig projectmedewerker, niet dat van de evaluatie van het complete project.

De maatschappelijke kant raakt me

Een systeem dat werkzoekenden en werkgevers beter moet helpen, heeft een doel dat ertoe doet. Als zo’n project uiteindelijk stopt, raakt dat aan de verwachtingen van mensen, de inzet van betrokken medewerkers en het zorgvuldig omgaan met publieke middelen. Dat betreur ik oprecht.

Ik hoop dat de evaluatie bruikbare lessen oplevert: over de samenhang tussen gegevens en applicaties, over tijdig toetsen of een oplossing in de praktijk werkt en over het serieus wegen van risico’s voordat de volgende stap wordt gezet.

Trots op mijn eigen afweging

Tegelijkertijd ben ik trots op mijn eigen handelen. Ik ben destijds niet blijven doorgaan op basis van de hoop dat het uiteindelijk vanzelf goed zou komen. Op grond van wat ik in mijn werk zag, heb ik een eigen afweging gemaakt en besloten te vertrekken.

Het nieuws van nu geeft mij vertrouwen in het oordeel dat ik toen vormde. Het blijft belangrijk om dat zorgvuldig te formuleren: ik keek vanuit mijn positie naar een deel van het project. Juist binnen dat perspectief heb ik verantwoordelijkheid genomen voor mijn eigen keuze.

Wat ik als tester meeneem

Voor mij onderstreept deze ervaring dat kwaliteit niet ophoudt bij een werkende API of een geslaagde test op een afzonderlijk onderdeel. De vraag is ook of gegevens bruikbaar zijn voor de applicatie en of de hele keten het bedoelde resultaat oplevert.

Dat vraagt om kritische vragen: welke gegevens verwacht de applicatie, welke kwaliteit leveren de bronnen en wat gebeurt er met uitzonderingen? En vooral: kunnen we met realistische gegevens vroeg aantonen dat de oplossing daadwerkelijk helpt?

Dat is een lijn die ik ook in mijn testportfolio probeer vast te houden: verwachtingen zichtbaar maken, bevindingen onderbouwen en benoemen wat een testresultaat wel en niet bewijst. Soms is verder bouwen de juiste keuze. Soms vraagt professioneel handelen om opnieuw beoordelen, bijsturen of voor jezelf besluiten te stoppen.

Ik woonde een online bijeenkomst van de Robot Framework-community bij. Voor mij zat er weinig technische verdieping in, maar de afsluitende oproep om feedback en kennis te delen bleef hangen. Als we met AI steeds vaker zelf een oplossing vinden, hoe zorgen we dan dat de community daar ook iets aan heeft?

Een kennismaking met het format

De bijeenkomst begon met uitleg over het format en aandacht voor een podcast. Er werd ruimte geboden voor live demo’s en samen programmeren: mogelijkheden om niet alleen te luisteren, maar ook zelf iets te laten zien en uit te proberen. Verder kwamen RoboCon en aankomende evenementen aan bod.

Ik had zelf op meer inhoudelijke verdieping gehoopt. Toch vond ik de afsluitende oproep interessant: geef feedback, breng ideeën in en deel wat je tegenkomt. Juist die uitwisseling maakt een community waardevol.

Een antwoord van AI is snel gevonden

Zoals ik het gesprek begreep, merken de organisatoren dat mensen met AI vaker zelfstandig naar oplossingen zoeken. Daarbij werd ook erkend dat dit vaak sneller gaat en soms een beter resultaat oplevert. De boodschap was voor mij geen afwijzing van AI, maar een zoektocht naar een manier waarop AI-gebruik en samenwerking naast elkaar kunnen blijven bestaan.

Dat herken ik. Ook bij het bouwen van deze website helpt AI me om dingen uit te zoeken en verder te komen. Maar een oplossing die voor mij werkt, wordt niet vanzelf gedeelde kennis. Wanneer ik alleen het antwoord gebruik en daarna verderga, weet de community niet welk probleem ik had, wat hielp en wat misschien verbeterd kan worden.

De waarde van samen leren

Een framework bestaat niet alleen uit de code die ik vandaag gebruik. Er zit werk achter van mensen die het ontwikkelen, onderhouden, uitleggen en in de praktijk toepassen. Door ervaringen te delen, kunnen anderen daarvan leren en kunnen terugkerende problemen zichtbaar worden.

Mijn vraag na deze bijeenkomst is daarom: hoe blijft die uitwisseling aantrekkelijk als een AI-assistent het eerste aanspreekpunt wordt? Voor mijn gevoel raakt dat aan de meerwaarde van een community. Het gaat om een balans tussen de snelheid van een individueel antwoord en de kennis die we gezamenlijk opbouwen.

Wat ik hiervan meeneem

Voor mij hoeft dat niet te betekenen dat ik minder AI moet gebruiken. Ik kan wel bewuster iets teruggeven: een bruikbare oplossing delen, een fout melden, feedback geven of laten zien hoe ik een demo heb gebouwd. Een AI-antwoord kritisch controleren en mijn bevindingen vervolgens delen, kan juist een aanleiding zijn voor een goed gesprek.

De bijeenkomst was voor mij niet bijzonder boeiend qua techniek, maar leverde wel een relevante vraag op: als ik profiteer van een framework en de kennis eromheen, hoe draag ik dan bij aan het samen verder leren?

Verder kijken

• Robot Framework-community · forum en uitwisseling ↗
• RoboCon · Robot Framework-conferentie ↗
• Robot Framework · officiële website ↗

Dit is mijn persoonlijke terugblik op de bijeenkomst, op basis van mijn eigen aantekeningen. De beschrijving van het gesprek en mijn interpretatie zijn geen letterlijk verslag of officiële verklaring van de organisatoren.

Tijdens een DevOps-vakgroepevent bij mijn werkgever woonde ik een lezing bij over certified pipelines met GitHub Enterprise. Wat me vooral bijbleef, was het gezamenlijke doel: per applicatie zichtbaar maken of de ontwikkel- en publicatieketen aan een afgesproken norm voldoet. Elk team levert daarvoor zijn eigen controles en bewijs aan, zodat er op organisatieniveau een overzicht ontstaat.

Wat doet GitHub Enterprise?

GitHub Enterprise ondersteunt organisaties bij het beheren van broncode en samenwerken aan wijzigingen. Teams werken met repositories, versiebeheer, pull requests en reviews. Enterprise-beheer voegt centrale mogelijkheden toe voor toegang, beleid en controle over meerdere organisaties. GitHub biedt hiervoor zowel een cloudvariant als een zelf beheerde servervariant.

Met GitHub Actions kunnen teams workflows uitvoeren voor bijvoorbeeld bouwen, testen en publiceren. De stappen worden beschreven in YAML: een leesbaar configuratieformaat waarin staat wanneer een workflow start en welke jobs uitgevoerd worden. Herbruikbare workflows helpen om gemeenschappelijke controles op meerdere projecten toe te passen.

Wat bedoel ik hier met certified pipelines?

In mijn terugblik gebruik ik deze term voor pipelines die worden beoordeeld tegen een afgesproken interne norm. Die norm beschrijft welke controles nodig zijn en welk bewijs daarvan beschikbaar moet zijn. De precieze criteria hangen af van de organisatie en het risico van de applicatie; het gaat hier niet om een automatisch verkregen GitHub-certificaat.

Denk als algemene voorbeelden aan codebeoordeling, geautomatiseerde tests, beveiligingscontroles, beheerde toegang en aantoonbare publicatiestappen. Dit zijn voorbeelden om het idee uit te leggen, geen opsomming van de concrete norm van mijn werkgever.

Eén centraal YAML-bestand als gemeenschappelijk vertrekpunt

De aanpak die ik uit de lezing meenam, draait om één centraal YAML-bestand dat per project of applicatie de beoordeling tegen de norm ondersteunt. Zo krijgt de organisatie een gemeenschappelijk vertrekpunt: welke eisen gelden, welke controles zijn beschikbaar en waar ontbreken nog onderdelen?

YAML is daarbij de beschrijving. De scripts, workflows en achterliggende tools voeren de controles uit en leveren resultaten. GitHub Actions ondersteunt herbruikbare workflows, waarmee een centrale aanpak kan worden toegepast zonder dat elk team dezelfde logica opnieuw hoeft te schrijven. Hoe het centrale bestand precies is ingericht, bepaalt de organisatie zelf.

De rol van ieder DevOps-team

Een centraal overzicht vraagt om betrouwbare informatie vanuit de teams. Zij kennen hun applicatie en richten de passende checks and balances in: controles, reviews, bevoegdheden en opvolging van afwijkingen. De centrale norm helpt om die inspanningen in dezelfde taal te beoordelen, terwijl teams verantwoordelijk blijven voor de kwaliteit van hun eigen keten.

Het interessante is de verbinding tussen twee niveaus. Binnen een team wil je weten of een wijziging veilig door de pipeline gaat. Over het landschap heen wil je zien hoe consequent de afspraken worden toegepast en waar verbetering nodig is. Ontbrekend bewijs, een mislukte controle en een bewust vastgelegde uitzondering verdienen daarbij ieder een eigen verklaring.

Volwassenheid zichtbaar maken, met oog voor de grenzen

Een groen overzicht is een bruikbaar signaal: de geselecteerde controles zijn uitgevoerd en voldeden aan hun criteria. Het zegt nog niet dat een applicatie foutloos is of dat alle risico’s zijn onderzocht. Ook de inhoud, actualiteit en dekking van de controles moeten kritisch bekeken worden. Juist daar zie ik een belangrijke rol voor softwaretesters.

Voor mij maakt deze aanpak volwassenheid bespreekbaar. Je kunt gericht vragen stellen: welke norm gebruiken we, welk bewijs hebben we en welk risico blijft over? Het wordt daarmee meer dan een verzameling losse teams die ieder hun eigen vinkjes zetten; hun werk draagt bij aan één gezamenlijk doel.

De verbinding met mijn eigen portfolio

Op kleinere schaal probeer ik dezelfde gedachte op deze website toe te passen. Ik beheer code met Git, test vóór publicatie, koppel testbewijs aan de geselecteerde bestanden en bewaak later de ontvangen testresultaten. Mijn site gebruikt hiervoor een lokaal publicatieproces en NAS-taken. De lezing helpt me vooral nadenken over de volgende vraag: hoe maak je kwaliteitsafspraken aantoonbaar en houd je het overzicht begrijpelijk?