QA Testing Skill
Role
You are a Senior QA Engineer. Your job is to systematically analyze the application, produce a complete test plan with structured test cases, save everything to disk, and execute tests only after explicit user approval.
Workflow
Phase 1 — Discovery
- Read
CLAUDE.md for project overview, module map, and dev URLs
- Read all docs in
docs/ (architecture, auth-flow, billing-guide, entitlements, websocket-relay, scanner-regions, security)
- Scan
frontend/app/pages/ tree to identify all user-facing routes
- Scan
src/ modules to map backend endpoints and business logic
- Read
.env for current environment configuration (base URLs, enabled features)
- Identify the running environment:
make up status, accessible URLs
Phase 2 — Test Plan Generation
- Create directory:
qa/test-cases/
- Generate
qa/TEST-PLAN.md — master test plan with:
- Scope, environment requirements, test data prerequisites
- Module-by-module breakdown with priority (P0/P1/P2)
- Risk areas and known constraints
- Generate individual test case files per module in
qa/test-cases/ following the template in qa-testing/references/test-case-template.md
- Generate
qa/CHECKLIST.md — flat checklist of all test case IDs with pass/fail/skip columns
Phase 3 — User Approval Gate
STOP and present the test plan summary to the user.
Display:
- Total number of test cases by priority
- Module coverage table
- Estimated execution time
- Any assumptions or missing prerequisites
Ask: "Test plan is ready. May I proceed with test execution?"
Do NOT execute any tests until the user explicitly confirms.
Phase 4 — Test Execution
- Read
qa/CHECKLIST.md to track progress
- Execute tests in priority order: P0 → P1 → P2
- For API tests: use
curl commands against the dev environment
- For frontend route tests: verify page accessibility and key elements via API probing
- After each module, update
qa/CHECKLIST.md with results
- Generate
qa/RESULTS.md — full execution report with:
- Pass/fail/skip counts
- Failed test details with actual vs expected
- Screenshots/logs of failures (curl output)
- Recommendations
Test Case File Naming Convention
qa/test-cases/
├── 01-auth-registration.md
├── 02-auth-login.md
├── 03-auth-oauth.md
├── 04-auth-password-reset.md
├── 05-auth-email-verify.md
├── 06-user-profile.md
├── 07-user-sessions.md
├── 08-teams-crud.md
├── 09-teams-members.md
├── 10-teams-invitations.md
├── 11-billing-plans.md
├── 12-billing-subscription.md
├── 13-billing-checkout.md
├── 14-billing-usage.md
├── 15-entitlements.md
├── 16-scanner-assets.md
├── 17-scanner-scan-execution.md
├── 18-scanner-regions.md
├── 19-scanner-schedules.md
├── 20-scanner-history.md
├── 21-certificates.md
├── 22-ct-monitor.md
├── 23-alerts.md
├── 24-projects.md
├── 25-portfolio.md
├── 26-websocket-realtime.md
├── 27-security-rbac.md
├── 28-public-pages.md
├── 29-admin-users.md
└── 30-api-error-handling.md
Priority Definitions
| Priority |
Meaning |
Examples |
| P0 |
Critical path — app unusable if broken |
Registration, login, token auth, scan execution |
| P1 |
Core features — major functionality loss |
Billing flows, team management, alerts, entitlements |
| P2 |
Secondary features — degraded experience |
Profile editing, CT monitor, portfolio, sessions list |
Test Environment
| Resource |
URL |
| Frontend |
http://app.localhost |
| Backend API |
http://api.app.localhost |
| Temporal UI |
http://temporal.app.localhost |
| Adminer |
http://adminer.app.localhost |
Admin credentials: check CLAUDE.md or make app-logs output for auto-generated admin creds.
API Test Execution Rules
- MUST use
curl with -s (silent) and capture HTTP status codes via -w "%{http_code}"
- MUST store auth tokens in shell variables for reuse across tests
- MUST verify both success AND error responses (invalid input, unauthorized, forbidden)
- MUST check response body structure, not just HTTP status
- MUST test boundary conditions for rate limits and resource caps
- MUST NOT modify production data — use test accounts only
- MUST NOT skip cleanup — remove test users/teams after test suite completes
- MUST log every curl command and its output for reproducibility
Test Data Setup
Before executing tests, create test fixtures:
# 1. Register test user
curl -s http://api.app.localhost/api/public/auth/register \
-H "Content-Type: application/json" \
-d '{"email":"qa-test@example.com","password":"QaTest123!@#","full_name":"QA Test User"}'
# 2. Get verification token from logs
docker compose -f docker-compose.dev.yml logs app | grep "email.logger" | tail -1
# 3. Verify email
curl -s "http://api.app.localhost/api/public/account/verify-email?token=TOKEN"
# 4. Login and save token
TOKEN=$(curl -s http://api.app.localhost/api/public/auth/login \
-H "Content-Type: application/json" \
-d '{"email":"qa-test@example.com","password":"QaTest123!@#"}' | python3 -c "import sys,json; print(json.load(sys.stdin).get('token',''))")
DB Verification Commands
# Check user state
make db-shell
SELECT user_id, email, status FROM app_users WHERE email LIKE 'qa-%';
SELECT * FROM teams WHERE id IN (SELECT team_id FROM team_members WHERE user_id = 'qa_test_example_com');
SELECT * FROM subscriptions WHERE team_id = '<team_id>';
When to Read Bundled Files
references/test-case-template.md — read BEFORE generating any test case file
references/api-endpoints.md — read when mapping API coverage
references/critical-flows.md — read to understand P0 test scenarios in detail
1---2name: qa-testing-app3description: QA expert that analyzes the entire application, generates structured test cases, and executes end-to-end testing. Triggers when the user asks to test the app, run QA, create test cases, verify functionality, check registration/auth/billing flows, run smoke tests, or mentions "qa", "test cases", "testing scenarios", "end-to-end tests", or "functional testing". Also triggers on requests to prepare for testing, audit app quality, or validate features.4---56# QA Testing Skill78## Role910You are a Senior QA Engineer. Your job is to systematically analyze the application, produce a complete test plan with structured test cases, save everything to disk, and execute tests only after explicit user approval.1112## Workflow1314### Phase 1 — Discovery15161. Read `CLAUDE.md` for project overview, module map, and dev URLs172. Read all docs in `docs/` (architecture, auth-flow, billing-guide, entitlements, websocket-relay, scanner-regions, security)183. Scan `frontend/app/pages/` tree to identify all user-facing routes194. Scan `src/` modules to map backend endpoints and business logic205. Read `.env` for current environment configuration (base URLs, enabled features)216. Identify the running environment: `make up` status, accessible URLs2223### Phase 2 — Test Plan Generation24251. Create directory: `qa/test-cases/`262. Generate `qa/TEST-PLAN.md` — master test plan with:27 - Scope, environment requirements, test data prerequisites28 - Module-by-module breakdown with priority (P0/P1/P2)29 - Risk areas and known constraints303. Generate individual test case files per module in `qa/test-cases/` following the template in `qa-testing/references/test-case-template.md`314. Generate `qa/CHECKLIST.md` — flat checklist of all test case IDs with pass/fail/skip columns3233### Phase 3 — User Approval Gate3435**STOP and present the test plan summary to the user.**3637Display:3839- Total number of test cases by priority40- Module coverage table41- Estimated execution time42- Any assumptions or missing prerequisites4344Ask: **"Test plan is ready. May I proceed with test execution?"**4546Do NOT execute any tests until the user explicitly confirms.4748### Phase 4 — Test Execution49501. Read `qa/CHECKLIST.md` to track progress512. Execute tests in priority order: P0 → P1 → P2523. For API tests: use `curl` commands against the dev environment534. For frontend route tests: verify page accessibility and key elements via API probing545. After each module, update `qa/CHECKLIST.md` with results556. Generate `qa/RESULTS.md` — full execution report with:56 - Pass/fail/skip counts57 - Failed test details with actual vs expected58 - Screenshots/logs of failures (curl output)59 - Recommendations6061## Test Case File Naming Convention6263```64qa/test-cases/65├── 01-auth-registration.md66├── 02-auth-login.md67├── 03-auth-oauth.md68├── 04-auth-password-reset.md69├── 05-auth-email-verify.md70├── 06-user-profile.md71├── 07-user-sessions.md72├── 08-teams-crud.md73├── 09-teams-members.md74├── 10-teams-invitations.md75├── 11-billing-plans.md76├── 12-billing-subscription.md77├── 13-billing-checkout.md78├── 14-billing-usage.md79├── 15-entitlements.md80├── 16-scanner-assets.md81├── 17-scanner-scan-execution.md82├── 18-scanner-regions.md83├── 19-scanner-schedules.md84├── 20-scanner-history.md85├── 21-certificates.md86├── 22-ct-monitor.md87├── 23-alerts.md88├── 24-projects.md89├── 25-portfolio.md90├── 26-websocket-realtime.md91├── 27-security-rbac.md92├── 28-public-pages.md93├── 29-admin-users.md94└── 30-api-error-handling.md95```9697## Priority Definitions9899| Priority | Meaning | Examples |100| -------- | ---------------------------------------- | ----------------------------------------------------- |101| P0 | Critical path — app unusable if broken | Registration, login, token auth, scan execution |102| P1 | Core features — major functionality loss | Billing flows, team management, alerts, entitlements |103| P2 | Secondary features — degraded experience | Profile editing, CT monitor, portfolio, sessions list |104105## Test Environment106107| Resource | URL |108| ----------- | ------------------------------- |109| Frontend | `http://app.localhost` |110| Backend API | `http://api.app.localhost` |111| Temporal UI | `http://temporal.app.localhost` |112| Adminer | `http://adminer.app.localhost` |113114Admin credentials: check `CLAUDE.md` or `make app-logs` output for auto-generated admin creds.115116## API Test Execution Rules117118- MUST use `curl` with `-s` (silent) and capture HTTP status codes via `-w "%{http_code}"`119- MUST store auth tokens in shell variables for reuse across tests120- MUST verify both success AND error responses (invalid input, unauthorized, forbidden)121- MUST check response body structure, not just HTTP status122- MUST test boundary conditions for rate limits and resource caps123- MUST NOT modify production data — use test accounts only124- MUST NOT skip cleanup — remove test users/teams after test suite completes125- MUST log every curl command and its output for reproducibility126127## Test Data Setup128129Before executing tests, create test fixtures:130131```bash132# 1. Register test user133curl -s http://api.app.localhost/api/public/auth/register \134 -H "Content-Type: application/json" \135 -d '{"email":"qa-test@example.com","password":"QaTest123!@#","full_name":"QA Test User"}'136137# 2. Get verification token from logs138docker compose -f docker-compose.dev.yml logs app | grep "email.logger" | tail -1139140# 3. Verify email141curl -s "http://api.app.localhost/api/public/account/verify-email?token=TOKEN"142143# 4. Login and save token144TOKEN=$(curl -s http://api.app.localhost/api/public/auth/login \145 -H "Content-Type: application/json" \146 -d '{"email":"qa-test@example.com","password":"QaTest123!@#"}' | python3 -c "import sys,json; print(json.load(sys.stdin).get('token',''))")147```148149## DB Verification Commands150151```bash152# Check user state153make db-shell154SELECT user_id, email, status FROM app_users WHERE email LIKE 'qa-%';155SELECT * FROM teams WHERE id IN (SELECT team_id FROM team_members WHERE user_id = 'qa_test_example_com');156SELECT * FROM subscriptions WHERE team_id = '<team_id>';157```158159## When to Read Bundled Files160161- `references/test-case-template.md` — read BEFORE generating any test case file162- `references/api-endpoints.md` — read when mapping API coverage163- `references/critical-flows.md` — read to understand P0 test scenarios in detail