Blog

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.

Als je denkt aan high-speed innovatie, denk je wellicht aan de Formule 1. Een wereld waar snelheid, precisie en strategie samenkomen om grenzen te verleggen. Deze principes vormen ook de ruggengraat van low-code development, waar risicogebaseerd testen snelheid, precisie en strategie in balans brengt.

Integratietesten. Iedereen kent ze, én iedereen gebruikt ze. Maar wat is nou precies een integratietest?

TMAP® heeft mij geleerd dat integratietesten draaien om het samenbrengen van verschillende applicaties of systemen, om de onderlinge integratie ervan te testen. Dit is soms verwarrend omdat we het vaak ook over end-to-end testen hebben, die bijna hetzelfde doen.

Met de aankondiging dat de Mendix Application Test Suite (ATS) voor low-code applicaties wordt uitgefaseerd, staan veel organisaties voor de uitdaging om een nieuwe, betrouwbare oplossing voor hun testautomatisering behoeften te vinden. In dit kritieke overgangsmoment biedt Praegus met de Open Source Toolchain een geavanceerd alternatief dat niet alleen de

Met het EK voetbal voor de boeg zal het journaille en trainersgilde eerdaags wel weer los gaan op het fenomeen van de sterkhouder. Voor de winnaar is de in bloedvorm verkerende sterkhouder een zegen; voor de verliezer zal de geblesseerde sterkhouder hét excuus zijn bij jammerlijk falen.

Vergeef het me, ik krijg momenteel enorm veel mee van kinderseries. Het is al een gekke gewaarwording om alle series van vroeger opnieuw mee te maken als volwassene. Echter bij één specifieke serie gebeurde er iets vreemds en ontdekte ik een diepere laag. Ik ging zelfs de absurde en lach opwekkende situaties herkennen in mijn dagelijkse werkzaamheden! Helaas zijn er genoeg overeenkomsten tussen de situaties waarin Buurman en Buurman continu terechtkomen en de iteraties die ook mij overkomen binnen software testen.

Toen mijn vriend en ik op een warme nazomerdag begonnen aan een onvergetelijke fietsvakantie, had ik nog niet bedacht dat het mij meer zou leren over risicomanagement. Maar eenmaal weer behouden thuis aangekomen wil ik de geleerde lessen graag met jullie delen.

Als je een beetje thuis bent in de wereld van softwareontwikkeling en softwaretesten kan het je niet ontgaan zijn. Je moet shiften! De één roept: “shift-left en je bent alle problemen voor.” De ander roept: “shift-right en je kunt alles verbeteren.” En bij nader inzien sluiten ze elkaar niet uit, maar versterken ze elkaar. Je zou er geschift van raken.
In deze blog neem ik je mee in de wereld van het shiften.