SmartBear and Multi-Agent QA

What It Covers

SmartBear VP of AI Fitz Nolan explains how BearQ, an AI-native QA platform, deploys multi-agent systems to autonomously explore web applications, author test cases, and maintain quality at the pace AI coding tools now generate code, covering architecture, test data challenges, and QA's evolving role.

Key Questions Answered

• •Multi-agent scope separation: BearQ uses three distinct agent types — exploration, test runner, and QA lead — each with deliberately narrow permissions. Test runner agents own the browser session exclusively; QA lead agents hold full account access and expensive models. This separation prevents runaway costs and unintended side effects while keeping most test runs fast and cheap.
• •Test data as distributed systems problem: Running concurrent agents against a shared application account creates state conflicts — one agent leaves items in a cart, another expects an empty cart. The practical near-term solution is provisioning one dedicated test account per parallel agent, treating test data isolation the same way distributed systems treat resource locking to avoid race conditions.
• •Black-box component inference: BearQ agents explore applications with zero prior code knowledge, using computer vision and vision LLMs to identify 20–30 reusable UI components. These inferred components are then presented to QA teams for human approval before becoming durable, reusable test building blocks — grounding AI-generated understanding in human-confirmed reality.
• •Self-healing test architecture: When a test runner agent fails a step, it spawns a QA lead agent that collects additional screenshots, queries recent run history, performs non-destructive browser actions like scrolling, and returns a corrected step definition. The tester agent never sees the full QA lead conversation — only a digest summary — keeping context windows lean.
• •QA role shifts to component-level abstraction: Rather than manually scripting hundreds of page-level tests, QA practitioners should reframe their work around 30–40 reusable application components and their relationships. Repetitive CRUD-level smoke tests should be fully delegated to agents, freeing QA teams to function as directors who approve component models, review failure pattern reports, and issue high-level agent directives.