Regressietesten zonder QA-team

De meeste software wordt gebouwd door teams zonder QA-functie. Er is geen testengineer, geen testplan en geen suite — alleen een groep mensen die oplevert, en een stil besef dat er iets stuk kan gaan zonder dat iemand het merkt.

Het gebruikelijke advies voor deze situatie is iemand aannemen of een platform aanschaffen. Geen van beide is haalbaar voor de meeste teams die de vraag stellen. Deze pagina gaat over wat je in plaats daarvan doet.

Begin bij de kosten, niet bij de dekking

De reflex is alles willen testen, concluderen dat dat onmogelijk is, en niets doen. De betere reflex is een smallere vraag stellen:

Als dit stilletjes stukging en een week stuk bleef, wat zou het ons kosten?

Rangschik je flows naar het antwoord. Bijna altijd steekt een klein aantal ver boven de rest uit — de flows waar geld, toegang of data die het pand verlaat bij betrokken is.

• Aanmelden en inloggen. Als niemand binnenkomt, doet de rest er niet toe.
• Betalen en afrekenen.
• Wat dan ook het kernrecord in je product aanmaakt — een bestelling, een boeking, een project, een ticket.
• Alles wat iets naar een klant verstuurt.
• Rechten, vooral overal waar de ene klant de gegevens van een andere zou kunnen zien.

Die lijst telt meestal vijf tot acht punten. Dat is je regressiesuite. Niet een eerste deel ervan — voorlopig het geheel.

Waarom kleine suites het hier winnen van grote

Honderd tests die niemand onderhoudt leveren een permanent rode build op, en die leert iedereen binnen twee weken negeren. Op dat punt heb je negatieve waarde: de onderhoudskosten, plus het valse vertrouwen dat je ‘een testsuite’ hebt.

Acht tests die betrouwbaar slagen, en waarvan een mislukking iets betekent, worden wél bekeken. Dat is het hele spel wanneer niemand dit als taak heeft.

Voeg tests toe op basis van bewijs in plaats van verbeelding. Wanneer er iets stukgaat in productie, schrijf dan de test die het zou hebben afgevangen. Na een half jaar heb je een suite die is gevormd door je werkelijke faalpatronen in plaats van door giswerk.

Frequentie

Zonder CI-pijplijn dekken twee runs het meeste risico af:

• Een geplande run tegen staging, dagelijks. Vangt drift af, wijzigingen bij derden, verlopen inloggegevens en dataproblemen die opduiken zonder dat iemand iets heeft uitgerold.
• Een run voor elke release. De poort die telt.

Heb je wél een pijplijn, dan is draaien bij elke pull request beter, en worden tools die daarvoor gebouwd zijn — mabl, Momentic, QA.tech — hun prijs waard. Zonder pijplijn is een schema een volstrekt redelijk alternatief en aanzienlijk beter dan niets.

Eigenaarschap

Hier sneuvelen deze pogingen het vaakst. Een suite die van ‘het team’ is, is van niemand: een mislukking verschijnt in een gedeeld kanaal, iedereen neemt aan dat een collega kijkt, en binnen een maand staan de meldingen op stil.

Wijs één persoon aan. Hun taak is niet alles repareren — het is naar elke gefaalde run kijken en beslissen of het een bug is, een kapotte test of een omgevingsprobleem. Een kwartier per week, trouw gedaan, maakt het verschil.

Wanneer tests in gewone taal zijn geschreven in plaats van in code, hoeft die persoon geen engineer te zijn, wat de vijver flink vergroot. Een product owner of operationeel manager die het product begrijpt kan dit prima doen.

Een tool kiezen voor deze situatie

De beperking die telt zijn niet de functies. Het is wat de tool van jou nodig heeft voordat hij kan helpen.

Alles wat een CI-pijplijn, een repository of een QA-praktijk vereist valt af — niet omdat het slecht is, maar omdat je de voorwaarde niet kunt leveren. Dat schrapt meteen het grootste deel van de markt, inclusief enkele van de beste producten erin.

Wat overblijft zijn tools die alleen een draaiende applicatie en een URL nodig hebben: Testmode, testRigor, Rainforest QA, Functionize en Autify. De volledige indeling naar beperking staat in het overzicht van AI-testtools.

De andere eerlijke optie is Playwright. Het is gratis en uitstekend, en als een van je ontwikkelaars echt een testsuite wil bewaken, is dat een goede uitkomst. Wees realistisch over de vraag of die persoon bestaat en de tijd heeft — een verlaten Playwright-suite is het meest voorkomende artefact in deze hele categorie.

Een redelijke eerste maand

• Week 1. Schrijf je vijf duurste storingen op. Nog geen tests — alleen de lijst.
• Week 2. Automatiseer er drie. Drie die draaien winnen het van acht die half af zijn.
• Week 3. Laat ze op een schema draaien en richt ze op een echte inbox of een echt kanaal. Voeg de resterende twee toe.
• Week 4. Wijs de eigenaar aan. Spreek af wat er gebeurt als een run faalt, concreet genoeg dat het niet in het moment hoeft te worden bedacht.

Dat is een werkende regressiepraktijk, en er hoeft niemand voor te worden aangenomen.