Testen en opleveren van MKB-software: onze praktische werkwijze

Wie eenmaal een grote bug in productie heeft gehad, weet het verschil tussen "we hebben getest" en "we hebben het goed getest". Een kassa-systeem dat op black friday crasht, een login-scherm dat na een deploy niemand meer binnenlaat, een factuurgenerator die BTW-bedragen verkeerd afrond. Zulke fouten kosten omzet, vertrouwen en bellen op zondag.

Bij Spago IT hebben we een vaste manier van werken die dit soort verrassingen sterk verkleint. Dit artikel laat concreet zien hoe wij van eerste commit tot live-gang bewegen, zonder mistige uitspraken over "best practices" maar met de stappen die we bij elke klant volgen.

Kort: onze werkwijze in vijf stappen

Ons bredere proces bestaat uit vijf blokken. De eerste drie staan uitgebreid op onze werkwijze-sectie op de homepage. Dit artikel zoomt in op stap vier en vijf: realisatie en oplevering.

1. Kennismaking
2. Analyse
3. Plan en voorstel
4. Realisatie (waar code, tests en review samenkomen)
5. Oplevering (wat u krijgt en hoe het werkt daarna)

Stap 4: Realisatie

Code pas live als er tests omheen staan

Wij schrijven geen feature zonder een laag tests die het gedrag bevriezen. De norm:

• Unit tests voor elke functie met logica. Pure functies, validatie, berekeningen: dit test we altijd.
• Integratietests voor elk API-endpoint. Request in, gewenste respons en database-effect uit.
• End-to-end tests via Playwright voor de kritieke user-flows. Inloggen, afrekenen, nieuwe klant toevoegen, offerte genereren. Alles wat misgaat als het mis is, komt hier.

Dekking is geen doel op zich. Wij schieten voor 70 tot 85% coverage op backend-code. Bij 100% slaat u door in tests van triviale code en verliest u ontwikkelsnelheid. Bij minder dan 60% laat u bugs glippen. Daar tussenin zit een sweet spot die we met klanten bespreken.

Code review voor elk stukje werk

Elke pull request gaat door review. Bij grotere klanten werken we met peer review binnen ons team of met een van uw eigen engineers als tweede paar ogen. Review-criteria:

• Doet de code wat de acceptance criteria zeggen?
• Staan er tests bij die een regressie voorkomen?
• Is het leesbaar zonder uitleg?
• Zit er geen onnodige complexiteit of voortijdige abstractie in?
• Zijn security-gevoelige stukken (auth, input-validatie, queries) expliciet gecheckt?

Een PR die niet aan één van deze punten voldoet, wordt niet gemerged. Klinkt streng, is het ook. Reden: we hebben uitgerekend dat een bug vangen in review vier tot tien keer goedkoper is dan hem later vinden in productie.

Geautomatiseerde kwaliteitscontrole in de pipeline

Voor elke commit draait onze CI-pipeline (GitHub Actions of uw eigen hosting):

1. TypeScript type-check en linting. Geen red squiggles die pas op de laptop van de volgende developer opduiken.
2. Unit- en integratietests. Volledig groen of de build faalt.
3. End-to-end tests tegen een productie-achtige omgeving. Playwright runt in parallel in meerdere browsers.
4. Security-scan: afhankelijkheden met bekende CVE's, hardcoded secrets, basis-OWASP-checks.
5. UI-controle: vergelijking met de vorige versie zodat een kleine CSS-wijziging die per ongeluk een hele header verschuift, direct opvalt.
6. Performance-budget: bundle-size, Lighthouse-scores. Feature die de site 500 ms trager maakt, stopt bij de poort.

Als één check faalt, gaat er niets live. Geen uitzonderingen, geen "we repareren het later".

Stap 5: Oplevering

Staged rollout met monitoring

Deploys gaan niet van niets naar alles. De route die we standaard volgen:

1. Preview-omgeving per pull request. De klant kan de wijziging zien en goedkeuren voordat hij echt naar productie gaat.
2. Staging voor de laatste check met productie-achtige data. Hier runnen nog eens de volledige E2E-tests.
3. Productie, waar nodig eerst naar een klein deel van de gebruikers zodat we een nieuwe versie rustig kunnen laten bezinken voor we hem op iedereen uitrollen.
4. Monitoring vanaf minuut nul: error-tracking via Sentry, uptime-monitoring via Uptime Kuma, log-aggregatie. Als er in de eerste vijftien minuten een spike in errors is, gaat er direct een alert.

Hand-over en documentatie

Bij oplevering krijgt u niet alleen een werkende applicatie. U krijgt alles wat nodig is om ermee door te werken, ook zonder ons:

• Source-code in uw eigen Git-repository
• Docker Compose-stack die lokaal en in productie identiek draait
• Infra-as-code: hosting, DNS, backups, alles vastgelegd in configuratiebestanden die u zelf kunt openen en aanpassen
• Runbook: concrete stappen voor deploy, rollback, backup-restore, toegangsbeheer
• Architectuurdiagram op één A4 met de belangrijkste componenten en data-flows
• Test-suite die u zelf kunt draaien
• Overdrachtsessie met uw intern team of een volgende leverancier, inclusief code-walkthrough

Geen lock-in op ons, geen geheime kennis in één hoofd. Als u later met een andere partij verder wil, kan dat zonder friction.

Garantie-periode en support

Na go-live volgt standaard een garantie-periode van 30 dagen waarin we bugs die uit initiële development komen kosteloos fixen. Dat is niet "we monitoren of het werkt", maar actief daily-standup op uw project terwijl het in productie stabiliseert.

Na die 30 dagen kiest u:

• Onderhoudscontract met afgesproken uren per maand voor nieuwe features en bugfixes
• Op-afroep-basis waar u per actie betaalt
• Volledig overgedragen naar uw eigen team

Geen pushy verkoop, geen vendor lock-in.

Wat dit oplevert voor uw organisatie

Concrete cijfers van klanten waar we deze werkwijze draaien:

• Minder dan 1 kritieke bug per maand in de eerste productiemaanden (sector-gemiddelde is 3 tot 5)
• Deploy-frequentie van 2 tot 5 keer per week in plaats van maandelijks (kleine wijzigingen zijn veiliger dan grote)
• Gemiddelde mean-time-to-restore bij incidenten onder 30 minuten dankzij monitoring en rollback-paden
• Onboarding van nieuwe medewerkers in 2 dagen door strakke documentatie

Dit is geen gemiddelde uit een whitepaper. Het zijn cijfers die we bij onze eigen klanten meten.

Wanneer dit NIET onze aanpak is

Wees eerlijk: dit proces kost in development ongeveer 15 tot 20% extra tijd vergeleken met "gewoon maar bouwen". Voor elke klant en project klopt die balans:

• Prototype of intern klein hulpmiddel: lichtere variant, alleen unit-tests en handmatige controle op hoofdpunten.
• Kritieke app waar geld door heen loopt of die bij uitval direct omzet kost: juist meer aandacht voor beveiliging, backups en monitoring.
• Bestaande codebase zonder tests: eerst een basis aan tests bouwen rond de onderdelen die vaak aangepast worden, voordat we features toevoegen. Anders bouwen we op drijfzand.

Wij passen het proces aan op uw situatie, niet andersom. Bij de intake bespreken we dit expliciet.

Tot slot

Goede testing en oplevering is geen kwestie van dure tools maar van discipline in de kleine stappen. Elke pull request door review, elke commit door CI, elke deploy naar staging voor productie, elke release met monitoring. Klein oogt simpel, gestapeld werkt het verschil zich terug in jaren zonder grote incidenten.

Wilt u zien hoe dit er in de praktijk uitziet voor een project dat u nu overweegt? Mail naar info@spago-it.nl met een korte beschrijving. We laten in een gesprek concreet zien welke test-lagen we zouden inrichten voor uw situatie en wat dat in doorlooptijd betekent.

Meer over onze aanpak bij Testing en QA vindt u via de Testing & QA artikelen op onze blog.