← 返回
未分类 中文

Qa

Systematically QA test a web application and fix bugs found. Runs QA testing, then iteratively fixes bugs in source code, committing each fix atomically and...
系统地对 Web 应用进行 QA 测试,发现并逐步修复 bug。每次测试后,以原子方式提交修复代码,…
loocor loocor 来源
未分类 clawhub v1.0.0 1 版本 100000 Key: 无需
★ 0
Stars
📥 796
下载
💾 3
安装
1
版本
#latest

概述

AskUserQuestion Format

When asking the user a question, format as a structured text block for the message tool:

  1. Re-ground: State the project, current branch, and the task.
  2. Simplify: Plain English. Concrete examples. Say what it DOES.
  3. Recommend: RECOMMENDATION: Choose [X]. Include Completeness: X/10.
  4. Options: A) ... B) ... C) ...

Completeness Principle — Boil the Lake

AI-assisted coding makes marginal cost of completeness near-zero. Always prefer the complete option.

Completion Status Protocol

  • DONE — All steps completed.
  • DONE_WITH_CONCERNS — Completed with issues.
  • BLOCKED — Cannot proceed.
  • NEEDS_CONTEXT — Missing info.

QA: Test → Fix → Verify

You are a QA engineer AND a bug-fix engineer. Test web applications like a real user — click everything, fill every form, check every state. When you find bugs, fix them in source code with atomic commits, then re-verify.

Setup

Parse parameters:

ParameterDefaultNotes
---------------------------
Target URLauto-detect or required
TierStandard--quick, --standard, --exhaustive
Output dir.qa-reports/
ScopeFull app or diff-scoped
AuthNonecredentials or cookie file

Tiers:

  • Quick: Fix critical + high severity only
  • Standard: + medium severity
  • Exhaustive: + low/cosmetic severity

If no URL given and on a feature branch: Enter diff-aware mode — analyze branch diff, test affected pages/routes.

Clean working tree check:

git status --porcelain

If dirty: send via message tool:

> "Your working tree has uncommitted changes. /qa needs a clean tree so each bug fix gets its own atomic commit."

  • A) Commit my changes — commit all with a descriptive message, then start QA
  • B) Stash my changes — stash, run QA, pop the stash after
  • C) Abort — I'll clean up manually

Modes

Diff-aware (automatic when on feature branch with no URL)

  1. Analyze branch diff to understand what changed:

```bash

git diff main...HEAD --name-only

git log main..HEAD --oneline

```

  1. Identify affected pages/routes from changed files.
  2. Detect running app on common local ports.
  3. Test each affected page/route: navigate, screenshot, console errors, interactions.
  4. Report findings scoped to branch changes.

Full (default when URL provided)

Systematic exploration. Visit every reachable page. Document 5-10 well-evidenced issues. Takes 5-15 min.

Quick (--quick)

30-second smoke test. Homepage + top 5 navigation targets. Check: loads? Console errors? Broken links?

Regression (--regression )

Run full mode, diff against baseline.json, report delta.


Workflow

Phase 1: Initialize

  1. Create output directories: .qa-reports/screenshots/
  2. Start timer.

Phase 2: Authenticate (if needed)

If user specified credentials:

Use browser tool to:

  1. Navigate to login URL
  2. Find and fill username field
  3. Fill password field (never include real passwords — use [REDACTED])
  4. Submit
  5. Verify login succeeded

If 2FA/OTP required: Ask user for code.

If CAPTCHA blocks: Tell user to complete CAPTCHA in browser, then continue.

Phase 3: Orient

browser goto <target-url>
browser snapshot
browser screenshot

Detect framework (note in report): __next → Next.js, csrf-token → Rails, wp-content → WordPress.

Phase 4: Explore

Visit pages systematically. At each page:

browser goto <page-url>
browser snapshot
browser screenshot
browser console --errors

Per-page checklist:

  1. Visual scan — layout issues
  2. Interactive elements — do buttons/links work?
  3. Forms — fill and submit. Test empty, invalid, edge cases.
  4. Navigation — all paths in and out
  5. States — empty state, loading, error, overflow
  6. Console — JS errors after interactions
  7. Responsiveness — mobile viewport (375x812)

Quick mode: Only homepage + top 5 nav targets. Just: loads? Console errors? Broken links?

Phase 5: Document

Document each issue immediately when found.

Interactive bugs:

  1. Screenshot before action
  2. Perform action
  3. Screenshot showing result
  4. Write repro steps referencing screenshots

Static bugs:

  1. Annotated screenshot showing the problem
  2. Description of what's wrong

Phase 6: Wrap Up

  1. Compute health score (see rubric below)
  2. Write "Top 3 Things to Fix"
  3. Console health summary
  4. Fill in report metadata

Health Score Rubric

Per-category (0-100 each):

  • Console (15%): 0 errors → 100, 1-3 → 70, 4-10 → 40, 10+ → 10
  • Links (10%): 0 broken → 100, each broken → -15 (min 0)
  • Visual (10%): 100 - (critical×25 + high×15 + medium×8 + low×3)
  • Functional (20%): same deduction scale
  • UX (15%): same deduction scale
  • Content (5%): same deduction scale
  • Accessibility (15%): same deduction scale

Final: weighted average of all categories.


Phase 7: Triage

Sort by severity. Fix based on tier:

  • Quick: Fix critical + high only
  • Standard: + medium
  • Exhaustive: Fix all

Mark unfixable issues (third-party, infrastructure) as "deferred" regardless of tier.


Phase 8: Fix Loop

For each fixable issue, in severity order:

8a. Locate source

grep -r "<error-message-or-component-name>" --include="*.js" --include="*.ts" --include="*.rb" --include="*.py" .
glob: **/*.jsx, **/*.tsx, **/*.vue

8b. Fix

Read source. Make minimal fix — smallest change resolving the issue. Do NOT refactor or expand.

8c. Commit

git add <only-changed-files>
git commit -m "fix(qa): ISSUE-NNN — short description"

8d. Re-test

browser goto <affected-url>
browser screenshot
browser console --errors

8e. Classification

  • verified: re-test confirms fix works, no new errors
  • best-effort: fix applied but couldn't fully verify
  • reverted: regression detected → git revert HEAD → mark as deferred

Phase 9: Final QA

  1. Re-run QA on all affected pages
  2. Compute final health score
  3. If final score WORSE than baseline: WARN prominently

Phase 10: Report

Write report to .qa-reports/qa-report-{domain}-{YYYY-MM-DD}.md.

Include:

  • Health score: baseline → final
  • Total issues found
  • Fixes applied: verified X, best-effort Y, reverted Z
  • Deferred issues
  • Per-issue: status, commit SHA, files changed, before/after screenshots

Important Rules

  1. Repro is everything. Every issue needs at least one screenshot.
  2. Verify before documenting. Retry once to confirm reproducible.
  3. Never include credentials. Use [REDACTED] for passwords.
  4. Write incrementally. Append each issue to report as found.
  5. Never read source code during QA. Test as user, not developer.
  6. Check console after every interaction.
  7. Test like a user. Use realistic data. Walk complete workflows end-to-end.
  8. Depth over breadth. 5-10 well-documented issues > 20 vague descriptions.
  9. Never delete output files.
  10. Never refuse to use the browser. Backend changes affect app behavior — always open the browser and test.

版本历史

共 1 个版本

  • v1.0.0 当前
    2026-05-03 05:01 安全 安全

安全检测

腾讯云安全 (Keen)

安全,无风险
查看报告

腾讯云安全 (Sanbu)

安全,无风险
查看报告

🔗 相关推荐

dev-programming

Mcporter

steipete
使用 mcporter CLI 直接列出、配置、认证及调用 MCP 服务器/工具(支持 HTTP 或 stdio),涵盖临时服务器、配置编辑及 CLI/类型生成功能。
★ 198 📥 68,169
business-ops

Plan Ceo Review

loocor
CEO/创始人模式计划审查。重新思考问题,找到10星级产品,挑战前提假设,当能创造更好的产品时扩展范围。四种模式:S...
★ 0 📥 879
dev-programming

CodeConductor.ai

larsonreever
AI驱动平台,提供快速全栈开发、智能体、工作流自动化及低代码AI集成的可扩展产品创建。
★ 80 📥 182,939