Kwaliteit en delivery
Het platform wordt gebouwd door een klein team met intensieve inzet van AI-agents. Dat maakt geautomatiseerde controle geen luxe maar de voorwaarde om verantwoord snel te kunnen werken.
Teststrategie
| Soort | Omvang | Wat het bewaakt |
|---|---|---|
| Component- en unittests | Bij elke wijziging, verplicht vóór samenvoegen | Gedrag van de interface en de bedrijfslogica |
| Isolatietests | Per wijziging en elke nacht, tegen een echte database | Wie welke data mag zien — per rol getoetst |
| End-to-end | Na elke uitrol en elke nacht | Inloggen en de kritieke gebruikersroutes |
| Zoekkwaliteit | Gelabelde meetset, met de hand gedraaid bij een wijziging aan het ophalen; geen automatische controle | Of het ophalen van bewijs nog even goed werkt |
De meetset voor zoekkwaliteit verdient toelichting: gelabelde vragen met een bekend juist antwoord, plus vragen waarop geen goed antwoord bestaat en het systeem dat ook moet zeggen. Daarmee is meetbaar of een wijziging de bewijsvinding verbetert of stilletjes verslechtert — in plaats van dat op gevoel te beoordelen. Anders dan de drie regels erboven draait deze meting niet vanzelf: de meetset bevat klantmateriaal en staat daarom niet in de repository, en er is geen geautomatiseerde run. Wie het ophalen wijzigt, draait de meting zelf en zet de uitkomst bij de wijziging.
De weg naar productie
De gouden regel: productie krijgt nooit een databasewijziging die niet eerst op staging is bewezen.
- Een wijziging gaat als voorstel naar staging.
- Daar worden de migraties toegepast en de isolatietests gedraaid.
- Twee poorten controleren de uitkomst:
- een volledigheidspoort die per migratie controleert dat hij daadwerkelijk is toegepast;
- een gelijkheidspoort die het schema van staging en productie vergelijkt.
- Pas daarna gaat dezelfde wijziging naar productie, langs dezelfde poorten.
- Na elke uitrol draait automatisch een rooktest die inlogt en controleert of de applicatie werkt.
Parallelle processen die dezelfde database raken worden geserialiseerd, zodat twee uitrollen elkaar niet kunnen overschrijven.
Poorten ontstaan uit incidenten
Elke geautomatiseerde poort hierboven komt voort uit iets dat één keer is misgegaan:
- Een uitrol waarna gebruikers niet meer konden inloggen → rooktest na elke uitrol.
- Twee parallel ontwikkelde wijzigingen waarvan er één stilletjes nooit op productie landde → volledigheidspoort op migraties.
- Een databasewijziging die een inlogpad dubbelzinnig maakte → structuurcontrole die daarop specifiek let.
Dat patroon — een incident wordt een permanente, geautomatiseerde controle in plaats van een eenmalige reparatie — is bewust beleid.
Besluitvorming
Architectuurkeuzes worden vastgelegd voordat ze gebouwd worden, inclusief de overwogen alternatieven, de nadelen van de gekozen route en de omstandigheden waaronder de keuze heroverwogen moet worden. Zie Architectuurbesluiten.