Eenvoudige producten zijn gemakkelijk te testen, en bijna niemand bouwt tegenwoordig nog eenvoudige producten. De B2B SaaS-platforms waarmee we bij QA.tech werken, hebben een herkenbaar profiel: meerdere gebruikersrollen met verschillende machtigingen, schermen waarvan de volledige vorm afhankelijk is van de gegevens erachter, workflows die zich over een tiental stappen en meerdere afhankelijkheden uitstrekken, en steeds vaker functionaliteit die zich binnen één gebruikersreis uitstrekt over web, API en mobiel.
Dit is precies het terrein waarop scripted testautomatisering het meest kost en het minst dekt. Elke rol vermenigvuldigt de mogelijke paden. Elke gegevensstatus vermenigvuldigt ze opnieuw. Een testsuite die de combinaties eerlijk zou afdekken, zou groter zijn dan het product – dus in de praktijk scripten teams de happy paths, controleren ze de rest steekproefsgewijs handmatig en accepteren ze de lacune.
Dit artikel zet uiteen hoe de agents van QA.tech elk van deze complexiteitsdimensies anders aanpakken, gebaseerd op het onboarden van teams bij {{deeplink:260096:[fintech]:fintech}}, HR-technologie, e-commerce-infrastructuur en gezondheidszorg – de producten waarvoor "de flow gewoon opnemen" nooit zou werken.
Het juiste mentale model: je begeleidt een nieuwe collega bij de introductie
De invalshoek die alles hieronder begrijpelijk maakt, kwam eigenlijk van een klant. Een QA-lead die de agent voor het eerst zijn platform zag verkennen, vroeg: "Dus hij gedraagt zich als een nieuwkomer in het bedrijf?" Precies. De agent sluit zich bij je team aan zoals een slimme nieuwe QA-medewerker dat zou doen – hij verkent het product, bouwt een mentaal model op, stelt vragen wanneer hij iets onduidelijks tegenkomt en wordt in zijn eerste weken af en toe gecorrigeerd. Het verschil zit in wat er daarna gebeurt: het begrip dat hij opbouwt is een blijvende {{deeplink:260096:[kennisgraaf]:core_concepts}}, hij vergeet nooit een correctie en past elke contextuele aanwijzing toe op elke toekomstige test.
Dat mentale model is belangrijk omdat juist bij complexe producten de periode als "nieuwkomer" zijn vruchten afwerpt. Een script kent één pad door je product. Een getrainde agent kent je product.
Rollen en machtigingen: leer het de volledige kaart en geef het daarna elke sleutel
Systemen voor machtigingen zijn de plek waar scripted suites stilletjes opgeven. Als je platform rollen heeft voor beheerders, managers en leden – of vijftig klantspecifieke rolconfiguraties – heeft een scriptgebaseerde aanpak per rol afzonderlijk opgestelde dekking nodig, en raakt die verouderd zodra de machtigingen veranderen.
De agentische aanpak draait dit om. Eerst verkent de agent je product met een beheerdersaccount, zodat zijn kennisgraaf het volledige oppervlak omvat: elk scherm, elke actie en elke bestaande flow. Daarna geef je hem accounts met beperkte rechten. Wanneer hij inlogt als lid, ziet de agent minder opties – en omdat hij de volledige kaart kent, begrijpt hij wat ontbreekt en waarom, in plaats van in de war te raken door een kleinere interface.
Vanaf daar wordt {{deeplink:260096:[testen van machtigingen]:roles_permissions}} een gesprek. Zeg tegen de agent: "als dit type gebruiker mag je alleen X, Y en Z zien", en hij controleert de grens. En dit is het detail waar teams dol op zijn: wanneer een gebruiker met beperkte rechten daadwerkelijk geen toegang heeft tot een scherm, registreert de agent een geslaagde test – bewijs dat het machtigingensysteem zijn werk doet. Je bevestigt die verwachting één keer, de agent legt haar vast en een hele categorie beveiligingsrelevante controles wordt continu uitgevoerd zonder dat iemand er scripts voor schrijft.
Gegevensgestuurde flows: hetzelfde doel, andere gegevens, niets opnieuw opstellen
In gegevensintensieve SaaS is de flow zelden het moeilijke deel – de permutaties zijn dat wel. Eén record aanmaken is één test; het aanmaken met vijftig verschillende gegevensprofielen, waarvan sommige zouden moeten slagen en andere zouden moeten worden afgewezen, is waar handmatig testen verdrinkt en scripts veranderen in ononderhoudbare parametermatrices.
Omdat de agent vanuit doelen werkt in plaats van vanuit opgenomen stappen, vereist gegevensvariatie slechts één instructie: "Voer deze testcase opnieuw uit met deze gegevens." De flowkennis blijft behouden; alleen de invoer verandert. Negatieve gevallen werken op dezelfde manier – beschrijf wat moet worden afgewezen en de agent controleert of het product nee zegt wanneer dat hoort. Voor de vrije tekstvelden waar elk complex product vol mee zit, put de agent uit de productcontext die je hem hebt gegeven om zinvolle waarden in te voeren, en wanneer hij verkeerd gokt, corrigeer je zijn begrip één keer in plaats van een script te repareren.
Lange workflows: de agent kent de vereisten al
Workflows in bedrijfs-SaaS hebben afhankelijkheidsketens – je kunt een deal pas bewerken als er een deal bestaat, {{deeplink:260096:[kan een verzoek niet goedkeuren voordat iemand het indient]:multi_user_testing}}, en je kunt de tiende stap niet testen zonder de eerste negen. In scripted suites wordt dit configuratiecode: fixtures, seeds en hulpscripts die zelf een onderhoudslast vormen.
De agent verwerkt ketens zoals een persoon dat doet: door te onthouden. Zodra de agent een flow heeft voltooid, bouwt alles wat daarna komt voort op die kennis. Vraag de agent om suballocaties voor een deal te testen, en hij weet dat het aanmaken van de deal eerst komt – omdat hij dat heeft gedaan en het pad in zijn kennisgrafiek staat. Vereiste flows zoals inloggen worden één keer geconfigureerd en overal hergebruikt. Hoe dieper je workflows zijn, hoe belangrijker deze opeenstapeling wordt, omdat elke stap die de agent al kent een stap is die niemand opnieuw hoeft te schrijven.
Journeys over meerdere oppervlakken: web, API en mobiel in één test
Echte gebruikersjourneys in moderne SaaS houden geen rekening met de grenzen van testtools. Een gebruiker configureert iets op het web, een webhook wordt geactiveerd, een record wordt bijgewerkt via de API en een melding komt binnen in de mobiele app. De meeste teams testen elk oppervlak in een afzonderlijke tool met afzonderlijke scripts en hopen dat de verbindingen standhouden.
QA.tech voert deze uit als {{deeplink:260096:[enkele end-to-end-tests]:end_to_end}}: een flow kan in het webproduct beginnen, in het midden API-teststappen bevatten en eindigen in de {{deeplink:260096:[native iOS- of Android-app]:mobile_testing}}, waarbij de journey wordt geverifieerd zoals je klant die daadwerkelijk ervaart. Voor platforms waarbij de verbindingen tussen oppervlakken precies de plekken zijn waar bugs zich verbergen – betalingen, meldingen, synchronisatie – dicht dit het gat dat tooling per oppervlak structureel niet kan dichten.
Wat dit uiteindelijk betekent
Het patroon bij teams die aan complexe producten werken is consistent. De eerste weken zijn samenwerkend – de agent verkent, stelt vragen en wordt gecorrigeerd, terwijl je team leert hoe het de agent moet instrueren. Daarna neemt het aantal vragen af en raakt de testinspanning losgekoppeld van de productcomplexiteit: nieuwe rollen, nieuwe datastaten en nieuwe workflowstappen worden opgenomen in de kennisgrafiek in plaats van nieuw scriptwerk te genereren.
Het resultaat is zichtbaar in uren. {{deeplink:260096:[Pricer, een retailtechnologiebedrijf]:pricer}}, waarvan het platform precies dit soort complex, data-intensief product is, heeft elk kwartaal 390 QA-uren bespaard nadat het de verificatie naar QA-agents had verplaatst – capaciteit die weer in het uitbrengen van nieuwe functionaliteit kon worden geïnvesteerd in plaats van in het onderhouden van testinfrastructuur.
En er is een rustiger voordeel dat technische leiders noemen: de verkenning van de agent brengt combinaties aan het licht die niemand had bedacht om te testen. Wanneer je dekking afkomstig is van een systeem dat het hele product in kaart heeft gebracht in plaats van uit een backlog met testtickets, wordt 'heb je hieraan gedacht?' iets wat het platform aan jou vraagt.
Veelgestelde vragen
Kunnen de agents van QA.tech rolgebaseerde toegangscontrole in B2B SaaS testen?
Ja. De agent brengt de volledige applicatie vanaf een beheerdersaccount in kaart en test vervolgens als elke beperkte gebruiker, waarbij wordt geverifieerd dat elke rol precies ziet wat deze hoort te zien. Verwachte machtigingsblokkeringen worden als geslaagde resultaten vastgelegd.
Hoe gaan de agents van QA.tech om met datagestuurde testscenario's?
Dezelfde testcase wordt op instructie met andere gegevens uitgevoerd – “voer dit opnieuw uit met deze gegevens” – zonder opnieuw te moeten schrijven. Zowel positieve als negatieve gevallen worden afgeleid van het doel dat je beschrijft.
Ondersteunt QA.tech testen over web, API en mobiel in één flow?
Ja. Eén QA.tech-test kan webstappen, API-teststappen en native iOS- of Android-stappen combineren, waarbij journeys over meerdere oppervlakken end-to-end worden geverifieerd.
Hoe lang duurt het voordat QA.tech een complex SaaS-product leert kennen?
De eerste crawl duurt enkele minuten; een goed getraind begrip van rollen, gegevens en workflows wordt doorgaans in enkele weken normaal gebruik opgebouwd, waarbij de vragen van de agent afnemen naarmate de kennisgrafiek zich vult.
Heb je een product dat testtools aan het wankelen brengt? {{deeplink:260096:[Richt de agents van QA.tech op je stagingomgeving]:article_1}} – ze zijn gebouwd voor complexiteit.