Je applicatie-leverancier heeft AI ontdekt. Het resultaat: meer releases met meer nieuwe functionaliteiten en meer wijzigingen in je applicaties. Klinkt als vooruitgang. Tot je beseft dat al die wijzigingen beoordeeld en getest moeten worden. Met hetzelfde team, dezelfde planning en dezelfde acceptatietests waarover je nu beschikt. De vraag is nu, hoe ga je dit allemaal in goede banen leiden zonder verlies van grip en controle op je testproces?
Leveranciers bouwen sneller dan ooit
Met AI-assisted coding sturen developers AI aan in plaats van alles zelf te schrijven. Een leverancier levert daardoor in dezelfde tijd veel meer op. Ook wij ontwikkelen Testersuite zo. We weten dus waar we het over hebben.
Onderzoek laat zien waar het wringt. Volgens het DORA-rapport 2025 van Google neemt de productiviteit van ontwikkelteams toe, maar daarmee ook de instabiliteit van releases. In het onderzoek van SmartBear onder 273 besluitvormers (januari 2026) zegt 60% dat ze het afgelopen jaar kwaliteitsproblemen hadden, omdat ontwikkeling sneller ging dan testen.
Het bouwen versnelt. Het valideren niet vanzelf. En dat valideren gebeurt in jouw landschap, met jouw processen en jouw koppelingen. Daarom nemen we drie stellingen in.
1. De acceptatietest zoals we die kennen houdt het niet vol
De FAT (Functionele Acceptatietest) en GAT (Gebruikersacceptatietest) zijn bij veel organisaties ingericht op een paar grote releases per jaar. Weken voorbereiden, key-users vrijmaken, testen, bevindingen laten oplossen, akkoord. Dat ritme bestaat niet meer. Wie elke release zo blijft testen, loopt structureel achter. Wie het loslaat, test straks niets meer.
De acceptatietest moet kleiner, vaker en slimmer. Bepaal de impact per release, houd een vaste regressieset voor je kritische processen en test alleen diep waar het ertoe doet.
2. Spreek je leverancier aan op zijn releasetempo
Sneller releasen is geen cadeau als jij de rekening betaalt. Toch accepteren veel organisaties elke release zoals hij binnenkomt. Dat hoeft niet. Je mag van je leverancier een voorspelbare releasekalender verwachten, heldere releasenotes en openheid over wat hij zelf al getest heeft. Maak dat onderdeel van je leveranciersgesprekken en contracten. Kwaliteit is een gedeelde verantwoordelijkheid, niet iets wat je over de schutting gooit.
3. Bij kleinere organisaties verdwijnt testmanagement
Dit is onze verwachting, en die is niet comfortabel. Organisaties met een klein team, waar één of twee mensen het testen er "ook even bij doen", gaan dit tempo niet bijbenen. De verleiding is groot om releases dan maar door te laten gaan. De leverancier heeft het toch getest? Zo verdwijnt testmanagement niet met een besluit, maar geruisloos. Release voor release.
En dan vraagt je accountant hoe je het hebt gevalideerd
Accountants en IT-auditors kijken bij de beoordeling van je IT-beheersing ook naar wijzigingsbeheer. Zijn wijzigingen goedgekeurd, getest en gecontroleerd doorgevoerd? "We vertrouwen op de leverancier" is dan geen antwoord. Wie testmanagement laat verdwijnen, kan ook niet meer aantonen dat er valide getest is. Hoe groot of klein je organisatie ook is.
Wat betekent dit voor jouw rol?
- Testmanagers en testcoördinatoren: van testen organiseren naar keuzes maken. Wat test je diep, wat niet, en waarom?
- Testers: je waarde zit in beoordelen, niet in afvinken. Past deze release bij hoe je organisatie werkt? Werkt hij met je koppelingen?
- Functioneel en applicatiebeheerders: change- en releasebeheer wordt een doorlopend proces in plaats van een kwartaalklus.
- Projectmanagers: het pakket staat na de livegang niet stil. Zorg dat je testwerk uit het project overdraagbaar is naar beheer.
- QA- en IT-managers: de vraag "Kunnen we live?" komt vaker. Beantwoord hem met onderbouwing, niet op gevoel.
Wat betekent dit voor je testaanpak?
- Eerst impact, dan testdiepte. Vertaal releasenotes naar je eigen processen. Raakt een wijziging een kritisch proces of een koppeling? Test diep. Alleen een schermaanpassing? Dan volstaat minder.
- Een vaste regressieset per kritisch proces. Compact, herhaalbaar en actief onderhouden.
- Nieuw en bestaand apart. Bestaande functionaliteit borg je met regressietesten, nieuwe functionaliteit in een gerichte GAT.
- Testplanning op het releaseritme. Vaste testmomenten, ook bij eindgebruikers. Zo hoef je niet elke release opnieuw te regelen wie er test.
- Een expliciete releasebeslissing. Wie zegt ja, en op basis van welke resultaten en openstaande bevindingen?
- Alles vastgelegd op één plek. Testgevallen, resultaten en bevindingen per release. Dat is je bewijs, ook richting je accountant.
Grip begint bij structuur
Snelheid mag nooit het doel worden. Meer releases zonder grip op je testproces is gokken met de kwaliteit van je IT-landschap. En lastig uitleggen aan je accountant.
Testersuite is een testmanagementoplossing die je die grip geeft, in de projectfase én in de beheerfase. Je brengt structuur in je FAT, GAT en regressietesten en houdt overzicht over change- en releasebeheer. Zo weet je bij elke release waar je staat, wat er getest is en welke risico's er nog liggen.
Wil je je testaanpak eerst zelf aanscherpen? Lees dan ook 7 lessen van testprofessionals of ons stuk over het verschil tussen testcase, testscenario en testrun.
En wat doet jouw testmanagement-tool?
Een ander testproces vraagt ook iets van je testmanagementtool. Een tool die alleen vastlegt wat jij erin stopt, helpt je niet om dit tempo bij te houden. Daarom ontwikkelen we Testersuite door van testmanagement-tool naar AI-ondersteund kwaliteitsmanagement-tool. Dat betekent dat de volgende onderdelen zijn vastgelegd in onze ontwikkel-roadmap:
- Releasenotes direct als testbasis. Je importeert releasenotes, bijvoorbeeld als pdf, xlsx of xml, en koppelt de wijzigingen direct aan je applicatiemodules en functionaliteiten.
- De impact per release inschatten. AI analyseert de releasenotes in de context van jouw organisatie: je eerdere testresultaten, bevindingen en productrisico's. Functioneel beheerders krijgen gerichte taken om de impact te controleren.
- De juiste regressietests selecteren. Op basis van die impactanalyse selecteert AI de relevante testgevallen uit je regressieset en zet een conceptversie van je testrun klaar.
- Je regressieset actueel houden. AI werkt bestaande testgevallen bij op basis van de wijzigingen en maakt nieuwe testgevallen waar die nog ontbreken.
Daarna kijken we onder meer naar AI-ondersteuning bij het vastleggen van goede, reproduceerbare bevindingen, bij de testplanning en bij een go/no-go-advies. Ook kijken we naar het omzetten van testbewijs in een sluitende audittrail voor je accountant.
Eén principe staat daarbij vast: de mens houdt de regie. AI doet het voorwerk, jij controleert en beslist. Daarom ontwikkelen we zelf ook met AI door: zodat jij het tempo kunt bijhouden.
Laten we erover praten
Ben je het met ons eens? Of juist helemaal niet? We horen graag hoe jij met dit tempo omgaat en waar je tegenaan loopt. Neem contact met ons op of plan een demo.
