QA agent · open source · Solo · design and build

QaAgent-Pro

By Mohit Kumar · Full-stack product engineer

Most browser agents optimise for finishing a task. QA has to do more: challenge assumptions, test the negative path, keep evidence, and never damage customer data.

QaAgent-Pro on GitHub (opens in a new tab)↗QaAgent (v1) (opens in a new tab)↗

QaAgent sample report preview

Project overview

I built QaAgent-Pro to make browser QA more deliberate: an explicit mission, repeatable actions, evidence for each result, and an independent decision about whether a failure is actually a product defect.

Separate execution from judgement

The system separates mission planning, risk analysis, deterministic execution, defect verification and release judgement into typed services. The executor uses registered Playwright actions; an external language model does not choose arbitrary runtime clicks.

A verifier considers UI, network, persistence and other captured evidence before classifying a failure. Product defects are distinguished from automation mistakes, environment problems and unclear requirements. An Excel workbook carries the evidence and release assessment to reviewers.

Write access has to be earned

A verified staging environment is required for write actions. Host, environment, tenant, visible marker and dedicated-account checks form the safety boundary. If verification fails, execution falls back to a read-only audit.

The documented Leads suite contains 56 deterministic scenarios. That is a defined suite, not a claim of complete coverage across every CRM. The repository exposes its scenario structure, quality checks and reporting approach so readers can inspect the implementation.

What I built

  • A local-first TypeScript and Playwright system that tests CRM applications the way a careful human QA engineer would.
  • Explicit roles as deterministic services: mission planner, risk analyst (likelihood × impact), executor, independent defect verifier and release judge.
  • A safety gate that only allows write actions on verified staging, and falls back to a read-only audit otherwise.
  • Stakeholder-ready Excel reports with embedded screenshots, evidence and a go, conditional-go or no-go verdict.
  • Deciding who a failure belongs to. An independent verifier separates product defects from automation, environment and unclear-rule failures before anything reaches the report.

Sources and live demo

Stack

  • TypeScript
  • Playwright
  • Node.js
  • Vitest
  • GitHub Actions
  • Excel reports

More work