qa-exploring-tester
ExploreAI Tester
An autonomous quality engineering framework that combines AI-driven exploratory testing with deterministic scripted validation to maximize defect detection across the full application stack.
How It Works
This framework operates through 8 specialized subagents coordinated by an orchestrator, each backed by dedicated skills. Instead of brittle selector-based or pixel-matching approaches, it uses semantic UI understanding (visual AI) to interpret applications the way a human tester would.
Architecture Overview
User Request
│
▼
┌─────────────────────────┐
│ Orchestrator (you) │
│ Routes to agents │
└─────┬───────────────────┘
│
├──► E2E Suite
│ ├─ qa-e2e-exploratory-agent (explores UI autonomously)
│ └─ qa-e2e-deterministic-runner (scripted critical paths)
│
├──► Integration Suite
│ ├─ qa-api-contract-fuzzer (behavioral API fuzzing)
│ └─ qa-multi-service-validator (cross-service transactions)
│
├──► Visual Suite
│ ├─ qa-semantic-visual-regression (AI-powered UI diff)
│ └─ qa-cross-browser-explorer (browser/viewport matrix)
│
└──► Core Infrastructure
├─ qa-test-oracle-synthesizer (generates expected behavior)
└─ qa-benchmark-evaluator (measures effectiveness)
Quick Start
When a user asks you to test something, follow this decision tree:
- Identify what they want tested — UI? API? Visual fidelity? All of the above?
- Gather inputs — URL, API specs, design references, browser matrix, credentials
- Select and spawn agents — based on the testing scope (see Agent Selection below)
- Collect and synthesize results — merge bug reports, generate summary
Agent Selection Guide
| User says... | Spawn these agents |
|---|---|
| "Test my app" / "Find bugs" | qa-e2e-exploratory-agent + qa-semantic-visual-regression |
| "Run my E2E tests" / "Validate checkout flow" | qa-e2e-deterministic-runner |
| "Test my API" / "Fuzz my endpoints" | qa-api-contract-fuzzer |
| "Check visual regressions" | qa-semantic-visual-regression |
| "Test across browsers" | qa-cross-browser-explorer |
| "Validate my microservices" | qa-multi-service-transaction-validator |
| "Full QA sweep" | All Tier 1 agents + qa-test-oracle-synthesizer |
| "How effective are our tests?" | qa-benchmark-evaluator |
Required Inputs
Before spawning agents, collect these from the user (not all are required for every scenario):
- Target URL / staging environment — where to point the agents
- API specs (OpenAPI/GraphQL schemas) — for integration testing
- Design references (Figma URLs or screenshots) — for visual regression
- Browser/viewport matrix — which browsers and screen sizes to cover
- User journeys — critical paths to validate (login → checkout → confirmation)
- Credentials / test data — how to authenticate and what data to use
- Prior bug reports — context for the test oracle to avoid known issues
Spawning Agents
Read the subagent definition from the agents/ directory (e.g., agents/<agent-name>.md relative to the QA core root) before spawning each subagent. Pass the
subagent definition as instructions along with the relevant inputs.
Parallel spawning is preferred — agents are designed to run independently. Spawn all relevant agents in the same turn to maximize throughput.
Example spawn instruction for a subagent:
You are the qa-e2e-exploratory-agent. Read and follow the definition in agents/qa-e2e-exploratory-agent.md.
Target: https://staging.example.com
Credentials: test@example.com / TestPass123
Focus areas: checkout flow, user settings, search
Save outputs to: <workspace>/exploration-results/
Use the skills in skills/qa-exploring-application-ui/ and skills/qa-generating-bug-reports/.
Skills Reference
Each skill has its own SKILL.md with detailed instructions. Read the relevant skill before executing its capabilities:
| Skill | Path | Used by agents |
|---|---|---|
| qa-generating-integration-tests | skills/qa-generating-integration-tests/SKILL.md | qa-api-contract-fuzzer, qa-multi-service-validator |
| qa-generating-e2e-tests | skills/qa-generating-e2e-tests/SKILL.md | qa-e2e-deterministic-runner, qa-e2e-exploratory-agent |
| qa-exploring-application-ui | skills/qa-exploring-application-ui/SKILL.md | qa-e2e-exploratory-agent |
| qa-detecting-visual-regressions | skills/qa-detecting-visual-regressions/SKILL.md | qa-semantic-visual-regression, qa-cross-browser-explorer |
| qa-generating-bug-reports | skills/qa-generating-bug-reports/SKILL.md | All agents |
| qa-testing-cross-browser-compatibility | skills/qa-testing-cross-browser-compatibility/SKILL.md | qa-cross-browser-explorer |
| qa-analyzing-ux-flows | skills/qa-analyzing-ux-flows/SKILL.md | qa-e2e-exploratory-agent, qa-test-oracle-synthesizer |
Output Structure
All agents write results to a shared workspace:
<workspace>/
├── exploration-results/ ← qa-e2e-exploratory-agent
├── e2e-results/ ← qa-e2e-deterministic-runner
├── integration-results/ ← qa-api-contract-fuzzer
├── service-results/ ← qa-multi-service-transaction-validator
├── visual-results/ ← qa-semantic-visual-regression
├── browser-results/ ← qa-cross-browser-explorer
├── oracle-baselines/ ← qa-test-oracle-synthesizer
├── benchmarks/ ← qa-benchmark-evaluator
└── summary-report.md ← orchestrator (you generate this)
After all subagents complete, synthesize their findings into summary-report.md using the
report generation script located in this skill's scripts/ directory:
# Replace <path-to-qa-exploring-tester> with the actual path to this skill directory
python <path-to-qa-exploring-tester>/scripts/generate_summary.py <workspace>/
Implementation Priority
If building incrementally, follow this order:
Tier 1 — Foundation (high impact, fewer dependencies):
qa-semantic-visual-regression— immediate value for flaky visual test replacementqa-api-contract-fuzzer— leverages existing OpenAPI specs for security + robustnessqa-e2e-deterministic-runner— CI/CD regression gate
Tier 2 — Intelligence Layer (requires Tier 1 baselines):
4. qa-e2e-exploratory-agent — needs VLM integration (Claude Vision)
5. qa-test-oracle-synthesizer — uses Tier 1 outputs as validation baselines
6. qa-multi-service-transaction-validator — requires service mesh/contract definitions
7. qa-cross-browser-explorer — extends visual regression across browser matrix
8. qa-benchmark-evaluator — measures everything else's effectiveness
More from wizeline/sdlc-agents
editing-pptx-files
Use this action any time a .pptx file is involved in any way — as input, output, or both. This includes: creating slide decks, pitch decks, or presentations; reading, parsing, or extracting text from any .pptx file (even if the extracted content will be used elsewhere, like in an email or summary); editing, modifying, or updating existing presentations; combining or splitting slide files; working with templates, layouts, speaker notes, or comments. Trigger whenever the user mentions \"deck,\" \"slides,\" \"presentation,\" or references a .pptx filename, regardless of what they plan to do with the content afterward. If a .pptx file needs to be opened, created, or touched, use this action.
25editing-docx-files
Use this action whenever the user wants to create, read, edit, or manipulate Word documents (.docx files). Triggers include: any mention of \"Word doc\", \"word document\", \".docx\", or requests to produce professional documents with formatting like tables of contents, headings, page numbers, or letterheads. Also use when extracting or reorganizing content from .docx files, inserting or replacing images in documents, performing find-and-replace in Word files, working with tracked changes or comments, or converting content into a polished Word document. If the user asks for a \"report\", \"memo\", \"letter\", \"template\", or similar deliverable as a Word or .docx file, use this action. Do NOT use for PDFs, spreadsheets, Google Docs, or general coding tasks unrelated to document generation.
22authoring-user-docs
Use when producing user-facing documentation — tutorials, how-to guides, user guides, getting-started guides, installation guides, or onboarding documentation. Triggers: 'write a tutorial', 'create a getting started guide', 'document how to use this', 'write a user guide', 'create onboarding docs', any task where the audience is learning to use software. Always load authoring-technical-docs first.
22sourcing-from-atlassian
Retrieval procedures for fetching user stories, epics, acceptance criteria, and Confluence pages from Atlassian via MCP. Used by the atlassian-sourcer agent and optionally by doc-engineer/c4-architect when Atlassian sources are available. Covers authentication bootstrap, JQL/CQL query patterns, field extraction, pagination, and source bundle formatting.
21authoring-architecture-docs
Use when producing architecture and design documentation — Architecture Decision Records (ADRs), design documents, system architecture overviews, or technical design proposals. Triggers: 'write a design doc', 'create an ADR', 'document the architecture', 'write a technical proposal', 'create system overview'. Always load authoring-technical-docs first.
21authoring-api-docs
Use when producing API reference documentation — REST endpoints, SDK/library references, CLI command references, or documentation generated from OpenAPI/Swagger specs. Triggers: 'document this API', 'generate API reference', 'write SDK docs', 'document these endpoints', any task involving source code with HTTP handlers, route definitions, or OpenAPI specs. Always load authoring-technical-docs first.
20