De adoptie is hoog, maar de statistieken zijn belangrijk
Uit het onderzoek van Stack Overflow uit 2025 bleek dat 84% van de respondenten AI-tools gebruikte of van plan was te gebruiken in hun ontwikkelingsproces; Van de professionele ontwikkelaars meldde 51% dat ze deze dagelijks gebruiken. De vraag heeft betrekking op AI-tools in het algemeen: het bewijst niet dat dat percentage code genereert, noch beschrijft het specifiek QA-teams.
Om naar de andere kant van de stroom te kijken, publiceerde DeviQA in juli 2026 zijn eigen onderzoek onder 300 QA-professionals, SDET- en testleiders. 52% zei dat ze een toename van het aantal bugs hebben waargenomen sinds de ontwikkeling gebruik begon te maken van AI, en 58% zag een grotere testlast. Het is een relevant signaal om te onderzoeken, geen representatieve inschatting van de sector: het is een interne leverancierssteekproef, gebaseerd op zelfgerapporteerde reacties en ervaringen.
In het onderzoek van DeviQA wordt gevraagd naar veranderingen die deelnemers tijdelijk associëren met de adoptie van AI; het vergelijkt geen gelijkwaardige opslagplaatsen met en zonder AI, noch controleert het de omvang van de wijzigingen, de ervaring, de leveringssnelheid of het beoordelingsbeleid. Het kan er ook toe leiden dat er nu meer defecten worden gedetecteerd of gerapporteerd. Daarom is het niet gepast om te concluderen dat AI op zichzelf een algemene toename van het aantal bugs veroorzaakt.
DORA 2025 stelt voor om AI te zien als een versterker van het bestaande werksysteem: snelle feedback, interne platforms en duidelijke prioriteiten helpen; Zwakke processen en moeilijk te beoordelen veranderingen worden ook versterkt. Onderzoek rapporteert associaties, geen universele causale regel. De praktische boodschap is om de gehele stroom te meten, en variatie niet toe te schrijven aan één enkel instrument.
Wat u moet meten voordat u het proces wijzigt
Registreer over meerdere iteraties hoeveel wijzigingen er zijn aangebracht en welke omvang; hoeveel gebreken verschijnen vóór en na publicatie; de ernst ervan; hoe vaak een zaak wordt heropend; hoe lang het duurt voordat QA ontvangt en reageert; en hoeveel werk wordt herhaald. Afzonderlijke wijzigingen kunnen alleen met behulp van AI worden aangebracht als het team deze op consistente wijze kan identificeren en zonder elke persoon in de gaten te houden.
Vergelijk perioden zorgvuldig: gebruik dezelfde definities, noteer product- of apparatuurwijzigingen en bekijk zowel wat de tests detecteren als welke waarschuwingen vals blijken te zijn. Als er meer wijzigingen worden vrijgegeven, kan het totale aantal defecten toenemen, ook al heeft elke wijziging minder. Door defecten te vergelijken met het aantal en de omvang van de wijzigingen, kunt u begrijpen wat er is gebeurd.
Stel je voor dat voordat het team tien wijzigingen per week uitbracht en vier defecten ontdekte; Nadat hij een assistent heeft toegevoegd, publiceert hij twintig wijzigingen en vindt hij er zes. Het totaal steeg, maar het percentage ging van 0,4 naar 0,3 defecten per wijziging. Zonder de noemer vermengt de kop ‘er zijn meer bugs’ het leveringsvolume met de kwaliteit per eenheid. De detectie kan ook toenemen omdat er tests zijn toegevoegd, betere logboeken of intensievere beoordelingen. In dat geval kan het zien van meer storingen erop duiden dat het systeem het beter doet, en niet dat het product slechter is geworden.
Het is handig om vier maatregelen te onderscheiden: gebreken die vóór publicatie zijn gevonden; defecten die de productie hebben bereikt; ernst en impact; en de kosten voor het onderzoeken en corrigeren ervan. Het vinden van meer kleine problemen tijdens het testen betekent niet dat er meer gebruikersincidenten zijn. Omgekeerd kan een stabiel tarief een groter risico verbergen als het aantal wijzigingen toeneemt of als fouten zich concentreren in betalingen, machtigingen of gegevens. Bepaal wat u gaat vertellen voordat u gaat vergelijken.
Wat voegt het beoordelen van de gegenereerde code toe, naast het uitvoeren van tests
Het feit dat alle tests slagen, betekent op zichzelf niet dat een verandering gemakkelijk vol te houden is, de projectregels respecteert of voldoende wordt getest. In een onderzoek uit 2026 vroeg METR vier beheerders van drie projecten om 296 wijzigingen te beoordelen die waren opgesteld door agenten en goedgekeurd door een geautomatiseerde evaluatie. Gemiddeld accepteerden de verantwoordelijken minder wijzigingen dan de beoordelaar: het verschil bedroeg 24 procentpunten. De steekproef was beperkt en de agenten konden hun voorstellen niet corrigeren nadat ze commentaar hadden ontvangen; Het resultaat maakt wel een duidelijk onderscheid: ‘de tests zijn geslaagd’ en ‘het team is bereid de verandering te integreren’ betekenen niet hetzelfde.
Controleer daarom naast het controleren of de functie doet wat er verwacht wordt ook of de wijziging andere functies beïnvloedt, hoe er met fouten wordt omgegaan, of de beveiliging wordt gerespecteerd en of de nieuwe tests het probleem ook daadwerkelijk detecteren. Een gegenereerde test kan dezelfde fout herhalen als de code. Het vraagt elke test om verband te houden met een vereiste en controleert of deze mislukt wanneer de functie die hij moest beschermen, wordt verwijderd.
Leg gedurende vier tot zes weken een basislijn vast met stabiele definities en selecteer vergelijkbare veranderingen op basis van omvang, risico en component. Als het team AI gebruikt, label de verandering dan vrijwillig en op functieniveau, niet op persoonsniveau. Vergelijk indien mogelijk groepen of perioden, noteer gelijktijdige veranderingen (nieuwe dekking, refactor, teamverloop) en normaliseer door veranderingen, gewijzigde lijnen of blootstelling. Gebruik geen enkel percentage als doel: dit kan het verbergen van defecten aanmoedigen of de dekking verminderen.
Een handig dashboard laat zien hoeveel defecten er optreden, hoe ernstig ze zijn en in welk stadium ze worden ontdekt; hoeveel bereiken de productie of heropenen; hoe lang het duurt voordat het team een reactie ontvangt; en hoeveel geautomatiseerde waarschuwingen een persoon bevestigt. Bewaar voorbeelden om te begrijpen waar de problemen vandaan komen. Als het team sneller werkt, maar er ernstigere defecten in de productie optreden of de herbewerking toeneemt, is het proces niet verbeterd. Als u meer opvangt voordat u publiceert en minder de productie bereikt, ondervindt u mogelijk nu betere problemen.
Een recente enquête wijst op een hogere QA-werkdruk
Een afzonderlijk onderzoek van DeviQA, gepubliceerd in september 2026 en beantwoord door 4.000 QA-professionals, helpt de andere kant van de stroom te beschrijven. 65% zei dat functies eerder getest worden; 64% gaf aan dat er meer functies tegelijkertijd arriveren; 55% observeerde een langere QA-staart; en 52% rapporteerde meer test-correct-hertest-cycli. Deze cijfers mogen niet worden verward met de vorige enquête onder 300 mensen: het zijn verschillende instrumenten, steekproeven en vragen. Ze meten ook niet defecten per verandering of bewijzen dat AI de oorzaak is. Ze laten een concrete spanning zien die een team kan controleren: sneller inzetten elimineert beoordeling, regressie of coördinatie niet, en het kan het werk concentreren dat QA ontvangt.
Het praktische gevolg is dat er niet meer blinde tests worden toegewezen. Het is de moeite waard om te vragen waar de wachtrij zich vormt: wachten op de omgeving, onvolledige vereisten, late beoordeling, gegevens die moeilijk voor te bereiden zijn, periodieke fouten of te veel niet-bevestigde waarschuwingen. Elke oorzaak vereist een andere reactie. Als het team niet weet wanneer een levering aankomt of wat er is veranderd, kan een tweede AI-tool voor ruis zorgen; Als u het verschil, het risico en de verwachte uitkomst kent, kunt u beter prioriteiten stellen. Het meet de wachttijd gescheiden van de effectieve testtijd: zo onderscheid je een capaciteitsprobleem van een doorstroomprobleem.
Een absolute telling geeft antwoord op het aantal gevonden defecten; het geeft niet alleen aan of elke verandering erger is. Stel dat een team tien wijzigingen heeft beoordeeld en vier gebreken heeft gevonden, en er vervolgens twintig heeft beoordeeld en er zes heeft gevonden. Het totaal groeide, maar de wisselkoers daalde. Zelfs dat percentage kan misleidend zijn als de nieuwe veranderingen groter zijn, verschillende componenten raken of meer aandacht krijgen. Gebruik verschillende noemers, afhankelijk van de beslissing: herziene wijzigingen voor triagebelasting, omvang en risico om de blootstelling te vergelijken, uitvoeringen voor stabiliteit, en gebruikers of transacties om de impact te schatten. Maak van coderegels geen universele maatstaf voor kwaliteit: ze dienen als context en niet als vervanging voor functioneel risico.
Het maakt ook onderscheid tussen ernst, timing van detectie en kosten. Een blokkerend defect dat wordt gedetecteerd voordat het wordt vrijgegeven, kan een teken zijn dat de tests werken; een kleine fout in productie kan minder ernstig zijn dan een fout in de machtigingen, ook al tellen beide als “een bug”. Leg vast of het probleem te maken had met eisen, implementatie, integratie, data of omgeving. Deze classificatie dient om het proces te corrigeren en niet de auteur of de tool de schuld te geven. Bewaar representatieve voorbeelden en bekijk wat er tussen periodes is veranderd; een metriek zonder uitleg van de casus kan het team ertoe aanzetten het verkeerde getal te optimaliseren.
Hoe je een tool evalueert met criteria om het weg te gooien
Voordat u AI aan de cyclus toevoegt, definieert u een vraag die een negatief antwoord mogelijk maakt: bijvoorbeeld: “Vermindert op verhalen gebaseerde tests de weglatingen zonder de beoordelingstijd te vergroten?” Kies een begrensde stroom, stel een basislijn in en spreek af wat telt als overslaan, dupliceren, geldige waarschuwing en herwerken. Vergelijk verschillende iteraties en wijzigingen met een vergelijkbaar risico. Wissel indien mogelijk taken of teams af; Als dat niet het geval is, noteer dan de veranderingen in dekking, personeel, vrijgave en hulpmiddelen die een verschil kunnen verklaren. Ken geen causaliteit toe aan een voor/na-vergelijking als er tegelijkertijd andere veranderingen waren.
Gecontroleerd testen heeft ook een stopregel nodig. Als de tool niet over voldoende context beschikt, zonder toestemming echte gegevens gebruikt, een niet-geïsoleerde omgeving wijzigt of resultaten oplevert die niemand kan reproduceren, moet deze worden stopgezet en in afwachting van uitvoering worden uitgevoerd. Menselijke beoordeling richt zich op relevante risico's en accepteert niet alles wat het model genereert. Bij het afsluiten worden de resultaten gepresenteerd, samen met de monsterlimieten, valse positieven, ontsnapte defecten en de kosten van de beoordelingstijd. Als de gegevens geen conclusie ondersteunen, is dat een geldige conclusie: de volgende stap is het verbeteren van de meting, niet het verklaren van succes.
Een automatische waarschuwing is een waarneming die nog moet worden geclassificeerd. Het kan wijzen op een nieuw defect, een bekende regressie, een visueel verschil dat geen impact heeft, een milieuprobleem of een test die niet langer het verwachte gedrag vertegenwoordigt. Als het dashboard alles bij elkaar optelt als 'bugs', lijkt het erop dat de tool meer problemen vindt, ook al zijn de meeste duplicaten of ruis. Behoudt verschillende statussen voor het vinden van ontvangen, beoordeeld, reproduceerbaar, bevestigd, duplicaat en weggegooid; Het registreert ook de reden van de teruggooi. Op deze manier kan het team de nauwkeurigheid en de kosten van de triage meten zonder een geldig signaal onder het gemiddelde te verbergen.
Bij de analyse moet ook naar de tijd worden gekeken. Een binnen enkele minuten gedetecteerde storing kost niet dezelfde kosten als een rapport dat aan het einde van een nachtelijke suite verschijnt; Een correcte waarschuwing die niemand pas na de vrijgave ziet, verbetert ook de preventie niet. Noteer hoe lang het duurde voordat het systeem rapporteerde, wanneer iemand het beoordeelde en wanneer het werd gesloten. Als het ruwe aantal waarschuwingen toeneemt, maar het bevestigde percentage daalt en de beoordelingstijd toeneemt, zou het volgende experiment de selectie en context moeten verbeteren en niet nog meer gevallen moeten genereren. Als de vroege detectie van relevante defecten toeneemt en de daaropvolgende herbewerking afneemt, is er een sterker signaal van bruikbaarheid.