{ "schemaVersion": "1.0", "item": { "slug": "afrexai-qa-engine", "name": "QA & Test Engineering Command Center", "source": "tencent", "type": "skill", "category": "开发工具", "sourceUrl": "https://clawhub.ai/1kalin/afrexai-qa-engine", "canonicalUrl": "https://clawhub.ai/1kalin/afrexai-qa-engine", "targetPlatform": "OpenClaw" }, "install": { "downloadMode": "redirect", "downloadUrl": "/downloads/afrexai-qa-engine", "sourceDownloadUrl": "https://wry-manatee-359.convex.site/api/v1/download?slug=afrexai-qa-engine", "sourcePlatform": "tencent", "targetPlatform": "OpenClaw", "installMethod": "Manual import", "extraction": "Extract archive", "prerequisites": [ "OpenClaw" ], "packageFormat": "ZIP package", "includedAssets": [ "README.md", "SKILL.md" ], "primaryDoc": "SKILL.md", "quickSetup": [ "Download the package from Yavira.", "Extract the archive and review SKILL.md first.", "Import or place the package into your OpenClaw setup." ], "agentAssist": { "summary": "Hand the extracted package to your coding agent with a concrete install brief instead of figuring it out manually.", "steps": [ "Download the package from Yavira.", "Extract it into a folder your agent can access.", "Paste one of the prompts below and point your agent at the extracted folder." ], "prompts": [ { "label": "New install", "body": "I downloaded a skill package from Yavira. Read SKILL.md from the extracted folder and install it by following the included instructions. Then review README.md for any prerequisites, environment setup, or post-install checks. Tell me what you changed and call out any manual steps you could not complete." }, { "label": "Upgrade existing", "body": "I downloaded an updated skill package from Yavira. Read SKILL.md from the extracted folder, compare it with my current installation, and upgrade it while preserving any custom configuration unless the package docs explicitly say otherwise. Then review README.md for any prerequisites, environment setup, or post-install checks. Summarize what changed and any follow-up checks I should run." } ] }, "sourceHealth": { "source": "tencent", "status": "healthy", "reason": "direct_download_ok", "recommendedAction": "download", "checkedAt": "2026-05-07T17:22:31.273Z", "expiresAt": "2026-05-14T17:22:31.273Z", "httpStatus": 200, "finalUrl": "https://wry-manatee-359.convex.site/api/v1/download?slug=afrexai-annual-report", "contentType": "application/zip", "probeMethod": "head", "details": { "probeUrl": "https://wry-manatee-359.convex.site/api/v1/download?slug=afrexai-annual-report", "contentDisposition": "attachment; filename=\"afrexai-annual-report-1.0.0.zip\"", "redirectLocation": null, "bodySnippet": null }, "scope": "source", "summary": "Source download looks usable.", "detail": "Yavira can redirect you to the upstream package for this source.", "primaryActionLabel": "Download for OpenClaw", "primaryActionHref": "/downloads/afrexai-qa-engine" }, "validation": { "installChecklist": [ "Use the Yavira download entry.", "Review SKILL.md after the package is downloaded.", "Confirm the extracted package contains the expected setup assets." ], "postInstallChecks": [ "Confirm the extracted package includes the expected docs or setup files.", "Validate the skill or prompts are available in your target agent workspace.", "Capture any manual follow-up steps the agent could not complete." ] }, "downloadPageUrl": "https://openagent3.xyz/downloads/afrexai-qa-engine", "agentPageUrl": "https://openagent3.xyz/skills/afrexai-qa-engine/agent", "manifestUrl": "https://openagent3.xyz/skills/afrexai-qa-engine/agent.json", "briefUrl": "https://openagent3.xyz/skills/afrexai-qa-engine/agent.md" }, "agentAssist": { "summary": "Hand the extracted package to your coding agent with a concrete install brief instead of figuring it out manually.", "steps": [ "Download the package from Yavira.", "Extract it into a folder your agent can access.", "Paste one of the prompts below and point your agent at the extracted folder." ], "prompts": [ { "label": "New install", "body": "I downloaded a skill package from Yavira. Read SKILL.md from the extracted folder and install it by following the included instructions. Then review README.md for any prerequisites, environment setup, or post-install checks. Tell me what you changed and call out any manual steps you could not complete." }, { "label": "Upgrade existing", "body": "I downloaded an updated skill package from Yavira. Read SKILL.md from the extracted folder, compare it with my current installation, and upgrade it while preserving any custom configuration unless the package docs explicitly say otherwise. Then review README.md for any prerequisites, environment setup, or post-install checks. Summarize what changed and any follow-up checks I should run." } ] }, "documentation": { "source": "clawhub", "primaryDoc": "SKILL.md", "sections": [ { "title": "QA & Test Engineering Command Center", "body": "Complete quality assurance system — from test strategy to automation frameworks, coverage analysis, and release readiness. Works for any stack, any team size." }, { "title": "When to Use", "body": "Planning test strategy for a new feature or project\nWriting unit, integration, or E2E tests\nReviewing test quality and coverage gaps\nSetting up test automation and CI/CD quality gates\nPerformance testing and load analysis\nSecurity testing checklist\nBug triage and defect management\nRelease readiness assessment" }, { "title": "Strategy Brief", "body": "Before writing any tests, define the strategy:\n\n# test-strategy.yaml\nproject: \"[name]\"\nscope: \"[feature/module/full product]\"\nrisk_level: high | medium | low\nstack:\n language: \"[TypeScript/Python/Java/Go]\"\n framework: \"[React/Express/Django/Spring]\"\n test_runner: \"[Jest/Vitest/pytest/JUnit/Go test]\"\n e2e_tool: \"[Playwright/Cypress/Selenium]\"\n\n# What are we testing?\ntest_scope:\n - area: \"[e.g., Auth module]\"\n risk: high\n test_types: [unit, integration, e2e]\n priority: 1\n - area: \"[e.g., Settings page]\"\n risk: low\n test_types: [unit]\n priority: 3\n\n# What's NOT in scope (and why)\nexclusions:\n - \"[e.g., Third-party widget — covered by vendor]\"\n\n# Quality targets\ntargets:\n line_coverage: 80\n branch_coverage: 70\n critical_path_coverage: 100\n max_flaky_rate: 2%\n max_test_duration_unit: 10ms\n max_test_duration_integration: 500ms\n max_test_duration_e2e: 30s" }, { "title": "Risk-Based Test Allocation", "body": "Not everything needs the same testing depth. Use the risk matrix:\n\nRisk LevelUnit TestsIntegrationE2EManual/ExploratoryCritical (payments, auth, data loss)95%+ coverageFull API coverageHappy + error pathsExploratory sessionHigh (core features, user-facing)85%+ coverageKey integrationsHappy pathSpot checkMedium (secondary features)70%+ coverageCritical paths onlySmoke onlyOn releaseLow (admin, internal tools)50%+ coverageNoneNoneNone" }, { "title": "Test Pyramid", "body": "Follow the pyramid — not the ice cream cone:\n\n/ E2E \\ ← Few (5-10%) — slow, expensive, brittle\n / Integr. \\ ← Some (15-25%) — API contracts, DB queries\n / Unit \\ ← Many (65-80%) — fast, isolated, cheap\n\nAnti-pattern: Ice cream cone (mostly E2E, few unit tests) = slow CI, flaky builds, expensive maintenance.\n\nDecision rule: Can this be tested at a lower level? → Test it there." }, { "title": "Anatomy of a Good Unit Test", "body": "Every unit test follows AAA (Arrange-Act-Assert):\n\n1. ARRANGE — Set up test data, mocks, state\n2. ACT — Call the function/method under test\n3. ASSERT — Verify the output matches expectations" }, { "title": "Unit Test Checklist (per function)", "body": "For each function/method, verify:\n\nHappy path — expected input → expected output\n Edge cases — empty input, null/undefined, zero, max values\n Boundary values — off-by-one, min-1, max+1\n Error handling — invalid input → correct error thrown\n Return types — correct type, shape, structure\n Side effects — does it modify state it shouldn't?\n Idempotency — calling twice gives same result?" }, { "title": "What to Mock (and What NOT to Mock)", "body": "Mock these:\n\nExternal APIs (HTTP calls, third-party services)\nDatabase queries (in unit tests only)\nFile system operations\nDate/time (use fake timers)\nRandom number generators\nEnvironment variables\n\nDO NOT mock these:\n\nThe function under test itself\nPure utility functions (test them directly)\nData transformations\nSimple value objects\n\nMock rule of thumb: If removing the mock would make the test hit the network, file system, or database → mock it. Otherwise → don't." }, { "title": "Test Naming Convention", "body": "Use the pattern: [unit] [scenario] [expected result]\n\nExamples:\n\ncalculateTotal returns 0 for empty cart\nvalidateEmail throws for missing @ symbol\nparseDate handles ISO 8601 with timezone offset" }, { "title": "Coverage Analysis", "body": "Metrics that matter:\n\nMetricTargetWhyLine coverage80%+Basic completenessBranch coverage70%+Catches missed if/else pathsFunction coverage90%+Ensures all functions are testedCritical path coverage100%Business-critical code fully verified\n\nCoverage traps to avoid:\n\n100% line coverage ≠ good tests (assertions matter more than lines hit)\nCoverage on generated code inflates numbers\nTrivial getters/setters pad coverage without value\nCoverage should INCREASE over time, never decrease" }, { "title": "What Integration Tests Cover", "body": "Integration tests verify that components work TOGETHER:\n\nAPI endpoint → middleware → handler → database → response\nService A calls Service B and handles the response\nMessage queue producer → consumer → side effect\nAuth flow: login → token → authenticated request" }, { "title": "Integration Test Patterns", "body": "Pattern 1: API Contract Testing\n\n1. Start test server (or use supertest/httptest)\n2. Send HTTP request with specific payload\n3. Assert: status code, response body shape, headers\n4. Assert: database state changed correctly\n5. Assert: side effects triggered (emails, events)\n\nPattern 2: Database Integration\n\n1. Start test database (SQLite in-memory or test container)\n2. Run migrations\n3. Seed test data\n4. Execute query/operation\n5. Assert: data matches expectations\n6. Teardown (truncate or rollback transaction)\n\nPattern 3: External Service\n\n1. Record real API response (VCR/nock/wiremock)\n2. Replay recorded response in tests\n3. Assert: your code handles the response correctly\n4. Also test: timeout, 500 error, malformed response" }, { "title": "Integration Test Checklist", "body": "Happy path — full flow works end-to-end\n Auth — unauthenticated returns 401, wrong role returns 403\n Validation — bad payload returns 400 with error details\n Not found — missing resource returns 404\n Conflict — duplicate create returns 409\n Rate limiting — excessive requests return 429\n Database constraints — unique violations, foreign keys\n Concurrency — two simultaneous writes don't corrupt data\n Timeout handling — external service timeout → graceful fallback" }, { "title": "E2E Strategy", "body": "E2E tests verify complete user journeys. They're expensive — be strategic:\n\nTest these E2E:\n\nUser registration → email verification → first login\nPurchase flow → payment → confirmation\nCritical business workflows (the ones that make money)\nCross-browser/device smoke tests\n\nDON'T test these E2E:\n\nIndividual form validations (unit test)\nAPI error handling (integration test)\nEdge cases (lower-level tests)\nVisual styling (visual regression tools)" }, { "title": "E2E Test Template", "body": "test_name: \"[User journey name]\"\npreconditions:\n - \"[User is logged in]\"\n - \"[Product exists in catalog]\"\nsteps:\n - action: \"Navigate to /products\"\n verify: \"Product list is visible\"\n - action: \"Click 'Add to Cart' on Product A\"\n verify: \"Cart badge shows 1\"\n - action: \"Click 'Checkout'\"\n verify: \"Checkout form displayed\"\n - action: \"Fill payment details and submit\"\n verify: \"Order confirmation page with order ID\"\npostconditions:\n - \"Order exists in database with status 'paid'\"\n - \"Confirmation email sent\"\nmax_duration: 30s" }, { "title": "Flaky Test Management", "body": "Flaky tests are the #1 CI killer. Handle them:\n\nFlaky Test Triage:\n\nIdentify — Track test pass rates over 10+ runs\nClassify — Why is it flaky?\n\nTiming/race condition → Add explicit waits, not sleep()\nTest data dependency → Isolate test data per run\nExternal service → Mock it or use test container\nBrowser rendering → Use visibility checks, not delays\n\n\nQuarantine — Move to @flaky suite, run separately\nFix or delete — Flaky test unfixed for 2 weeks → delete it\n\nFlaky rate target: < 2% of total test runs" }, { "title": "Performance Test Types", "body": "TypePurposeWhenLoad testNormal traffic handlingBefore every releaseStress testFind breaking pointQuarterly or before scalingSpike testSudden traffic burstBefore marketing campaignsSoak testMemory leaks over timeMonthly or after major changesCapacity testMax users/throughputPlanning infrastructure" }, { "title": "Performance Test Plan", "body": "test_name: \"[API/Page] Load Test\"\ntarget: \"[URL or endpoint]\"\nbaseline:\n p50_response: \"[current p50 ms]\"\n p95_response: \"[current p95 ms]\"\n p99_response: \"[current p99 ms]\"\n error_rate: \"[current %]\"\n\nscenarios:\n - name: \"Normal load\"\n vus: 50 # virtual users\n duration: 5m\n ramp_up: 30s\n thresholds:\n p95_response: \"< 500ms\"\n error_rate: \"< 1%\"\n\n - name: \"Peak load\"\n vus: 200\n duration: 10m\n ramp_up: 1m\n thresholds:\n p95_response: \"< 2000ms\"\n error_rate: \"< 5%\"\n\n - name: \"Stress test\"\n vus: 500\n duration: 5m\n ramp_up: 2m\n # Find the breaking point — no thresholds, observe" }, { "title": "Performance Metrics Dashboard", "body": "Track these per endpoint:\n\nMetricGreenYellowRedp50 response< 200ms200-500ms> 500msp95 response< 500ms500ms-2s> 2sp99 response< 1s1-5s> 5sError rate< 0.1%0.1-1%> 1%Throughput> baseline80-100% baseline< 80%CPU usage< 60%60-80%> 80%Memory usage< 70%70-85%> 85%DB query time< 50ms avg50-200ms> 200ms" }, { "title": "Common Performance Fixes", "body": "SymptomLikely CauseFixSlow API responseN+1 queriesBatch/join queriesMemory climbingObject retentionProfile heap, fix leaksTimeout spikesConnection pool exhaustionIncrease pool, add queuingSlow page loadLarge bundleCode split, lazy loadDB bottleneckMissing indexAdd index on WHERE/JOIN columnsHigh CPUSynchronous computeMove to worker/queue" }, { "title": "Security Test Checklist", "body": "Run through these for every feature/release:\n\nAuthentication & Authorization:\n\nPasswords hashed with bcrypt/argon2 (not MD5/SHA1)\n Session tokens are random, sufficient length (128+ bits)\n JWT tokens have short expiry (15 min access, 7 day refresh)\n Failed login rate limiting (5 attempts → lockout)\n Password reset tokens expire (1 hour max)\n Role-based access enforced server-side (not just UI)\n Can't access other users' data by changing IDs in URL\n\nInput Validation:\n\nSQL injection — parameterized queries everywhere\n XSS — output encoding, CSP headers\n CSRF — tokens on state-changing requests\n Path traversal — validate file paths, no ../\n Command injection — never pass user input to shell\n File upload — validate type, size, scan for malware\n JSON/XML parsing — depth limits, entity expansion disabled\n\nData Protection:\n\nHTTPS everywhere (HSTS header)\n Sensitive data encrypted at rest\n PII not logged (mask in log output)\n API keys not in client-side code\n CORS configured correctly (not *)\n Security headers set (X-Frame-Options, X-Content-Type-Options)\n\nInfrastructure:\n\nDependencies scanned for CVEs (npm audit / pip audit)\n Docker images scanned (Trivy/Snyk)\n Secrets not in code/env files (use vault)\n Error messages don't leak internals\n Admin endpoints behind VPN/IP allowlist" }, { "title": "OWASP Top 10 Quick Reference", "body": "#VulnerabilityTest ForA01Broken Access ControlAccess other users' resources, bypass role checksA02Cryptographic FailuresWeak hashing, plaintext secrets, expired certsA03InjectionSQL, XSS, command, LDAP injectionA04Insecure DesignBusiness logic flaws, missing rate limitsA05Security MisconfigurationDefault creds, verbose errors, open portsA06Vulnerable ComponentsOutdated deps with known CVEsA07Authentication FailuresBrute force, weak passwords, session fixationA08Data Integrity FailuresUnsigned updates, CI/CD pipeline injectionA09Logging FailuresMissing audit logs, no alerting on breachesA10SSRFInternal network access via user-controlled URLs" }, { "title": "Bug Report Template", "body": "bug_id: \"[auto or manual]\"\ntitle: \"[Short description of the bug]\"\nseverity: P0-critical | P1-high | P2-medium | P3-low\nreporter: \"[name]\"\ndate: \"[YYYY-MM-DD]\"\n\nenvironment:\n os: \"[OS + version]\"\n browser: \"[Browser + version]\"\n app_version: \"[version/commit]\"\n \nsteps_to_reproduce:\n 1. \"[Step 1]\"\n 2. \"[Step 2]\"\n 3. \"[Step 3]\"\n\nexpected_result: \"[What should happen]\"\nactual_result: \"[What actually happens]\"\nfrequency: \"always | intermittent | once\"\nscreenshots: \"[links]\"\nlogs: \"[relevant log output]\"" }, { "title": "Severity Classification", "body": "LevelDefinitionSLAExampleP0 CriticalSystem down, data loss, security breachFix in 4 hoursPayment processing brokenP1 HighMajor feature broken, no workaroundFix in 24 hoursUsers can't loginP2 MediumFeature broken with workaroundFix this sprintSearch returns wrong results sometimesP3 LowMinor issue, cosmeticFix when convenientButton alignment off by 2px" }, { "title": "Bug Triage Process (Weekly)", "body": "1. Review all new bugs (unassigned)\n2. For each bug:\n a. Reproduce — can you trigger it?\n b. Classify severity (P0-P3)\n c. Estimate fix effort (S/M/L)\n d. Assign to owner + sprint\n e. Link to related bugs/stories\n3. Review P0/P1 bugs from last week — are they fixed?\n4. Close bugs that can't be reproduced (after 2 attempts)\n5. Update metrics dashboard" }, { "title": "Bug Metrics Dashboard", "body": "Track weekly:\n\nMetricFormulaTargetBug escape rateBugs found in prod / total bugs< 10%Mean time to fix (P0)Avg hours from report to deploy< 8 hoursMean time to fix (P1)Avg hours from report to deploy< 48 hoursBug reopen rateReopened bugs / closed bugs< 5%Test escape analysisBugs that SHOULD have been caughtTrack & reduceOpen bug countTotal open by severityTrending down" }, { "title": "Release Checklist", "body": "Before shipping to production:\n\nCode Quality:\n\nAll unit tests passing\n All integration tests passing\n E2E smoke suite passing\n No new lint warnings/errors\n Code reviewed and approved\n No known P0/P1 bugs open for this release\n\nCoverage & Quality Gates:\n\nLine coverage ≥ target (80%)\n Branch coverage ≥ target (70%)\n No coverage decrease from last release\n Mutation testing score ≥ 60% (if applicable)\n\nPerformance:\n\nLoad test passed (within thresholds)\n No performance regressions vs baseline\n Bundle size within budget\n\nSecurity:\n\nDependency audit clean (no critical/high CVEs)\n Security checklist completed\n Secrets rotated if needed\n\nOperational Readiness:\n\nMonitoring/alerts configured for new features\n Rollback plan documented\n Feature flags in place for risky changes\n Database migration tested and reversible\n Runbook updated" }, { "title": "Release Readiness Score", "body": "Score 0-100 across 5 dimensions:\n\nDimensionWeightScoringTest coverage25%100 if targets met, -10 per gap areaBug status25%100 if 0 P0/P1, -20 per open P0, -10 per P1Performance20%100 if all green, -15 per yellow, -30 per redSecurity20%100 if clean, -25 per critical, -15 per highOperational10%100 if checklist complete, -20 per missing item\n\nShip threshold: ≥ 80 overall, no dimension below 60" }, { "title": "Pipeline Quality Gates", "body": "Configure these gates in your CI pipeline:\n\n# Quality gate configuration\ngates:\n - name: \"Lint\"\n stage: pre-commit\n command: \"npm run lint\"\n blocking: true\n \n - name: \"Unit Tests\"\n stage: commit\n command: \"npm test -- --coverage\"\n blocking: true\n thresholds:\n pass_rate: 100%\n coverage_line: 80%\n coverage_branch: 70%\n \n - name: \"Integration Tests\"\n stage: merge\n command: \"npm run test:integration\"\n blocking: true\n thresholds:\n pass_rate: 100%\n \n - name: \"Security Scan\"\n stage: merge\n command: \"npm audit --audit-level=high\"\n blocking: true\n \n - name: \"E2E Smoke\"\n stage: staging\n command: \"npm run test:e2e:smoke\"\n blocking: true\n thresholds:\n pass_rate: 100%\n \n - name: \"Performance\"\n stage: staging\n command: \"npm run test:perf\"\n blocking: false # Alert only\n thresholds:\n p95_regression: 20%" }, { "title": "Test Automation Maturity Model", "body": "Rate your team 1-5:\n\nLevelDescriptionCharacteristics1 — ManualAll testing is manualNo automation, long release cycles2 — ReactiveSome unit tests, no CITests written after bugs, not before3 — StructuredTest pyramid, CI pipelineUnit + integration, automated on push4 — ProactiveFull automation, quality gatesE2E + perf + security in pipeline, TDD5 — OptimizedSelf-healing, predictiveFlaky auto-quarantine, AI-assisted testing, continuous deployment" }, { "title": "Weekly Test Health Review", "body": "review_date: \"[YYYY-MM-DD]\"\n\nmetrics:\n total_tests: 0\n pass_rate_7d: \"0%\"\n flaky_tests: 0\n flaky_rate: \"0%\"\n avg_suite_duration: \"0s\"\n coverage_line: \"0%\"\n coverage_branch: \"0%\"\n \nactions:\n quarantined: [] # Tests moved to flaky suite\n deleted: [] # Tests removed (obsolete/unfixable)\n fixed: [] # Flaky tests fixed this week\n added: [] # New tests added\n \ntrends:\n coverage_delta: \"+0%\" # vs last week\n flaky_delta: \"+0\" # vs last week\n duration_delta: \"+0s\" # vs last week\n \nnotes: \"\"" }, { "title": "Test Maintenance Rules", "body": "No commented-out tests — delete or fix, never comment\nNo skipped tests > 2 weeks — fix or remove\nNo test duplication — each behavior tested once at the right level\nTest names must be readable — someone new should understand what broke\nShared test utilities — common setup in fixtures/factories, not copy-pasted\nTest data isolation — each test creates its own data, cleans up after\nNo magic numbers — use named constants in assertions\nAssertion messages — custom messages on complex assertions" }, { "title": "Common Test Anti-Patterns", "body": "Anti-PatternProblemFixSleeping testssleep(2000) instead of waitingUse explicit waits/pollingTest interdependenceTest B relies on Test A's stateIsolate — each test sets up its own stateAssertionless testsTest runs code but doesn't assertAdd meaningful assertionsBrittle selectorsCSS selectors that break on redesignUse data-testid or aria rolesGod testOne test verifying 20 thingsSplit into focused testsMock overloadEverything mocked, nothing real testedOnly mock external boundariesHardcoded dataTests break when seed data changesUse factories/buildersIgnoring test output\"It passed, ship it\"Review WHY it passed — is the assertion meaningful?" }, { "title": "Quick Reference: Natural Language Commands", "body": "Tell the agent:\n\n\"Create test strategy for [feature]\" → Generates strategy brief\n\"Write unit tests for [function/file]\" → AAA-structured tests with edge cases\n\"Review test coverage for [module]\" → Gap analysis + recommendations\n\"Write integration tests for [API endpoint]\" → Full HTTP test suite\n\"Plan E2E tests for [user journey]\" → E2E test template\n\"Run security checklist for [feature]\" → OWASP-based security review\n\"Triage these bugs: [list]\" → Severity classification + assignment\n\"Release readiness check\" → Full readiness score + blockers\n\"Performance test plan for [endpoint]\" → Load/stress test configuration\n\"Fix flaky test [name]\" → Root cause analysis + fix strategy" } ], "body": "QA & Test Engineering Command Center\n\nComplete quality assurance system — from test strategy to automation frameworks, coverage analysis, and release readiness. Works for any stack, any team size.\n\nWhen to Use\nPlanning test strategy for a new feature or project\nWriting unit, integration, or E2E tests\nReviewing test quality and coverage gaps\nSetting up test automation and CI/CD quality gates\nPerformance testing and load analysis\nSecurity testing checklist\nBug triage and defect management\nRelease readiness assessment\nPhase 1: Test Strategy\nStrategy Brief\n\nBefore writing any tests, define the strategy:\n\n# test-strategy.yaml\nproject: \"[name]\"\nscope: \"[feature/module/full product]\"\nrisk_level: high | medium | low\nstack:\n language: \"[TypeScript/Python/Java/Go]\"\n framework: \"[React/Express/Django/Spring]\"\n test_runner: \"[Jest/Vitest/pytest/JUnit/Go test]\"\n e2e_tool: \"[Playwright/Cypress/Selenium]\"\n\n# What are we testing?\ntest_scope:\n - area: \"[e.g., Auth module]\"\n risk: high\n test_types: [unit, integration, e2e]\n priority: 1\n - area: \"[e.g., Settings page]\"\n risk: low\n test_types: [unit]\n priority: 3\n\n# What's NOT in scope (and why)\nexclusions:\n - \"[e.g., Third-party widget — covered by vendor]\"\n\n# Quality targets\ntargets:\n line_coverage: 80\n branch_coverage: 70\n critical_path_coverage: 100\n max_flaky_rate: 2%\n max_test_duration_unit: 10ms\n max_test_duration_integration: 500ms\n max_test_duration_e2e: 30s\n\nRisk-Based Test Allocation\n\nNot everything needs the same testing depth. Use the risk matrix:\n\nRisk Level\tUnit Tests\tIntegration\tE2E\tManual/Exploratory\nCritical (payments, auth, data loss)\t95%+ coverage\tFull API coverage\tHappy + error paths\tExploratory session\nHigh (core features, user-facing)\t85%+ coverage\tKey integrations\tHappy path\tSpot check\nMedium (secondary features)\t70%+ coverage\tCritical paths only\tSmoke only\tOn release\nLow (admin, internal tools)\t50%+ coverage\tNone\tNone\tNone\nTest Pyramid\n\nFollow the pyramid — not the ice cream cone:\n\n / E2E \\ ← Few (5-10%) — slow, expensive, brittle\n / Integr. \\ ← Some (15-25%) — API contracts, DB queries\n / Unit \\ ← Many (65-80%) — fast, isolated, cheap\n\n\nAnti-pattern: Ice cream cone (mostly E2E, few unit tests) = slow CI, flaky builds, expensive maintenance.\n\nDecision rule: Can this be tested at a lower level? → Test it there.\n\nPhase 2: Unit Testing\nAnatomy of a Good Unit Test\n\nEvery unit test follows AAA (Arrange-Act-Assert):\n\n1. ARRANGE — Set up test data, mocks, state\n2. ACT — Call the function/method under test\n3. ASSERT — Verify the output matches expectations\n\nUnit Test Checklist (per function)\n\nFor each function/method, verify:\n\n Happy path — expected input → expected output\n Edge cases — empty input, null/undefined, zero, max values\n Boundary values — off-by-one, min-1, max+1\n Error handling — invalid input → correct error thrown\n Return types — correct type, shape, structure\n Side effects — does it modify state it shouldn't?\n Idempotency — calling twice gives same result?\nWhat to Mock (and What NOT to Mock)\n\nMock these:\n\nExternal APIs (HTTP calls, third-party services)\nDatabase queries (in unit tests only)\nFile system operations\nDate/time (use fake timers)\nRandom number generators\nEnvironment variables\n\nDO NOT mock these:\n\nThe function under test itself\nPure utility functions (test them directly)\nData transformations\nSimple value objects\n\nMock rule of thumb: If removing the mock would make the test hit the network, file system, or database → mock it. Otherwise → don't.\n\nTest Naming Convention\n\nUse the pattern: [unit] [scenario] [expected result]\n\nExamples:\n\ncalculateTotal returns 0 for empty cart\nvalidateEmail throws for missing @ symbol\nparseDate handles ISO 8601 with timezone offset\nCoverage Analysis\n\nMetrics that matter:\n\nMetric\tTarget\tWhy\nLine coverage\t80%+\tBasic completeness\nBranch coverage\t70%+\tCatches missed if/else paths\nFunction coverage\t90%+\tEnsures all functions are tested\nCritical path coverage\t100%\tBusiness-critical code fully verified\n\nCoverage traps to avoid:\n\n100% line coverage ≠ good tests (assertions matter more than lines hit)\nCoverage on generated code inflates numbers\nTrivial getters/setters pad coverage without value\nCoverage should INCREASE over time, never decrease\nPhase 3: Integration Testing\nWhat Integration Tests Cover\n\nIntegration tests verify that components work TOGETHER:\n\nAPI endpoint → middleware → handler → database → response\nService A calls Service B and handles the response\nMessage queue producer → consumer → side effect\nAuth flow: login → token → authenticated request\nIntegration Test Patterns\n\nPattern 1: API Contract Testing\n\n1. Start test server (or use supertest/httptest)\n2. Send HTTP request with specific payload\n3. Assert: status code, response body shape, headers\n4. Assert: database state changed correctly\n5. Assert: side effects triggered (emails, events)\n\n\nPattern 2: Database Integration\n\n1. Start test database (SQLite in-memory or test container)\n2. Run migrations\n3. Seed test data\n4. Execute query/operation\n5. Assert: data matches expectations\n6. Teardown (truncate or rollback transaction)\n\n\nPattern 3: External Service\n\n1. Record real API response (VCR/nock/wiremock)\n2. Replay recorded response in tests\n3. Assert: your code handles the response correctly\n4. Also test: timeout, 500 error, malformed response\n\nIntegration Test Checklist\n Happy path — full flow works end-to-end\n Auth — unauthenticated returns 401, wrong role returns 403\n Validation — bad payload returns 400 with error details\n Not found — missing resource returns 404\n Conflict — duplicate create returns 409\n Rate limiting — excessive requests return 429\n Database constraints — unique violations, foreign keys\n Concurrency — two simultaneous writes don't corrupt data\n Timeout handling — external service timeout → graceful fallback\nPhase 4: End-to-End (E2E) Testing\nE2E Strategy\n\nE2E tests verify complete user journeys. They're expensive — be strategic:\n\nTest these E2E:\n\nUser registration → email verification → first login\nPurchase flow → payment → confirmation\nCritical business workflows (the ones that make money)\nCross-browser/device smoke tests\n\nDON'T test these E2E:\n\nIndividual form validations (unit test)\nAPI error handling (integration test)\nEdge cases (lower-level tests)\nVisual styling (visual regression tools)\nE2E Test Template\ntest_name: \"[User journey name]\"\npreconditions:\n - \"[User is logged in]\"\n - \"[Product exists in catalog]\"\nsteps:\n - action: \"Navigate to /products\"\n verify: \"Product list is visible\"\n - action: \"Click 'Add to Cart' on Product A\"\n verify: \"Cart badge shows 1\"\n - action: \"Click 'Checkout'\"\n verify: \"Checkout form displayed\"\n - action: \"Fill payment details and submit\"\n verify: \"Order confirmation page with order ID\"\npostconditions:\n - \"Order exists in database with status 'paid'\"\n - \"Confirmation email sent\"\nmax_duration: 30s\n\nFlaky Test Management\n\nFlaky tests are the #1 CI killer. Handle them:\n\nFlaky Test Triage:\n\nIdentify — Track test pass rates over 10+ runs\nClassify — Why is it flaky?\nTiming/race condition → Add explicit waits, not sleep()\nTest data dependency → Isolate test data per run\nExternal service → Mock it or use test container\nBrowser rendering → Use visibility checks, not delays\nQuarantine — Move to @flaky suite, run separately\nFix or delete — Flaky test unfixed for 2 weeks → delete it\n\nFlaky rate target: < 2% of total test runs\n\nPhase 5: Performance Testing\nPerformance Test Types\nType\tPurpose\tWhen\nLoad test\tNormal traffic handling\tBefore every release\nStress test\tFind breaking point\tQuarterly or before scaling\nSpike test\tSudden traffic burst\tBefore marketing campaigns\nSoak test\tMemory leaks over time\tMonthly or after major changes\nCapacity test\tMax users/throughput\tPlanning infrastructure\nPerformance Test Plan\ntest_name: \"[API/Page] Load Test\"\ntarget: \"[URL or endpoint]\"\nbaseline:\n p50_response: \"[current p50 ms]\"\n p95_response: \"[current p95 ms]\"\n p99_response: \"[current p99 ms]\"\n error_rate: \"[current %]\"\n\nscenarios:\n - name: \"Normal load\"\n vus: 50 # virtual users\n duration: 5m\n ramp_up: 30s\n thresholds:\n p95_response: \"< 500ms\"\n error_rate: \"< 1%\"\n\n - name: \"Peak load\"\n vus: 200\n duration: 10m\n ramp_up: 1m\n thresholds:\n p95_response: \"< 2000ms\"\n error_rate: \"< 5%\"\n\n - name: \"Stress test\"\n vus: 500\n duration: 5m\n ramp_up: 2m\n # Find the breaking point — no thresholds, observe\n\nPerformance Metrics Dashboard\n\nTrack these per endpoint:\n\nMetric\tGreen\tYellow\tRed\np50 response\t< 200ms\t200-500ms\t> 500ms\np95 response\t< 500ms\t500ms-2s\t> 2s\np99 response\t< 1s\t1-5s\t> 5s\nError rate\t< 0.1%\t0.1-1%\t> 1%\nThroughput\t> baseline\t80-100% baseline\t< 80%\nCPU usage\t< 60%\t60-80%\t> 80%\nMemory usage\t< 70%\t70-85%\t> 85%\nDB query time\t< 50ms avg\t50-200ms\t> 200ms\nCommon Performance Fixes\nSymptom\tLikely Cause\tFix\nSlow API response\tN+1 queries\tBatch/join queries\nMemory climbing\tObject retention\tProfile heap, fix leaks\nTimeout spikes\tConnection pool exhaustion\tIncrease pool, add queuing\nSlow page load\tLarge bundle\tCode split, lazy load\nDB bottleneck\tMissing index\tAdd index on WHERE/JOIN columns\nHigh CPU\tSynchronous compute\tMove to worker/queue\nPhase 6: Security Testing\nSecurity Test Checklist\n\nRun through these for every feature/release:\n\nAuthentication & Authorization:\n\n Passwords hashed with bcrypt/argon2 (not MD5/SHA1)\n Session tokens are random, sufficient length (128+ bits)\n JWT tokens have short expiry (15 min access, 7 day refresh)\n Failed login rate limiting (5 attempts → lockout)\n Password reset tokens expire (1 hour max)\n Role-based access enforced server-side (not just UI)\n Can't access other users' data by changing IDs in URL\n\nInput Validation:\n\n SQL injection — parameterized queries everywhere\n XSS — output encoding, CSP headers\n CSRF — tokens on state-changing requests\n Path traversal — validate file paths, no ../\n Command injection — never pass user input to shell\n File upload — validate type, size, scan for malware\n JSON/XML parsing — depth limits, entity expansion disabled\n\nData Protection:\n\n HTTPS everywhere (HSTS header)\n Sensitive data encrypted at rest\n PII not logged (mask in log output)\n API keys not in client-side code\n CORS configured correctly (not *)\n Security headers set (X-Frame-Options, X-Content-Type-Options)\n\nInfrastructure:\n\n Dependencies scanned for CVEs (npm audit / pip audit)\n Docker images scanned (Trivy/Snyk)\n Secrets not in code/env files (use vault)\n Error messages don't leak internals\n Admin endpoints behind VPN/IP allowlist\nOWASP Top 10 Quick Reference\n#\tVulnerability\tTest For\nA01\tBroken Access Control\tAccess other users' resources, bypass role checks\nA02\tCryptographic Failures\tWeak hashing, plaintext secrets, expired certs\nA03\tInjection\tSQL, XSS, command, LDAP injection\nA04\tInsecure Design\tBusiness logic flaws, missing rate limits\nA05\tSecurity Misconfiguration\tDefault creds, verbose errors, open ports\nA06\tVulnerable Components\tOutdated deps with known CVEs\nA07\tAuthentication Failures\tBrute force, weak passwords, session fixation\nA08\tData Integrity Failures\tUnsigned updates, CI/CD pipeline injection\nA09\tLogging Failures\tMissing audit logs, no alerting on breaches\nA10\tSSRF\tInternal network access via user-controlled URLs\nPhase 7: Bug Triage & Defect Management\nBug Report Template\nbug_id: \"[auto or manual]\"\ntitle: \"[Short description of the bug]\"\nseverity: P0-critical | P1-high | P2-medium | P3-low\nreporter: \"[name]\"\ndate: \"[YYYY-MM-DD]\"\n\nenvironment:\n os: \"[OS + version]\"\n browser: \"[Browser + version]\"\n app_version: \"[version/commit]\"\n \nsteps_to_reproduce:\n 1. \"[Step 1]\"\n 2. \"[Step 2]\"\n 3. \"[Step 3]\"\n\nexpected_result: \"[What should happen]\"\nactual_result: \"[What actually happens]\"\nfrequency: \"always | intermittent | once\"\nscreenshots: \"[links]\"\nlogs: \"[relevant log output]\"\n\nSeverity Classification\nLevel\tDefinition\tSLA\tExample\nP0 Critical\tSystem down, data loss, security breach\tFix in 4 hours\tPayment processing broken\nP1 High\tMajor feature broken, no workaround\tFix in 24 hours\tUsers can't login\nP2 Medium\tFeature broken with workaround\tFix this sprint\tSearch returns wrong results sometimes\nP3 Low\tMinor issue, cosmetic\tFix when convenient\tButton alignment off by 2px\nBug Triage Process (Weekly)\n1. Review all new bugs (unassigned)\n2. For each bug:\n a. Reproduce — can you trigger it?\n b. Classify severity (P0-P3)\n c. Estimate fix effort (S/M/L)\n d. Assign to owner + sprint\n e. Link to related bugs/stories\n3. Review P0/P1 bugs from last week — are they fixed?\n4. Close bugs that can't be reproduced (after 2 attempts)\n5. Update metrics dashboard\n\nBug Metrics Dashboard\n\nTrack weekly:\n\nMetric\tFormula\tTarget\nBug escape rate\tBugs found in prod / total bugs\t< 10%\nMean time to fix (P0)\tAvg hours from report to deploy\t< 8 hours\nMean time to fix (P1)\tAvg hours from report to deploy\t< 48 hours\nBug reopen rate\tReopened bugs / closed bugs\t< 5%\nTest escape analysis\tBugs that SHOULD have been caught\tTrack & reduce\nOpen bug count\tTotal open by severity\tTrending down\nPhase 8: Release Readiness\nRelease Checklist\n\nBefore shipping to production:\n\nCode Quality:\n\n All unit tests passing\n All integration tests passing\n E2E smoke suite passing\n No new lint warnings/errors\n Code reviewed and approved\n No known P0/P1 bugs open for this release\n\nCoverage & Quality Gates:\n\n Line coverage ≥ target (80%)\n Branch coverage ≥ target (70%)\n No coverage decrease from last release\n Mutation testing score ≥ 60% (if applicable)\n\nPerformance:\n\n Load test passed (within thresholds)\n No performance regressions vs baseline\n Bundle size within budget\n\nSecurity:\n\n Dependency audit clean (no critical/high CVEs)\n Security checklist completed\n Secrets rotated if needed\n\nOperational Readiness:\n\n Monitoring/alerts configured for new features\n Rollback plan documented\n Feature flags in place for risky changes\n Database migration tested and reversible\n Runbook updated\nRelease Readiness Score\n\nScore 0-100 across 5 dimensions:\n\nDimension\tWeight\tScoring\nTest coverage\t25%\t100 if targets met, -10 per gap area\nBug status\t25%\t100 if 0 P0/P1, -20 per open P0, -10 per P1\nPerformance\t20%\t100 if all green, -15 per yellow, -30 per red\nSecurity\t20%\t100 if clean, -25 per critical, -15 per high\nOperational\t10%\t100 if checklist complete, -20 per missing item\n\nShip threshold: ≥ 80 overall, no dimension below 60\n\nPhase 9: CI/CD Quality Gates\nPipeline Quality Gates\n\nConfigure these gates in your CI pipeline:\n\n# Quality gate configuration\ngates:\n - name: \"Lint\"\n stage: pre-commit\n command: \"npm run lint\"\n blocking: true\n \n - name: \"Unit Tests\"\n stage: commit\n command: \"npm test -- --coverage\"\n blocking: true\n thresholds:\n pass_rate: 100%\n coverage_line: 80%\n coverage_branch: 70%\n \n - name: \"Integration Tests\"\n stage: merge\n command: \"npm run test:integration\"\n blocking: true\n thresholds:\n pass_rate: 100%\n \n - name: \"Security Scan\"\n stage: merge\n command: \"npm audit --audit-level=high\"\n blocking: true\n \n - name: \"E2E Smoke\"\n stage: staging\n command: \"npm run test:e2e:smoke\"\n blocking: true\n thresholds:\n pass_rate: 100%\n \n - name: \"Performance\"\n stage: staging\n command: \"npm run test:perf\"\n blocking: false # Alert only\n thresholds:\n p95_regression: 20%\n\nTest Automation Maturity Model\n\nRate your team 1-5:\n\nLevel\tDescription\tCharacteristics\n1 — Manual\tAll testing is manual\tNo automation, long release cycles\n2 — Reactive\tSome unit tests, no CI\tTests written after bugs, not before\n3 — Structured\tTest pyramid, CI pipeline\tUnit + integration, automated on push\n4 — Proactive\tFull automation, quality gates\tE2E + perf + security in pipeline, TDD\n5 — Optimized\tSelf-healing, predictive\tFlaky auto-quarantine, AI-assisted testing, continuous deployment\nPhase 10: Test Maintenance\nWeekly Test Health Review\nreview_date: \"[YYYY-MM-DD]\"\n\nmetrics:\n total_tests: 0\n pass_rate_7d: \"0%\"\n flaky_tests: 0\n flaky_rate: \"0%\"\n avg_suite_duration: \"0s\"\n coverage_line: \"0%\"\n coverage_branch: \"0%\"\n \nactions:\n quarantined: [] # Tests moved to flaky suite\n deleted: [] # Tests removed (obsolete/unfixable)\n fixed: [] # Flaky tests fixed this week\n added: [] # New tests added\n \ntrends:\n coverage_delta: \"+0%\" # vs last week\n flaky_delta: \"+0\" # vs last week\n duration_delta: \"+0s\" # vs last week\n \nnotes: \"\"\n\nTest Maintenance Rules\nNo commented-out tests — delete or fix, never comment\nNo skipped tests > 2 weeks — fix or remove\nNo test duplication — each behavior tested once at the right level\nTest names must be readable — someone new should understand what broke\nShared test utilities — common setup in fixtures/factories, not copy-pasted\nTest data isolation — each test creates its own data, cleans up after\nNo magic numbers — use named constants in assertions\nAssertion messages — custom messages on complex assertions\nCommon Test Anti-Patterns\nAnti-Pattern\tProblem\tFix\nSleeping tests\tsleep(2000) instead of waiting\tUse explicit waits/polling\nTest interdependence\tTest B relies on Test A's state\tIsolate — each test sets up its own state\nAssertionless tests\tTest runs code but doesn't assert\tAdd meaningful assertions\nBrittle selectors\tCSS selectors that break on redesign\tUse data-testid or aria roles\nGod test\tOne test verifying 20 things\tSplit into focused tests\nMock overload\tEverything mocked, nothing real tested\tOnly mock external boundaries\nHardcoded data\tTests break when seed data changes\tUse factories/builders\nIgnoring test output\t\"It passed, ship it\"\tReview WHY it passed — is the assertion meaningful?\nQuick Reference: Natural Language Commands\n\nTell the agent:\n\n\"Create test strategy for [feature]\" → Generates strategy brief\n\"Write unit tests for [function/file]\" → AAA-structured tests with edge cases\n\"Review test coverage for [module]\" → Gap analysis + recommendations\n\"Write integration tests for [API endpoint]\" → Full HTTP test suite\n\"Plan E2E tests for [user journey]\" → E2E test template\n\"Run security checklist for [feature]\" → OWASP-based security review\n\"Triage these bugs: [list]\" → Severity classification + assignment\n\"Release readiness check\" → Full readiness score + blockers\n\"Performance test plan for [endpoint]\" → Load/stress test configuration\n\"Fix flaky test [name]\" → Root cause analysis + fix strategy" }, "trust": { "sourceLabel": "tencent", "provenanceUrl": "https://clawhub.ai/1kalin/afrexai-qa-engine", "publisherUrl": "https://clawhub.ai/1kalin/afrexai-qa-engine", "owner": "1kalin", "version": "1.0.0", "license": null, "verificationStatus": "Indexed source record" }, "links": { "detailUrl": "https://openagent3.xyz/skills/afrexai-qa-engine", "downloadUrl": "https://openagent3.xyz/downloads/afrexai-qa-engine", "agentUrl": "https://openagent3.xyz/skills/afrexai-qa-engine/agent", "manifestUrl": "https://openagent3.xyz/skills/afrexai-qa-engine/agent.json", "briefUrl": "https://openagent3.xyz/skills/afrexai-qa-engine/agent.md" } }