Voor een mkb-webshop loont het vooral om na elke patch of upgrade een handvol flows te testen: checkout, betaling, orderexport, zoeken en inloggen. Alles testen hoeft niet, maar niets testen is een gok. Adobe schrijft bij de maandelijkse isolated security patches zelf: “Test, then deploy. Validate in staging before promoting to production” (Adobe Experience League). Die patches slaan de volledige regressietest van een normale Composer-release over, en jouw combinatie van extensies, thema en koppelingen test Adobe sowieso niet. Dat deel ligt bij jou.
Wat Adobe test, en wat niet
Hoe het patchbeleid in elkaar steekt (maandelijks, los bestand, niet cumulatief), staat in de uitleg over Magento security patches. Voor testen telt vooral dit: ook een volledig geteste release test Adobe alleen op Magento zelf. Niet op jouw betaalmodule, je PIM-koppeling of het thema dat drie jaar geleden is aangepast. Die combinatie test niemand voor je.
De flows waar geld op het spel staat
Niet elke pagina is even belangrijk om te testen. Prioriteer op geldrisico, niet op volledigheid:
- Checkout, als gast en ingelogd. Als dit stuk is, verkoop je niets meer.
- Betaling afronden en de PSP-webhook die de orderstatus zet. Een order die wel wordt afgerekend maar in Magento op “pending” blijft staan, levert geen foutmelding op, alleen een klant die zijn bevestiging niet krijgt en een voorraad die niet klopt. Zie betaalproviders in Magento voor hoe die koppeling werkt.
- Orderexport naar ERP en voorraad. Loopt dit via cron of message queues, dan merk je een storing meestal pas als het ERP al een dag stilligt. Achtergrond hierover in cron en message queues.
- Zoeken via OpenSearch. Geen resultaten of een foutmelding op de zoekpagina kost direct conversie.
- Inloggen en accountbeheer. Vooral relevant als je terugkerende klanten of B2B-accounts hebt.
Alles daarbuiten (een los CMS-blok dat er anders uitziet, een filter dat net iets anders sorteert) is vervelend maar kost geen omzet. Begin bij de lijst hierboven.
De handmatige rooktest die je zelf kunt doen
Een rooktest (smoke test) is geen vervanging van een echte regressietest, maar wel het eerste alarm. Als eigenaar kun je hem zelf uitvoeren, zonder developer erbij. Doe de volledige versie op staging, vóór de patch of upgrade naar productie gaat:
- Zoek op een bekend product en controleer of het juiste resultaat bovenaan staat.
- Leg het in de winkelwagen en plaats een bestelling als gast, met de betaalprovider in testmodus.
- Log in als klant, bestel nog een keer en bekijk je orderhistorie.
- Controleer of de orders in de admin verschijnen met de juiste status.
- Controleer of dezelfde orders in het ERP terechtkomen, als je die koppeling hebt. Op staging hoort die koppeling naar een testadministratie te wijzen; vraag je developer waar je moet kijken, anders lijkt hij kapot terwijl hij bewust uit staat.
Staat de patch live, doe dan op productie een korte check: zoeken, product in de winkelwagen, doorklikken tot de betaalstap, inloggen. Wil je de hele keten zien, plaats dan een kleine echte bestelling en annuleer en crediteer die daarna.
De stagingronde kost een kwartier en vangt de meest voorkomende breuken: een kapotte checkout, een betaalmodule die niet meer reageert, of een exportkoppeling die is gestopt. Het vangt geen subtiele fouten, bijvoorbeeld een kortingsregel die net iets anders uitrekent, of een webhook die wel binnenkomt maar de verkeerde order bijwerkt.
Wat geautomatiseerd testen toevoegt en wat niet
Het verschil met een rooktest is herhaalbaarheid. Een geautomatiseerde test draai je elke keer identiek, zonder dat iemand het zich moet herinneren of tijd heeft.
Adobe onderhoudt hiervoor zelf het Magento Functional Testing Framework (MFTF), met versie 7.0.0 verschenen op 14 augustus 2026 (releases op GitHub). Het wordt dus actief doorontwikkeld. Toch wijst een LinkedIn-poll van Yireo uit 2024 erop dat het in de praktijk weinig gebruikt wordt: 95% van de respondenten gaf aan MFTF niet te gebruiken (Yireo). Dat is een poll, geen representatief onderzoek, maar het past bij wat je in de community ziet: wie end-to-end test, kiest steeds vaker voor Playwright, ook voor Hyvä-shops.
Voor jou als eigenaar telt vooral dat tests bij je frontend horen: stap je over van Luma naar Hyvä, dan werken bestaande frontendtests meestal niet meer en moeten ze opnieuw geschreven worden. Vraag dat na vóór de migratie.
Wat geautomatiseerd testen niet oplost: een functionele test ziet geen visuele fouten (een knop die verspringt, een afbeelding die niet laadt), en het test niet of een live PSP-webhook daadwerkelijk binnenkomt. Dat laatste simuleer je in een testomgeving, maar de echte betaalprovider test je daarmee niet. En het is iets anders dan een loadtest: die meet of de shop drukte aankan, zie Black Friday voorbereiden. Een functionele test kijkt of hij het überhaupt nog doet.
Staging met echte data, niet met een lege database
Een testomgeving met een leeg of jaren oud databasebestand geeft een vals gevoel van veiligheid. Kortingsregels die afhangen van klantgroepen, voorraadniveaus die bepalen of een artikel wel of niet bestelbaar is, prijsregels die op datum afgaan: dat gedrag test je alleen goed met data die op productie lijkt.
Werk daarom met een periodieke, geanonimiseerde kopie van de productiedatabase op staging. Maak hierover een vaste afspraak met je hoster of developer, zodat het niet afhangt van wie er net tijd heeft.
Wanneer automatiseren loont
Weinig wijzigingen en weinig maatwerk: een consequente handmatige rooktest na elke patch is dan voldoende. Denk aan een shop die naast de maandelijkse patch een paar keer per jaar iets nieuws krijgt, met een standaard checkout en de gewone module van je betaalprovider. De kans dat iets structureel misgaat is klein, en geautomatiseerde tests bouwen en bijhouden kost dan meer dan het oplevert.
Het kantelt als een van deze drie geldt:
- Er gaat meer dan eens per maand nieuwe code live, naast de patches.
- De checkout heeft eigen stappen of logica: extra velden, afwijkende verzendregels, B2B-goedkeuring, een aangepaste betaalmodule.
- Je kunt uitrekenen wat een uur kapotte checkout kost, omdat er elk uur orders binnenkomen.
Automatiseer dan in elk geval de vijf flows uit de lijst hierboven. Niet alles: een testsuite die elke pagina dekt, kost al snel meer onderhoud dan hij voorkomt.
Wat je aan je developer of bureau vraagt
Doe je de deploy niet zelf, dan helpen deze vragen om te zien hoe het testen nu geregeld is:
- Draaien er geautomatiseerde tests, en welke flows dekken ze?
- Wanneer liepen ze voor het laatst, en wie kijkt naar de uitkomst?
- Hoe vaak wordt staging gevuld met een geanonimiseerde kopie van productie?
- Waar komt een testorder van staging terecht: in een testadministratie, of nergens?
- Wat is de afspraak als een patch op staging iets breekt: wachten, of toch live?
Koppel testen aan je onderhoudsritme
De meest praktische aanpak: koppel de rooktest aan het ritme van Adobe’s Patch Tuesday (de tweede dinsdag van de maand) en aan grotere stappen zoals een PHP-upgrade of de overstap naar Magento 2.4.9. Zo wordt testen geen apart project, maar onderdeel van structureel Magento onderhoud.
Twijfel je of je code en testdekking op dit moment een risico vormen, laat dat dan nakijken via een Magento code review. Weet je niet waar je moet beginnen, neem contact op.
Veelgestelde vragen
Moet ik testen na elke security patch?
Ja, in elk geval een gerichte check. Adobe adviseert zelf om een isolated security patch eerst op staging te valideren, en test hem niet in combinatie met jouw extensies, thema en koppelingen. Een korte rooktest van checkout, betaling en zoeken vangt de meest voorkomende breuken.
Wat is het verschil tussen een rooktest en geautomatiseerd testen?
Een rooktest doe je handmatig, in een kwartier, en vangt grove fouten zoals een kapotte checkout of een gestopte exportkoppeling. Geautomatiseerd testen draait dezelfde stappen herhaalbaar en zonder dat iemand het moet onthouden, maar vraagt meer tijd om op te zetten en te onderhouden.
Heb ik een staging-omgeving nodig?
Ja, en wel met data die op productie lijkt. Een lege testdatabase mist de kortingsregels, klantgroepen en voorraadniveaus die juist vaak de bron zijn van onverwacht gedrag. Werk met een periodieke, geanonimiseerde kopie van productie.
Loont automatisch testen voor een kleine webshop?
Meestal niet volledig. Bij weinig wijzigingen en weinig maatwerk is een consequent uitgevoerde handmatige rooktest vaak genoeg. Automatiseren loont pas als er meer dan eens per maand nieuwe code live gaat, je checkout eigen stappen of logica heeft, of je kunt uitrekenen wat een uur kapotte checkout kost.