qa-skills 3.0.0

package/skills/qa-test-reviewer/SKILL.md

@@ -0,0 +1,142 @@
+---
+name: qa-test-reviewer
+description: Code review for test files analyzing structure, assertions, coverage, anti-patterns, and providing a code-smell catalog with before/after improvement examples.
+output_dir: reports/reviews
+---
+
+# QA Test Reviewer
+
+## Purpose
+
+Perform code review on test files to assess quality, identify anti-patterns, and recommend improvements. Analyzes test structure, assertion quality, coverage alignment, naming conventions, and mocking correctness. Produces a structured review report with severity ratings and suggested fixes.
+
+## Trigger Phrases
+
+- "Review my test code" / "Code review for tests"
+- "Analyze test quality" / "Test code quality review"
+- "Find test anti-patterns" / "Test code smells"
+- "Review [test file] for best practices"
+- "Improve test assertions" / "Fix test structure"
+- "Test coverage alignment check"
+- "DRY vs DAMP in tests"
+
+## Review Criteria
+
+| Criterion | What to Check |
+|-----------|---------------|
+| **Test structure** | describe/it nesting, setup/teardown placement, logical grouping |
+| **Assertion quality** | Specific vs vague assertions; one logical assertion per test |
+| **Coverage alignment** | Test ↔ requirement traceability; tests map to intended behavior |
+| **Anti-patterns** | Hardcoded data, shared state, sleep waits, implementation coupling |
+| **Naming conventions** | Descriptive test names; consistent style (should/expect format) |
+| **DRY vs DAMP** | Shared setup where appropriate; readable tests over excessive abstraction |
+| **Mocking correctness** | Mocks verify behavior; no over-mocking; correct setup/teardown |
+
+See `references/anti-patterns.md` for the full catalog with before/after examples.
+
+## Code Smell Catalog
+
+| Smell | Description | See |
+|-------|-------------|-----|
+| **Magic numbers in tests** | Unexplained literals (timeouts, IDs, counts) | `references/anti-patterns.md` |
+| **Copy-paste test duplication** | Nearly identical tests; should use parametrize/fixtures | `references/anti-patterns.md` |
+| **Assertion-free tests** | Tests that run code but never assert | `references/anti-patterns.md` |
+| **Over-mocking** | Mocking everything; tests verify mocks, not behavior | `references/anti-patterns.md` |
+| **Test logic (if/for in tests)** | Conditional logic inside tests; tests should be deterministic | `references/anti-patterns.md` |
+| **Ignored tests without explanation** | skip/xfail/todo with no reason | `references/anti-patterns.md` |
+| **Hardcoded URLs/selectors** | Brittle strings; should use constants or config | `references/anti-patterns.md` |
+
+Each smell includes before/after examples in `references/anti-patterns.md`.
+
+## Output Format
+
+### Review Report Template
+
+```markdown
+# Test Review Report: [file/module name]
+
+## Summary
+- **Files reviewed:** [count]
+- **Issues found:** [count] (Critical: X, High: Y, Medium: Z, Low: W)
+- **Overall assessment:** Pass / Needs improvement / Fail
+
+## Issues
+
+### [Severity] [Issue title]
+**Location:** [file:line]
+**Smell:** [from catalog]
+**Description:** [what's wrong]
+**Suggested fix:**
+[before/after code or instructions]
+
+## Recommendations
+1. [Priority action]
+2. [Secondary action]
+
+## References
+- Anti-patterns: references/anti-patterns.md
+- Checklist: references/review-checklist.md
+```
+
+### Severity Levels
+
+| Level | When to use |
+|-------|-------------|
+| **Critical** | Tests are broken, misleading, or will cause false confidence |
+| **High** | Significant maintainability or reliability issues |
+| **Medium** | Best-practice violations; improves quality |
+| **Low** | Style or minor improvements |
+
+## Workflow
+
+1. **Receive test files** — User provides path(s) or content
+2. **Apply review checklist** — Use `references/review-checklist.md` systematically
+3. **Identify smells** — Map findings to `references/anti-patterns.md` catalog
+4. **Assign severity** — Critical/High/Medium/Low per impact
+5. **Suggest fixes** — Provide before/after examples where applicable
+6. **Produce report** — Structured output per template above
+
+## Scope
+
+**Can do (autonomous):**
+- Review test files for structure, assertions, anti-patterns
+- Produce review report with severity and suggested fixes
+- Reference anti-patterns catalog and review checklist
+- Suggest refactors with before/after examples
+
+**Cannot do (requires confirmation):**
+- Apply fixes directly to test code (review only; user applies)
+- Change test framework or migrate tests
+- Override organizational coding standards
+
+**Will not do (out of scope):**
+- Modify production/application code
+- Execute tests or generate coverage (consume existing reports)
+- Implement fixes; this skill reviews and recommends only
+
+## References
+
+| Topic | File |
+|-------|------|
+| Anti-patterns catalog with before/after examples | `references/anti-patterns.md` |
+| Comprehensive test review checklist | `references/review-checklist.md` |
+
+## Quality Checklist
+
+- [ ] All review criteria from checklist applied
+- [ ] Issues mapped to code smell catalog where applicable
+- [ ] Severity assigned per impact (Critical/High/Medium/Low)
+- [ ] Suggested fixes include before/after when helpful
+- [ ] Report follows template format
+- [ ] No hardcoded secrets in examples
+- [ ] Traceability preserved (test case IDs, requirement links)
+
+## Troubleshooting
+
+| Symptom | Likely Cause | Fix |
+|---------|--------------|-----|
+| Report too verbose | Every minor issue listed | Focus on High/Critical; group Low by category |
+| Before/after unclear | Example too abstract | Use concrete code from reviewed file |
+| Checklist incomplete | Missing framework-specific checks | See review-checklist.md for Jest/pytest/Playwright sections |
+| Severity inconsistent | Subjective judgment | Use severity table; Critical = broken/misleading |
+| User wants fixes applied | Skill is review-only | Clarify scope; offer to generate patch as separate step |

package/skills/qa-test-reviewer/references/anti-patterns.md

@@ -0,0 +1,268 @@
+# Test Anti-Patterns Catalog
+
+Before/after examples for common test code smells. Use this catalog when reviewing tests.
+
+---
+
+## 1. Magic Numbers in Tests
+
+**Smell:** Unexplained literals (timeouts, IDs, counts) make tests brittle and hard to understand.
+
+### Before
+
+```typescript
+it('loads user data', async () => {
+  await page.waitForSelector('.user-card', { timeout: 5000 });
+  expect(await page.$$('.user-item')).toHaveLength(10);
+});
+```
+
+```python
+def test_pagination():
+    response = client.get('/users?page=1&per_page=25')
+    assert len(response.json()['items']) == 25
+```
+
+### After
+
+```typescript
+const USER_LOAD_TIMEOUT_MS = 5000;
+const EXPECTED_DEFAULT_PAGE_SIZE = 10;
+
+it('loads user data', async () => {
+  await page.waitForSelector('.user-card', { timeout: USER_LOAD_TIMEOUT_MS });
+  expect(await page.$$('.user-item')).toHaveLength(EXPECTED_DEFAULT_PAGE_SIZE);
+});
+```
+
+```python
+DEFAULT_PAGE_SIZE = 25
+
+def test_pagination():
+    response = client.get(f'/users?page=1&per_page={DEFAULT_PAGE_SIZE}')
+    assert len(response.json()['items']) == DEFAULT_PAGE_SIZE
+```
+
+---
+
+## 2. Copy-Paste Test Duplication
+
+**Smell:** Nearly identical tests; should use parametrize or shared fixtures.
+
+### Before
+
+```typescript
+it('validates email format for gmail', () => {
+  expect(validateEmail('user@gmail.com')).toBe(true);
+});
+it('validates email format for outlook', () => {
+  expect(validateEmail('user@outlook.com')).toBe(true);
+});
+it('validates email format for yahoo', () => {
+  expect(validateEmail('user@yahoo.com')).toBe(true);
+});
+```
+
+```python
+def test_email_gmail():
+    assert validate_email('user@gmail.com') is True
+
+def test_email_outlook():
+    assert validate_email('user@outlook.com') is True
+
+def test_email_yahoo():
+    assert validate_email('user@yahoo.com') is True
+```
+
+### After
+
+```typescript
+const validEmails = ['user@gmail.com', 'user@outlook.com', 'user@yahoo.com'];
+validEmails.forEach((email) => {
+  it(`validates email format: ${email}`, () => {
+    expect(validateEmail(email)).toBe(true);
+  });
+});
+// Or use test.each in Jest/Vitest
+```
+
+```python
+@pytest.mark.parametrize('email', ['user@gmail.com', 'user@outlook.com', 'user@yahoo.com'])
+def test_valid_email_formats(email):
+    assert validate_email(email) is True
+```
+
+---
+
+## 3. Assertion-Free Tests
+
+**Smell:** Tests that run code but never assert; they pass even when behavior is wrong.
+
+### Before
+
+```typescript
+it('saves user to database', async () => {
+  await userService.create({ name: 'Alice', email: 'alice@test.com' });
+});
+```
+
+```python
+def test_create_user():
+    user_service.create(name='Alice', email='alice@test.com')
+```
+
+### After
+
+```typescript
+it('saves user to database', async () => {
+  const user = await userService.create({ name: 'Alice', email: 'alice@test.com' });
+  expect(user.id).toBeDefined();
+  expect(user.name).toBe('Alice');
+  const saved = await db.users.findById(user.id);
+  expect(saved).toEqual(user);
+});
+```
+
+```python
+def test_create_user():
+    user = user_service.create(name='Alice', email='alice@test.com')
+    assert user.id is not None
+    assert user.name == 'Alice'
+    saved = db.users.find_by_id(user.id)
+    assert saved == user
+```
+
+---
+
+## 4. Over-Mocking
+
+**Smell:** Mocking everything; tests verify mocks, not real behavior.
+
+### Before
+
+```typescript
+it('fetches user', async () => {
+  const mockFetch = jest.fn().mockResolvedValue({ id: 1, name: 'Alice' });
+  (global as any).fetch = mockFetch;
+  const user = await userService.getUser(1);
+  expect(mockFetch).toHaveBeenCalledWith('/api/users/1');
+  expect(user.name).toBe('Alice'); // from mock, not real logic
+});
+```
+
+### After
+
+```typescript
+it('fetches user from API', async () => {
+  const mockResponse = { id: 1, name: 'Alice' };
+  server.use(http.get('/api/users/:id', () => HttpResponse.json(mockResponse)));
+  const user = await userService.getUser(1);
+  expect(user.name).toBe('Alice');
+  expect(user.id).toBe(1);
+});
+// Or: test integration with real API in integration suite; mock only external deps
+```
+
+---
+
+## 5. Test Logic (if/for in Tests)
+
+**Smell:** Conditional logic inside tests; tests should be deterministic and simple.
+
+### Before
+
+```typescript
+it('handles multiple users', () => {
+  const users = getUsers();
+  for (const u of users) {
+    if (u.role === 'admin') {
+      expect(u.permissions).toContain('delete');
+    } else {
+      expect(u.permissions).not.toContain('delete');
+    }
+  }
+});
+```
+
+### After
+
+```typescript
+it('admin users have delete permission', () => {
+  const admin = getUsers().find(u => u.role === 'admin');
+  expect(admin?.permissions).toContain('delete');
+});
+it('non-admin users lack delete permission', () => {
+  const regular = getUsers().find(u => u.role !== 'admin');
+  expect(regular?.permissions).not.toContain('delete');
+});
+```
+
+---
+
+## 6. Ignored Tests Without Explanation
+
+**Smell:** skip/xfail/todo with no reason; tests get forgotten.
+
+### Before
+
+```typescript
+it.skip('flaky test', () => { /* ... */ });
+it.todo('something');
+```
+
+```python
+@pytest.mark.skip
+def test_something():
+    pass
+```
+
+### After
+
+```typescript
+it.skip('flaky: API returns 500 intermittently; ticket QA-123', () => { /* ... */ });
+it.todo('add test for bulk delete when API is ready');
+```
+
+```python
+@pytest.mark.skip(reason='Flaky: API returns 500 intermittently; ticket QA-123')
+def test_something():
+    pass
+```
+
+---
+
+## 7. Hardcoded URLs/Selectors
+
+**Smell:** Brittle strings; should use constants or config.
+
+### Before
+
+```typescript
+await page.goto('https://staging.example.com/login');
+await page.click('#root > div > form > button[type="submit"]');
+```
+
+```python
+driver.get('https://staging.example.com/login')
+driver.find_element(By.CSS_SELECTOR, '#root > div > form > button[type="submit"]').click()
+```
+
+### After
+
+```typescript
+const BASE_URL = process.env.TEST_BASE_URL || 'https://staging.example.com';
+const SELECTORS = {
+  loginSubmit: 'button[type="submit"]',
+  // or use data-testid: '[data-testid="login-submit"]'
+};
+await page.goto(`${BASE_URL}/login`);
+await page.click(SELECTORS.loginSubmit);
+```
+
+```python
+BASE_URL = os.environ.get('TEST_BASE_URL', 'https://staging.example.com')
+LOGIN_SUBMIT = '[data-testid="login-submit"]'
+
+driver.get(f'{BASE_URL}/login')
+driver.find_element(By.CSS_SELECTOR, LOGIN_SUBMIT).click()
+```

package/skills/qa-test-reviewer/references/review-checklist.md

@@ -0,0 +1,93 @@
+# Test Review Checklist
+
+Use this checklist systematically when reviewing test files.
+
+---
+
+## 1. Test Structure
+
+- [ ] **describe/it nesting** — Logical grouping; max 3–4 levels deep
+- [ ] **Setup/teardown** — beforeEach/afterEach or fixtures in correct scope
+- [ ] **Test isolation** — Each test independent; no shared mutable state
+- [ ] **Arrange-Act-Assert** — Clear three-phase structure
+- [ ] **One logical assertion per test** — Single behavior under test
+
+### Framework-Specific
+
+| Framework | Structure |
+|-----------|-----------|
+| Jest/Vitest | describe → it; beforeEach/afterEach |
+| pytest | class or module; fixtures with scope |
+| Playwright | test() with test.describe; fixtures |
+| Cypress | describe → it; beforeEach |
+
+---
+
+## 2. Assertion Quality
+
+- [ ] **Specific assertions** — `expect(x).toBe(y)` not `expect(!!x).toBe(true)` when possible
+- [ ] **Meaningful failure messages** — Custom message when assertion is unclear
+- [ ] **No assertion-free tests** — Every test asserts something
+- [ ] **Correct matchers** — toEqual vs toBe; toContain vs toHaveLength
+
+---
+
+## 3. Coverage Alignment
+
+- [ ] **Requirement traceability** — Test IDs or comments link to requirements
+- [ ] **Behavior-focused** — Tests verify behavior, not implementation
+- [ ] **Edge cases** — Boundaries, empty inputs, error paths covered
+- [ ] **No redundant tests** — Same behavior not tested multiple times
+
+---
+
+## 4. Anti-Patterns
+
+- [ ] **No magic numbers** — Constants for timeouts, counts, IDs
+- [ ] **No copy-paste duplication** — Parametrize or fixtures
+- [ ] **No sleep waits** — Explicit waits (waitForSelector, waitForResponse)
+- [ ] **No hardcoded URLs/selectors** — Config or constants
+- [ ] **No shared mutable state** — Each test gets fresh data
+- [ ] **No implementation coupling** — Test public API, not internals
+- [ ] **No test logic** — No if/for/switch inside tests
+- [ ] **No ignored tests without reason** — skip/xfail/todo with explanation
+
+---
+
+## 5. Naming Conventions
+
+- [ ] **Descriptive names** — "should display error when email is invalid"
+- [ ] **Consistent style** — should/expect or given-when-then
+- [ ] **No implementation details** — "clicks submit button" vs "calls onSubmit handler"
+
+---
+
+## 6. DRY vs DAMP
+
+- [ ] **Shared setup** — Common fixtures for repeated setup
+- [ ] **Readable over abstract** — DAMP when clarity matters
+- [ ] **No over-abstraction** — Test helpers that obscure intent
+
+---
+
+## 7. Mocking
+
+- [ ] **Mock only external deps** — APIs, DB, file system
+- [ ] **Verify behavior, not calls** — Prefer outcome over call count when possible
+- [ ] **Correct teardown** — Mocks restored after test
+- [ ] **No over-mocking** — Test real code paths where feasible
+
+---
+
+## Severity Mapping
+
+| Finding | Typical Severity |
+|---------|------------------|
+| Assertion-free test | Critical |
+| Shared mutable state | Critical |
+| sleep() in test | High |
+| Magic numbers everywhere | Medium |
+| Copy-paste duplication | Medium |
+| Hardcoded URL | Medium |
+| skip without reason | Low |
+| Naming style inconsistency | Low |

package/skills/qa-test-strategy/SKILL.md

@@ -0,0 +1,133 @@
+---
+name: qa-test-strategy
+description: Generate comprehensive test strategy documents covering scope, approach, testing types, environments, risk assessment, entry/exit criteria, and resource planning.
+output_dir: docs/plans
+dependencies:
+  recommended:
+    - qa-diagram-generator
+    - qa-risk-analyzer
+---
+
+# QA Test Strategy
+
+## Purpose
+
+Create comprehensive test strategy and test plan documents that define the overall approach to testing for a project or release. Aligns with ISO/IEC/IEEE 29119-3 and provides a strategic blueprint for all testing activities.
+
+## Trigger Phrases
+
+- "Create a test strategy for..."
+- "Generate test strategy document"
+- "Define testing approach for project"
+- "Test plan with risk assessment"
+- "Comprehensive QA strategy"
+
+## Output Sections
+
+Every test strategy document includes:
+
+| Section | Content |
+| ------- | ------- |
+| **Test Scope & Objectives** | In-scope/out-of-scope, measurable goals, success criteria |
+| **Testing Types Breakdown & Rationale** | Unit, integration, E2E, performance, security, accessibility, etc. — with rationale for each |
+| **Environment Requirements** | Dev, staging, prod parity, data, tooling |
+| **Risk Assessment Matrix** | Technical, business, process risks with probability/impact and mitigations |
+| **Entry/Exit Criteria** | Conditions to start and complete testing at each level |
+| **Resource & Timeline Estimation** | Roles, effort, schedule, dependencies |
+| **Defect Management Process** | Triage, severity, workflow, escalation |
+| **Definition of Done/Ready** | DoD for stories; DoR for sprint readiness |
+| **Test Data Strategy** | Sources, masking, refresh, synthetic data |
+| **CI/CD Integration Strategy** | Pipeline gates, automation triggers, reporting |
+
+## Testing Pyramid Guidance
+
+Apply the testing pyramid principle for balanced coverage:
+
+| Layer | Ratio (typical) | Focus |
+| ----- | ----------------- | ----- |
+| **Unit** | 70% | Fast, isolated, high volume |
+| **Integration** | 20% | Component interactions, APIs |
+| **E2E** | 10% | Critical user journeys, smoke |
+
+Reference `references/testing-types.md` for detailed type descriptions and when to apply each.
+
+## Risk-Based Test Prioritization
+
+1. **Identify risks** — Technical, business, process (see `references/risk-matrix.md`)
+2. **Score** — Probability × Impact = Risk score
+3. **Prioritize** — High-risk areas get more coverage and earlier testing
+4. **Mitigate** — Allocate exploratory, security, performance tests to high-risk zones
+
+## Integration with Other Skills
+
+| Need | Skill | Usage |
+| ---- | ----- | ----- |
+| Gantt charts, timelines | qa-diagram-generator | `references/gantt.md` for schedule visualization |
+| Mind maps, flowcharts | qa-diagram-generator | `references/mindmap.md`, `references/flowchart.md` for scope/process |
+| Detailed sub-plans | qa-plan-creator | Test plan, sprint plan, regression plan, performance plan |
+| NFR analysis | qa-nfr-analyst | Performance, security, usability requirements |
+
+## Workflow
+
+1. **Input:** Project context (scope, tech stack, timeline, constraints)
+2. **Scope:** Define in/out boundaries and objectives
+3. **Types:** Select testing types from `references/testing-types.md` with rationale
+4. **Pyramid:** Apply unit > integration > E2E ratios
+5. **Risk:** Populate risk matrix from `references/risk-matrix.md`
+6. **Criteria:** Apply entry/exit from `references/entry-exit-criteria.md`
+7. **Visuals:** Call qa-diagram-generator for Gantt, mind maps, flowcharts
+8. **Sub-plans:** Call qa-plan-creator for detailed test/sprint/regression plans
+9. **Output:** Complete test strategy document
+
+## Scope
+
+**Can do (autonomous):**
+- Generate full test strategy documents from project context
+- Populate all 10 output sections
+- Apply testing pyramid ratios and risk-based prioritization
+- Call qa-diagram-generator for Gantt, mind maps, flowcharts
+- Call qa-plan-creator for detailed sub-plans
+- Reference testing-types, risk-matrix, entry-exit-criteria
+
+**Cannot do (requires confirmation):**
+- Change project scope or release dates set by stakeholders
+- Override organizational test policy or standards
+- Assign resources without approval
+
+**Will not do (out of scope):**
+- Execute tests or automation
+- Modify production code or environments
+- Approve strategy (approval is stakeholder responsibility)
+
+## Quality Checklist
+
+- [ ] All 10 output sections present and populated
+- [ ] Test scope clearly defines in/out boundaries
+- [ ] Testing types include rationale (why each type)
+- [ ] Pyramid ratios applied (unit > integration > E2E)
+- [ ] Risk matrix populated with mitigations
+- [ ] Entry/exit criteria are testable and level-specific
+- [ ] Resource/timeline estimates are realistic
+- [ ] Diagrams generated for schedule/scope (Gantt, mind map)
+- [ ] References to qa-diagram-generator and qa-plan-creator correct
+- [ ] No hardcoded secrets
+
+## Troubleshooting
+
+| Symptom | Likely Cause | Fix |
+| ------- | ------------ | --- |
+| Strategy too generic | Insufficient context | Ask for scope, tech stack, timeline, team size |
+| Missing diagrams | qa-diagram-generator not invoked | Explicitly call for Gantt, mind map, flowchart |
+| Wrong testing types | Project type unclear | Clarify web/mobile/API/embedded; use testing-types reference |
+| Risk matrix empty | No risk input | Prompt for known risks; use risk-matrix template |
+| Entry/exit vague | Subjective language | Use entry-exit-criteria reference; make criteria measurable |
+| Pyramid inverted | E2E-heavy approach | Recommend rebalancing; explain pyramid rationale |
+| Duplicate content | Overlap with qa-plan-creator | Strategy = high-level; plan = detailed; delegate sub-plans |
+
+## Reference Files
+
+| Topic | Reference |
+| ----- | --------- |
+| Testing types | `references/testing-types.md` |
+| Risk assessment | `references/risk-matrix.md` |
+| Entry/exit criteria | `references/entry-exit-criteria.md` |