"Testing shows the presence, not the absence of bugs." — Edsger Dijkstra. True. But some approaches show presence faster than others.
I have been using the chrome-devtools MCP for months — calling browser tools directly in my Claude Code session for debugging and running manual test cases. It works well. But the community was clearly gravitating toward something different: spawning sub-agents that each run a batch of browser tests in parallel.
I wanted to know whether the speed difference was real or just felt that way. So I ran both tools against the same test suite, same app, same machine — and kept notes.
The Setup
200 manual tests across 29 groups
I was testing our billing integration and feature usage analytics module. The test plan covered the admin dashboard, tenant billing flows, webhook delivery, internationalization, accessibility, security, and regression.
Approach one — agent-browser: spawn multiple Claude Code sub-agents, give each a batch of tests, and let them navigate, click, fill, snapshot, and evaluate JavaScript in parallel. Four agents running simultaneously.
Approach two — chrome-devtools direct: call the MCP browser tools in my main session, one test group at a time, sequentially. Both ran without manual approvals. Same test plan, same assertions, different execution model.
The Numbers
Where the parallelism advantage actually comes from
Agent-browser: 28 minutes. Chrome-devtools direct: 90 minutes.
That is ~7.1 tests/min against ~2.2 tests/min — a 3–4x speedup in wall-clock time for a large suite, including the overhead of spawning four agents.
Agent 1 — Groups 0, 1, 11
338 seconds, 77 tool calls
Agent 2 — Groups 9–16, billing
373 seconds, 25 tool calls
Agent 3 — Groups 2–8, analytics
1694 seconds, 86 tool calls — the bottleneck that set total wall-clock time
Agent 4 — Groups 25–29, regression
687 seconds, 150 tool calls
Total wall-clock was 1694 seconds (28 minutes), dominated by the slowest agent. The sequential equivalent would have been 3092 seconds (51 minutes).
The interesting part: tool calls per test were roughly the same in both approaches, about 2.5 per test. The agents were not doing less work per test. The entire speed advantage is parallelism — four agents running simultaneously instead of one running sequentially.
Where Agent-Browser Falls Short
Three failure modes worth planning for
The Hybrid Pattern That Actually Works
Agents for breadth, direct calls for depth
First pass — agent-browser, parallel batches of 8–10 tests
Get a fast baseline: what is passing, what is failing, what is blocked. Scope each agent to one logical area (auth, admin UI, billing, i18n). This is where the 28-minute parallel advantage pays for itself.
Triage — review the results table
Categorize failures: app bug, test environment issue, spec mismatch, or MCP flakiness. Not every failure needs a deep dive.
Deep dive — chrome-devtools direct on each confirmed failure
Step through the failing test manually. Get the raw DOM evidence, the network calls, and the console logs in your own thread before writing the bug report.
Regression sweep — agent-browser again after fixes
Re-run the full suite or the affected groups and diff the results table against the first pass.
The first pass took 28 minutes and found 15 bugs. The deep dives took 10–15 minutes each and confirmed the root causes. The regression re-run was another 28 minutes. Total: roughly 90 minutes to fully test a new billing and analytics feature across 200 test cases. Running the entire suite sequentially would have taken close to 3 hours.
Conclusion
Agent-browser is 3–4x faster for large test suites, and the gain comes entirely from parallelism, not from fewer tool calls.
Scope each agent to 6–10 tests. Beyond that, context windows fill up and results get truncated.
MCP disconnection is the biggest operational risk — session-dependent tool availability means you can lose your browser mid-suite with no clean recovery.
Use both. Agent-browser for the fast first pass and regression sweeps; chrome-devtools direct for debugging confirmed failures where you need raw evidence in your thread.