Artikelen en blogs.

Bij elke technologische golf verandert het speelveld voor IT kwaliteit. Agile, DevOps, Cloud: telkens werden testers overbodig verklaard. Testen wordt immers in het proces als activiteit wel ingebed, toch? Daar is dan geen aparte rol meer voor nodig.

Een paar jaar geleden ben ik verhuisd. Dit werd ons eerste huis met een echte tuin. En hoewel de verhuizing midden in de winter was, kon ik duidelijk zien dat dit een keurig en goed onderhouden tuin was. Er was een groot grasveld dat recent gemaaid was, geen kale plekken

Flaky testen en dieprode, door ieder genegeerde, dashboards. Onleesbare testen, omdat men zegt BDD te doen, maar de scenario’s zien er uit als old-skool testscripts. En angst voor het toevoegen of onderhouden van geautomatiseerde testen. Dat zijn allemaal problemen die niet hoeven te bestaan, als je het testautomatisering framework de juiste structuur geeft.

Flaky testen en dieprode, door ieder genegeerde, dashboards. Onleesbare testen, omdat men zegt BDD te doen, maar de scenario’s zien er uit als old-skool testscripts. En angst voor het toevoegen of onderhouden van geautomatiseerde testen. Dat zijn allemaal problemen die niet hoeven te bestaan, als je het testautomatisering framework de juiste structuur geeft.

De wereld van softwaretesten en kwaliteitsborging verandert razendsnel. AI, testautomatisering en generatieve modellen lijken het speelveld opnieuw te definiëren. Sommigen roepen dat de menselijke factor overbodig wordt. Dat AI alle testcases schrijft, zelf software valideert en dat diep nadenken verleden tijd is.  Wij zien dat anders.  Nieuwe technologieën hebben altijd

De alertmelding hierboven verklapt het eigenlijk al. Ik ben obsolete geworden, deprecated, afgeschreven. ‘Vroegâh’ schreef ik met enige regelmaat een blog om nieuwe verbanden te leggen, zodat ik mijn eigen gedachten kon ordenen. In de hoop dat het zou leiden tot nieuwe inzichten. Soms bij mij zelf en hopelijk ook bij anderen die de moeite namen om mijn gedachtenspinsels te lezen. Dit spelen met gedachten helpt ook bij mijn dagelijks werk als het gaat over de kwaliteit van complexe informatiesystemen. Door onderwerpen uit te diepen, op papier te zetten en er over te praten met anderen kom je tot nieuwe inzichten.

Als je begint met component testen is het verstandig om klein te beginnen en nog niet te veel tijd te stoppen in code abstractie en helper classes. Maar naarmate je component testen meer gaat gebruiken, heeft het waarde om zo’n framework juist uit het schrijven en bepaalde logica te hergebruiken.

Stel je een directiemeeting voor bij een grote organisatie. Kwartaalcijfers en projectupdates passeren de revue, financiële targets worden besproken en strategische KPI’s beoordeeld. Maar zodra de voortgang van een aantal cruciale IT-projecten op tafel komt, neemt de spanning toe. De directie merkt op dat deadlines herhaaldelijk worden gemist en de kosten oplopen. Tegelijkertijd rapporteren IT-teams over bugs, technical debt en integratieproblemen. Hoe grondig de rapportages ook zijn, het ontbreekt vaak aan strategische inzichten die écht helpen om beslissingen te nemen. Klinkt dit bekend?

Component testen helpen steeds meer teams om grip te krijgen op de kwaliteit van hun microservices. Refactoren wordt een stuk minder pijnlijk en hierdoor wordt het ook makkelijker om de code van je microservice continu te blijven verbeteren. Maar hoe begin je nu met het schrijven van component testen?

In de snel veranderende wereld van bankieren is het waarborgen van veiligheid, compliance en klanttevredenheid cruciaal. Met de integratie van low-code platforms zoals PEGA en de strengere regelgeving onder de DORA-wetgeving, is risicogebaseerd testen belangrijker dan ooit.

In de wereld van bankieren is vertrouwen essentieel. Klanten vertrouwen erop dat hun financiële gegevens veilig zijn en dat hun transacties vlekkeloos verlopen. Dit vertrouwen is gebouwd op de fundamenten van veiligheid, compliance en innovatie. Low-code platforms zoals PEGA spelen een cruciale rol in het balanceren van deze pijlers door snelle, flexibele en betrouwbare oplossingen te bieden. Risicogebaseerd testen is daarbij onmisbaar om ervoor te zorgen dat de oplossingen niet alleen efficiënt maar ook veilig en compliant zijn, vooral in het licht van de DORA-wetgeving.