Kwaliteit blijkt wanneer mensen op het platform rekenen.

We bepalen met jullie welke handelingen de grootste gevolgen hebben. Bij het aanvraag- en partnerplatform werkten we bijvoorbeeld commissiestaffels, partnerrelaties en batchverwerking uit. Daar raakt een wijziging in een berekening direct aan een commerciële afspraak. Bij JobLog raken uitzonderingen op terugkerend werk aan de opdrachten die medewerkers ontvangen.

Daaruit volgt de testaanpak. We leggen belangrijke bedrijfsregels vast in gerichte tests, controleren integraties en doorlopen de gebruikssituaties met de mensen die het werk kennen. De gewone route én de uitzonderingen horen erbij.

Een geautomatiseerde test bewijst wat hij controleert. Daarom kijken we niet alleen naar aantallen of een groen rapport, maar naar de risico’s die wel en niet zijn afgedekt.

Vraag	Passende controle
Blijft een berekening juist bij een wijziging?	Tests van bedrijfslogica en grensgevallen
Mag deze gebruiker deze opdracht aanpassen?	Autorisatietests voor toegestane en geweigerde toegang
Blijven toepassingen dezelfde afspraak begrijpen?	Contract- en integratietests
Kan een medewerker het werk echt uitvoeren?	Browsertests en beoordeling van een complete gebruikssituatie
Blijft het bruikbaar bij drukte?	Belastingtests met afgesproken volumes en afhankelijkheden
Kunnen we herstellen?	Beproeven van back-upherstel en terugvalscenario’s

We spreken af welke controles bij de opdracht horen. Dat maakt verwachtingen zichtbaar voor de opdrachtgever én voor het ontwikkelteam.

We gebruiken AI waar het helpt bij uitwerking, implementatie en analyse. Gegenereerde code krijgt daarmee geen andere kwaliteitsnorm. Een wijziging moet passen bij de architectuur, de bedrijfsregels en de afgesproken controles.

Voor wijzigingen met grote gevolgen willen we kunnen terugvinden wat er verandert, waarom dat nodig is en hoe het is getoetst. Een test die door hetzelfde hulpmiddel is geschreven als de code verdient evenzeer inhoudelijke beoordeling. Een aannemelijke uitleg is geen bewijs dat een grensgeval werkt.

De winst van sneller schrijven gebruiken we ook om meer situaties te onderzoeken en ideeën eerder met gebruikers te toetsen.

Ontwikkeling, test en productie hebben elk een eigen rol. We richten een herhaalbare route in van broncode naar gebouwd artefact, controle en vrijgave. Configuratie, geheimen en omgevingskeuzes horen bij die route.

Datamigraties verdienen afzonderlijke aandacht. Een oudere app kan nog actief zijn terwijl de backend wordt vernieuwd. We onderzoeken die afhankelijkheden, maken waar nodig een overgang mogelijk en leggen vast wat terugdraaien wel en niet betekent.

Niet iedere fout kan met een oude applicatieversie worden opgelost. Een al verzonden bericht of gewijzigde betaling vraagt een eigen herstelhandeling.

Een draaiende server is niet hetzelfde als een werkende onderneming. Daarom kiezen we signalen die bij het product passen: mislukte boekingen, vastgelopen taken, fouten in koppelingen en ongebruikelijke responstijden of kosten.

In de praktijk: verwerking met zicht op voortgang en fouten

In JobLog bouwden we achtergrondverwerking voor abonnementstaken. De wachtrijflow verwerkt werk in batches en houdt voortgang, voltooiing en fouten bij. Daardoor bestaat er een onderscheid tussen werk dat is aangeboden en werk dat daadwerkelijk is verwerkt. Dat is de informatie waarop gerichte opvolging kan worden ingericht.

We bepalen wie meldingen ontvangt, wanneer actie nodig is en welke informatie helpt bij onderzoek. Daarbij vermijden we dat logging een tweede ongecontroleerde verzameling persoonsgegevens wordt.

Hersteldoelen bespreken we vanuit het gebruik: hoe lang mag een functie uitvallen en hoeveel gegevensverlies is aanvaardbaar? Google Cloud’s reliability framework verbindt betrouwbaarheid eveneens aan gebruikersdoelen, monitoring en hersteltests. De invulling moet bij jullie onderneming en budget passen.

Onderhoud, bereikbaarheid en verdere ontwikkeling zijn verschillende afspraken. We maken duidelijk wat onder het beheer valt, hoe nieuwe wensen worden opgepakt en welke inzet bij jullie team ligt. Bereikbaarheid en responstijden leggen we vast in een beheerafspraak die past bij het belang van het platform.

Bij een Amerikaanse bouwmaterialenleverancier onderhouden en moderniseren we verkoop-, voorraad- en logistieke toepassingen en begeleiden we de interne ontwikkelaars. Productberekeningen, vestigingscontext en bestaande koppelingen zijn daarbij onderdeel van het werk. We verbinden technische vernieuwing aan de bedrijfskennis in de omgeving en de mensen die ermee verder moeten.

Broncode alleen is niet genoeg. Een volgend team moet kunnen begrijpen hoe het product is opgebouwd, hoe het wordt gestart en uitgerold en waar de belangrijkste risico’s zitten.

Voor een platform voor vastgoedonderhoud werkten we de requirements van de opdrachtgever uit, ontwikkelden we de web- en mobiele toepassingen en backend en droegen we het project na akkoord over. Dat is een andere opdrachtvorm dan langdurig beheer. Beide vragen om een duidelijke grens tussen onze verantwoordelijkheid en die van het volgende team.

Daarom nemen we documentatie, toegang, omgevingen en beheerafspraken mee in de oplevering. Rechten op code en afhankelijkheden leggen we contractueel vast. We maken overstappen of samenwerken mogelijk door de kennis deelbaar te houden. Meer over beheer en doorontwikkeling.