qa-skills 3.0.0

package/skills/qa-risk-analyzer/references/impact-analysis.md

@@ -0,0 +1,133 @@
+# Git Diff Impact Analysis Patterns
+
+## Overview
+
+Impact analysis maps git changes to affected modules, tests, and regression scope. Use this to prioritize testing and scope regression sets.
+
+---
+
+## 1. Parsing Git Diff
+
+### Commands
+
+```bash
+# Files changed in branch vs base
+git diff --name-only base_branch..HEAD
+
+# Files changed in last commit
+git diff --name-only HEAD~1..HEAD
+
+# Files changed in PR
+git diff --name-only origin/main...HEAD
+
+# With change stats
+git diff --stat base_branch..HEAD
+```
+
+### Output Structure
+
+- **Added:** New files (higher risk if untested)
+- **Modified:** Changed files (map to modules)
+- **Deleted:** Removed files (update test mapping)
+
+---
+
+## 2. File → Module Mapping
+
+### Strategies
+
+| Strategy | When to Use | How |
+|----------|-------------|-----|
+| **Directory** | Clear package structure | `src/auth/` → `auth` module |
+| **Package/Import** | JS/TS/Python | Parse `package.json`, `__init__.py`, imports |
+| **Config** | Custom mapping | `impact-mapping.json` or similar |
+| **Convention** | Monorepo | `packages/auth`, `apps/web` |
+
+### Example Mapping
+
+```
+src/auth/login.ts     → auth
+src/auth/session.ts   → auth
+src/api/users.ts      → api
+tests/auth/login.spec.ts → auth (test)
+```
+
+---
+
+## 3. Affected Tests
+
+### Coverage-Based
+
+- Use coverage report: which tests cover changed files?
+- Tools: Istanbul `--reporter json`, JaCoCo, coverage.py
+- Map: changed file → tests that execute it
+
+### Naming/Path-Based
+
+- Convention: `tests/<module>/` or `<module>.spec.ts`
+- Changed `auth/login.ts` → run `tests/auth/*` or `**/auth*.spec.ts`
+
+### Import-Based
+
+- Parse test files for imports of changed modules
+- Grep: `import.*from.*auth` in test files
+
+---
+
+## 4. Downstream Impact
+
+### Dependencies
+
+- **Import graph:** Who imports changed files?
+- **API consumers:** If changed file exports API, find callers
+- **Database:** Schema changes → migration tests, integration tests
+
+### Patterns
+
+```bash
+# Find files importing changed module
+grep -r "from.*auth" src/ tests/
+
+# Find API consumers (if OpenAPI available)
+# Cross-reference with qa-api-contract-curator
+```
+
+---
+
+## 5. Regression Scope
+
+### Suggested Set
+
+1. **Direct:** Tests for changed modules (from mapping)
+2. **Integration:** Tests that use changed APIs/components
+3. **Smoke:** Critical path tests (from qa-test-strategy)
+4. **Optional:** Full suite if risk > threshold
+
+### Output Format
+
+```markdown
+## Regression Scope for [Branch/PR]
+
+### Must Run (High Impact)
+- tests/auth/login.spec.ts
+- tests/auth/session.spec.ts
+- tests/api/users.integration.spec.ts
+
+### Should Run (Medium Impact)
+- tests/checkout/flow.spec.ts
+
+### Optional (Low Impact)
+- Full E2E suite
+```
+
+---
+
+## 6. Edge Cases
+
+| Case | Handling |
+|------|----------|
+| **New file** | No change frequency; use complexity + criticality |
+| **Config only** | Lower risk; may affect env-specific tests |
+| **Test file changed** | Include in regression; flag for review |
+| **Generated code** | Exclude or treat as low risk |
+| **Merge conflict resolution** | Re-analyze after merge |

package/skills/qa-risk-analyzer/references/risk-factors.md

@@ -0,0 +1,123 @@
+# Risk Factor Calculation Methods
+
+## Overview
+
+Risk factors feed into the formula: **Risk = Complexity × ChangeFrequency × (1 - TestCoverage)**. Each factor should be normalized to a 0–1 scale for consistent scoring.
+
+---
+
+## 1. Code Complexity
+
+### Cyclomatic Complexity
+
+| Tool | Language | Command / Config |
+|------|----------|------------------|
+| **ESLint** | JS/TS | `complexity` rule; `cyclomatic-complexity` |
+| **radon** | Python | `radon cc -a -s path` |
+| **SonarQube** | Multi | Complexity metric per file |
+| **Checkstyle** | Java | `CyclomaticComplexity` |
+
+### Normalization (0–1)
+
+```
+normalized = min(1, raw_complexity / threshold)
+```
+
+- Typical threshold: 10 (McCabe); high = 15+
+- Scale: 0 = trivial, 1 = very complex
+
+### Alternative: Coupling
+
+- **Afferent coupling (Ca):** Incoming dependencies
+- **Efferent coupling (Ce):** Outgoing dependencies
+- **Instability:** Ce / (Ca + Ce) — higher = more change-prone
+
+---
+
+## 2. Change Frequency
+
+### Git History
+
+```bash
+# Commits per file (last N commits)
+git log --follow --format=format: --name-only -n 100 | sort | uniq -c | sort -rn
+
+# Per directory/module
+git log --follow --format=format: --name-only -n 100 -- path/to/module
+```
+
+### Normalization (0–1)
+
+```
+normalized = min(1, commit_count / max_commits_in_repo)
+```
+
+- `max_commits_in_repo` = highest commit count among analyzed files
+- Higher = more frequently changed = higher risk
+
+### Time Windows
+
+- **Sprint:** Last 2 weeks
+- **Release:** Last 4–8 weeks
+- **All time:** Full history (use for baseline)
+
+---
+
+## 3. Test Coverage
+
+### Source
+
+- **qa-coverage-analyzer** output (Istanbul, JaCoCo, coverage.py)
+- Line coverage or branch coverage per file/module
+- Already 0–1 (e.g., 0.85 = 85%)
+
+### In Formula
+
+- `(1 - TestCoverage)` — low coverage increases risk
+- Coverage = 1 → factor = 0 (no coverage risk)
+- Coverage = 0 → factor = 1 (full coverage risk)
+
+---
+
+## 4. Defect History (Adjustment)
+
+### Source
+
+- **Memory MCP:** Past bugs per module/component
+- Jira/issue tracker: Bugs linked to files/modules
+- Manual tagging in config
+
+### Application
+
+- **Multiplier:** e.g., `1 + (defect_count / 10)` — more defects = higher risk
+- **Additive:** Add fixed points for "defect-prone" modules
+- Use as ranking adjustment, not primary factor
+
+---
+
+## 5. Business Criticality
+
+### Levels
+
+| Level | Examples | Weight |
+|-------|----------|--------|
+| **Critical** | Payment, auth, core flows | 1.5–2.0 |
+| **High** | Checkout, user profile | 1.2–1.5 |
+| **Medium** | Search, filters | 1.0 |
+| **Low** | Help, static content | 0.7–0.9 |
+
+### Application
+
+- Multiply final risk score by criticality weight
+- Requires stakeholder input or config file
+
+---
+
+## Combined Risk Score
+
+```
+base_risk = Complexity × ChangeFrequency × (1 - TestCoverage)
+adjusted_risk = base_risk × DefectMultiplier × CriticalityWeight
+```
+
+Rank modules/features by `adjusted_risk` descending.

package/skills/qa-robot-framework-writer/SKILL.md

@@ -0,0 +1,147 @@
+---
+name: qa-robot-framework-writer
+description: Generate Robot Framework tests for E2E, acceptance testing, and RPA with keyword-driven human-readable syntax, SeleniumLibrary, BrowserLibrary, and RequestsLibrary.
+output_dir: tests/e2e
+---
+
+# QA Robot Framework Writer
+
+## Purpose
+
+Write Robot Framework tests from test case specifications. Transform structured test cases (from qa-testcase-from-docs, qa-manual-test-designer, qa-testcase-from-ui, or specs) into executable `.robot` files with keyword-driven syntax, resource files, and proper configuration.
+
+## Trigger Phrases
+
+- "Write Robot Framework tests for [feature/flow]"
+- "Generate Robot Framework E2E tests from test cases"
+- "Create Robot Framework acceptance tests"
+- "Add Robot Framework tests with SeleniumLibrary"
+- "Robot Framework tests for [URL/flow]"
+- "Robot Framework API tests with RequestsLibrary"
+- "Robot Framework RPA automation for [task]"
+- "BrowserLibrary Playwright tests in Robot Framework"
+- "Data-driven Robot Framework tests"
+- "BDD-style Robot Framework tests"
+
+## Key Features
+
+| Feature | Description |
+| ------- | ----------- |
+| **Keyword-driven** | Human-readable keywords; business logic in reusable keywords |
+| **Human-readable syntax** | Plain-text, tab-separated; no programming required for basic tests |
+| **SeleniumLibrary** | Browser automation (Open Browser, Input Text, Click Element) |
+| **BrowserLibrary** | Playwright-based modern browser automation |
+| **RequestsLibrary** | API testing (GET, POST, PUT, DELETE) |
+| **Built-in data-driven** | FOR loops, template tests, variable tables |
+| **Variable support** | `*** Variables ***`, variable files, `${VAR}` syntax |
+| **Extensible via Python** | Custom libraries, listener APIs |
+
+## Test Types
+
+| Type | Scope | Approach |
+|------|-------|----------|
+| **E2E web** | Full user flows, browser interactions | SeleniumLibrary or BrowserLibrary |
+| **Acceptance** | BDD-style Given/When/Then | Gherkin-like keywords |
+| **RPA** | Desktop/file/process automation | RPA Framework, Process, OperatingSystem |
+| **API** | REST endpoints | RequestsLibrary |
+
+## Workflow
+
+1. **Read test cases** — From specs, requirements, or manual test designs
+2. **Generate .robot files** — Produce `{feature}.robot` with test cases and keywords
+3. **Add resource files** — Shared keywords in `resources/*.robot`
+4. **Configure** — Variable files, output dir, listeners, CLI options
+
+## Context7 MCP
+
+Use **Context7 MCP** for Robot Framework documentation when:
+- Library keyword syntax (SeleniumLibrary, BrowserLibrary, RequestsLibrary) is uncertain
+- Variable scope, FOR loops, or template syntax needs verification
+- Resource file import or variable file format requires reference
+
+## Key Patterns
+
+| Pattern | Usage |
+| ------- | ----- |
+| `*** Settings ***` | Library imports, resource imports, suite/test setup |
+| `*** Variables ***` | Suite-level variables |
+| `*** Test Cases ***` | Test case definitions |
+| `*** Keywords ***` | Reusable keyword definitions |
+| Given/When/Then | BDD-style keyword naming |
+| FOR loops | `FOR    ${item}    IN    @{list}` |
+| IF/ELSE | `IF    condition    ...    ELSE    ...` |
+| TRY/EXCEPT | Error handling in keywords |
+| Template tests | Data-driven via `[Template]` |
+| `[Documentation]` | Test/keyword documentation |
+| `[Tags]` | Test categorization |
+
+## Libraries
+
+| Library | Purpose | Key Keywords |
+| ------- | ------- | ------------ |
+| **SeleniumLibrary** | Browser (Selenium) | Open Browser, Input Text, Click Element, Get Title, Close Browser |
+| **BrowserLibrary** | Browser (Playwright) | New Browser, Click, Fill Text, Get Text, Close Browser |
+| **RequestsLibrary** | API | GET, POST, PUT, DELETE, Create Session, Status Should Be |
+| **BuiltIn** | Core | Log, Should Be Equal, Run Keyword If, Fail, Sleep |
+| **Collections** | Lists/dicts | Get From List, Append To List, Dictionary Should Contain Key |
+| **String** | String ops | Get Length, Should Contain, Replace String |
+| **DateTime** | Date/time | Get Current Date, Add Time To Date |
+
+## File Naming
+
+- `{feature}.robot` — Test files (e.g., `login.robot`, `checkout.robot`)
+- `resources/*.robot` — Resource files for shared keywords (e.g., `resources/common.robot`)
+- `variables.py` or `variables.robot` — Variable files for environment/config
+
+## Scope
+
+**Can do (autonomous):**
+- Generate Robot Framework tests from test case specs
+- Create .robot files with Settings, Variables, Test Cases, Keywords
+- Add resource files for shared keywords
+- Use SeleniumLibrary, BrowserLibrary, RequestsLibrary as appropriate
+- Apply BDD-style Given/When/Then, data-driven (FOR, template), TRY/EXCEPT
+- Configure variable files, output dir, basic CLI options
+- Call qa-diagram-generator for test flow diagrams if needed
+- Use Context7 MCP for Robot Framework docs
+
+**Cannot do (requires confirmation):**
+- Change production code to satisfy tests
+- Add tests for requirements not in source documents
+- Override project-level Robot config without approval
+- Install new libraries not in project dependencies
+
+**Will not do (out of scope):**
+- Execute tests (user runs `robot tests/` or `robot -d output tests/`)
+- Write Playwright/Cypress TypeScript tests (use qa-playwright-ts-writer, qa-cypress-writer)
+- Modify CI/CD pipelines
+
+## References
+
+- `references/patterns.md` — Keyword-driven, BDD, data-driven, resource files, variable files
+- `references/libraries.md` — SeleniumLibrary, BrowserLibrary, RequestsLibrary, BuiltIn, Collections
+- `references/config.md` — CLI options, variable files, output dir, listeners
+- `references/best-practices.md` — Keyword naming, resource organization, variable scope, test independence
+
+## Quality Checklist
+
+- [ ] Tests match test case steps and expected results
+- [ ] Keywords are reusable and well-named (Given/When/Then where appropriate)
+- [ ] No hardcoded secrets or sensitive data (use variables)
+- [ ] Resource files used for shared logic; no duplication
+- [ ] Proper teardown (Close Browser, Delete All Sessions) in suite/test teardown
+- [ ] File naming follows `{feature}.robot` convention
+- [ ] [Documentation] and [Tags] applied for traceability
+- [ ] Variable scope appropriate (suite vs test vs keyword)
+
+## Troubleshooting
+
+| Symptom | Likely Cause | Fix |
+| ------- | ------------ | --- |
+| Keyword not found | Library not imported, typo | Add `Library    LibraryName` in Settings; check keyword spelling |
+| Variable not defined | Scope or variable file | Define in Variables section or variable file; check `${VAR}` syntax |
+| Element not found | Selector, timing | Use Wait Until Element Is Visible; verify locator (id, xpath, css) |
+| Resource import fails | Path, file missing | Use relative path from test file; ensure resource exists |
+| API test fails | Session, URL | Create Session before requests; verify base URL |
+| Browser not opening | Driver, browser binary | Install chromedriver/geckodriver; or use BrowserLibrary (bundled) |
+| FOR loop syntax error | Indentation, IN RANGE | Use 4+ spaces between FOR items; check `IN` vs `IN RANGE` |

package/skills/qa-robot-framework-writer/references/best-practices.md

@@ -0,0 +1,249 @@
+# Robot Framework Best Practices
+
+## Keyword Naming
+
+### Use Descriptive, Action-Oriented Names
+
+| Good | Avoid |
+| ---- | ----- |
+| `User Clicks Login Button` | `Click1` |
+| `Verify Order Total Matches Cart` | `Check` |
+| `Navigate To Checkout Page` | `Go` |
+| `Enter Valid Credentials` | `Do Login` |
+
+### BDD-Style (Given/When/Then)
+
+- **Given** — Preconditions, setup
+- **When** — Actions, user/system behavior
+- **Then** — Assertions, expected outcomes
+- **And** — Additional steps in same phase
+
+```robot
+*** Keywords ***
+Given User Is On Login Page
+    Open Browser    ${LOGIN_URL}    ${BROWSER}
+    Title Should Be    Login
+
+When User Enters Valid Credentials
+    Input Text    id=username    ${VALID_USER}
+    Input Password    id=password    ${VALID_PASS}
+    Click Button    id=login
+
+Then User Should See Dashboard
+    Wait Until Location Contains    /dashboard
+    Page Should Contain    Welcome
+```
+
+### One Logical Action Per Keyword
+
+Keep keywords focused. Avoid "god keywords" that do too much:
+
+```robot
+# Good: Single responsibility
+Enter Username    ${user}
+Enter Password    ${pass}
+Click Login Button
+
+# Avoid: One keyword doing everything
+Login With User And Password And Submit    ${user}    ${pass}
+```
+
+---
+
+## Resource Organization
+
+### Structure by Domain
+
+```
+resources/
+├── common.robot          # Shared setup, teardown, generic keywords
+├── login_keywords.robot  # Login-specific keywords
+├── checkout_keywords.robot
+├── api_keywords.robot
+└── variables.robot       # Shared variables (or use variable files)
+```
+
+### Layered Imports
+
+- **common.robot** — Base libraries, variables, generic keywords
+- **Feature resources** — Import common; add feature-specific keywords
+- **Test files** — Import only needed resources
+
+```robot
+*** Settings ***
+# In login.robot
+Resource    resources/common.robot
+Resource    resources/login_keywords.robot
+```
+
+### Avoid Circular Imports
+
+Resource A imports B, B imports A → Error. Keep dependency graph acyclic.
+
+---
+
+## Variable Scope
+
+| Scope | When to Use | How |
+| ----- | ----------- | --- |
+| **Local** | Within keyword | `[Arguments]` or `Set Variable` |
+| **Test** | Single test | `Set Test Variable` |
+| **Suite** | All tests in suite | `Set Suite Variable` |
+| **Global** | Entire run | Variable file, `-v`, or `Set Global Variable` |
+
+### Prefer Explicit Passing Over Global State
+
+```robot
+# Prefer: Pass as argument
+Login And Verify    ${user}    ${pass}
+
+# Avoid: Rely on global state
+Set Suite Variable    ${CURRENT_USER}    ${user}
+Login And Verify
+```
+
+### Sensitive Data
+
+- Never hardcode passwords, API keys
+- Use variable files loaded per environment
+- Use `-v` or env vars in CI: `-v API_KEY:${API_KEY}`
+
+---
+
+## Test Independence
+
+### Each Test Should Be Runnable Alone
+
+- No shared mutable state between tests
+- Each test sets up its own preconditions
+- Use Suite/Test Setup and Teardown for common setup/cleanup
+
+### Clean Up in Teardown
+
+```robot
+*** Settings ***
+Test Teardown    Cleanup Test Data
+
+*** Keywords ***
+Cleanup Test Data
+    Run Keyword If Test Failed    Capture Page Screenshot
+    Delete Test User    ${TEST_USER}
+    Close Browser
+```
+
+### Avoid Test Order Dependencies
+
+- Tests should pass in any order
+- Use `--randomize all` occasionally to detect order dependencies
+
+---
+
+## Locator Strategy
+
+### Prefer Stable Locators
+
+| Priority | Type | Example | Notes |
+| -------- | ---- | ------- | ----- |
+| 1 | id | `id=submit-btn` | Stable if IDs are consistent |
+| 2 | data-testid | `css=[data-testid=submit]` | Explicit for testing |
+| 3 | name | `name=email` | Good for forms |
+| 4 | role/label | `role=button[name=Submit]` | Accessible |
+| 5 | css/xpath | `css=.btn-primary` | Last resort; can break with UI changes |
+
+### Centralize Locators
+
+```robot
+*** Variables ***
+${LOGIN_BUTTON}    id=login-btn
+${USERNAME_INPUT}  id=username
+${PASSWORD_INPUT}  id=password
+
+*** Keywords ***
+User Clicks Login Button
+    Click Element    ${LOGIN_BUTTON}
+```
+
+---
+
+## Data-Driven Tests
+
+### Use [Template] for Same Flow, Different Data
+
+```robot
+*** Test Cases ***
+Login With Multiple Users
+    [Template]    Login And Verify Success
+    user1    pass1
+    user2    pass2
+    admin    admin123
+```
+
+### Use FOR for Iteration
+
+```robot
+FOR    ${item}    IN    @{ITEMS}
+    Add Item To Cart    ${item}
+    Verify Cart Contains    ${item}
+END
+```
+
+---
+
+## Error Handling and Resilience
+
+### Use TRY/EXCEPT for Expected Failures
+
+```robot
+TRY
+    Click Element    ${OPTIONAL_BUTTON}
+EXCEPT    Element not found
+    Log    Optional button not present, continuing
+END
+```
+
+### Use Wait Until for Flaky Elements
+
+```robot
+Wait Until Element Is Visible    ${DYNAMIC_ELEMENT}    timeout=10s
+Click Element    ${DYNAMIC_ELEMENT}
+```
+
+### Capture Screenshot on Failure
+
+```robot
+Test Teardown    Run Keyword If Test Failed    Capture Page Screenshot
+```
+
+---
+
+## Documentation
+
+### Add [Documentation] to Keywords and Tests
+
+```robot
+*** Test Cases ***
+User Can Complete Checkout
+    [Documentation]    Verify full checkout flow with valid payment.
+    ...                Covers: cart review, shipping, payment, confirmation.
+    [Tags]    smoke    checkout
+    Given User Has Items In Cart
+    When User Completes Checkout With Card    ${TEST_CARD}
+    Then Order Confirmation Is Displayed
+```
+
+### Use Tags for Filtering
+
+- `smoke` — Critical path
+- `regression` — Full regression
+- `e2e` — End-to-end
+- `api` — API tests
+- `slow` — Long-running (exclude in quick runs)
+
+---
+
+## Performance
+
+- Use **BrowserLibrary** (Playwright) for faster execution than Selenium when possible
+- Run API tests separately from UI tests (faster feedback)
+- Use `--exclude slow` for quick smoke runs
+- Consider `pabot` for parallel execution on large suites