## New Skill: qa-expert (v1.0.0) Comprehensive QA testing infrastructure with autonomous LLM execution: - One-command QA project initialization with complete templates - Google Testing Standards (AAA pattern, 90% coverage targets) - Autonomous LLM-driven test execution via master prompts (100x speedup) - OWASP Top 10 security testing (90% coverage target) - Bug tracking with P0-P4 severity classification - Quality gates enforcement (100% execution, ≥80% pass rate, 0 P0 bugs) - Ground Truth Principle for preventing doc/CSV sync issues - Day 1 onboarding guide (5-hour timeline) - 30+ ready-to-use LLM prompts for QA tasks - Bundled scripts: init_qa_project.py, calculate_metrics.py ## Documentation Updates - Updated marketplace to v1.10.0 (16 → 17 skills) - Updated CHANGELOG.md with v1.10.0 entry - Updated README.md (EN) with qa-expert skill section - Updated README.zh-CN.md (ZH) with skills 11-16 and qa-expert - Updated CLAUDE.md with qa-expert in available skills list - Updated marketplace.json with qa-expert plugin entry ## SOP Improvements Enhanced "Adding a New Skill to Marketplace" workflow: - Added mandatory Step 7: Update README.zh-CN.md - Added 6 new Chinese documentation checklist items - Added Chinese documentation to Common Mistakes (#2, #3, #4, #5, #7, #8) - Updated File Update Summary Template (7 files including zh-CN) - Added verification commands for EN/ZH sync - Made Chinese documentation updates MANDATORY Total: 17 production-ready skills 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
5.0 KiB
5.0 KiB
Google Testing Standards Reference
Comprehensive guide to Google's testing best practices and standards.
AAA Pattern (Arrange-Act-Assert)
Every test should follow this structure:
1. Arrange (Setup)
**Prerequisites**:
- System in known state
- Test data prepared
- Dependencies mocked/configured
2. Act (Execute)
**Test Steps**:
1. Perform action
2. Trigger behavior
3. Execute operation
3. Assert (Verify)
**Expected Result**:
✅ Verification criteria
✅ Observable outcomes
✅ System state validation
Test Case Design Principles
1. Test Case ID Convention
TC-[CATEGORY]-[NUMBER]
Examples:
- TC-CLI-001 (CLI tests)
- TC-WEB-042 (Web tests)
- TC-API-103 (API tests)
- TC-SEC-007 (Security tests)
2. Priority Classification
P0 (Blocker) - Must fix before release
- Prevents core functionality
- Security vulnerabilities (SQL injection, XSS)
- Data corruption/loss
- System crashes
P1 (Critical) - Fix within 2 weeks
- Major feature broken with workaround
- Significant UX degradation
- Performance issues
P2 (High) - Fix within 4 weeks
- Minor feature issues
- Edge cases
- Non-critical bugs
P3 (Medium) - Fix when possible
- Cosmetic issues
- Rare edge cases
- Nice-to-have improvements
P4 (Low) - Optional
- Documentation typos
- Minor UI alignment
3. Test Types
Unit Tests:
- Test individual functions/methods
- No external dependencies
- Fast execution (<100ms)
- Coverage: ≥80% statements, 75% branches
Integration Tests:
- Test component interactions
- Real dependencies (database, APIs)
- Moderate execution time
- Coverage: Critical user journeys
E2E Tests:
- Test complete user workflows
- Real browser/environment
- Slow execution
- Coverage: Happy paths + critical failures
Security Tests:
- OWASP Top 10 coverage
- Input validation
- Authentication/authorization
- Data protection
Coverage Thresholds
Code Coverage Targets
- ✅ Statements: ≥80%
- ✅ Branches: ≥75%
- ✅ Functions: ≥85%
- ✅ Lines: ≥80%
Test Distribution (Recommended)
- Unit Tests: 70%
- Integration Tests: 20%
- E2E Tests: 10%
Test Isolation
Mandatory Principles
-
No Shared State
❌ BAD: Tests share global variables ✅ GOOD: Each test has independent data -
Fresh Data Per Test
beforeEach(() => { database.seed(freshData); }); -
Cleanup After Tests
afterEach(() => { database.cleanup(); mockServer.reset(); });
Fail-Fast Validation
Critical Security Pattern
// ❌ BAD: Fallback to mock data
if (error) {
return getMockData(); // WRONG - hides issues
}
// ✅ GOOD: Fail immediately
if (error || !data) {
throw new Error(error?.message || 'Operation failed');
}
Input Validation
// Validate BEFORE any operations
function processSkillName(input: string): void {
// Security checks first
if (input.includes('..')) {
throw new ValidationError('Path traversal detected');
}
if (input.startsWith('/')) {
throw new ValidationError('Absolute paths not allowed');
}
// Then business logic
return performOperation(input);
}
Test Documentation Standards
Test Case Template
### TC-XXX-YYY: Descriptive Title
**Priority**: P0/P1/P2/P3/P4
**Type**: Unit/Integration/E2E/Security
**Estimated Time**: X minutes
**Prerequisites**:
- Specific, verifiable conditions
**Test Steps**:
1. Exact command or action
2. Specific input data
3. Verification step
**Expected Result**:
✅ Measurable outcome
✅ Specific verification criteria
**Pass/Fail Criteria**:
- ✅ PASS: All verification steps succeed
- ❌ FAIL: Any error or deviation
**Potential Bugs**:
- Known edge cases
- Security concerns
Quality Gates
Release Criteria
| Gate | Threshold | Blocker |
|---|---|---|
| Test Execution | 100% | Yes |
| Pass Rate | ≥80% | Yes |
| P0 Bugs | 0 | Yes |
| P1 Bugs | ≤5 | Yes |
| Code Coverage | ≥80% | Yes |
| Security | 90% OWASP | Yes |
Daily Checkpoints
Morning Standup:
- Yesterday's progress
- Today's plan
- Blockers
End-of-Day:
- Tests executed
- Pass rate
- Bugs filed
- Tomorrow's plan
Weekly Review
Friday Report:
- Week summary
- Baseline comparison
- Quality gates status
- Next week plan
Best Practices Summary
DO:
- ✅ Write reproducible test cases
- ✅ Update tracking after EACH test
- ✅ File bugs immediately on failure
- ✅ Follow AAA pattern
- ✅ Maintain test isolation
- ✅ Document environment details
DON'T:
- ❌ Skip test documentation
- ❌ Batch CSV updates
- ❌ Ignore security tests
- ❌ Use production data in tests
- ❌ Skip cleanup
- ❌ Hard-code test data
References: