qa-skills 3.0.0

package/skills/qa-test-strategy/references/entry-exit-criteria.md

@@ -0,0 +1,176 @@
+# Entry and Exit Criteria Reference
+
+Common entry and exit criteria for different test levels. Use these checklists when defining conditions to start and complete testing in a test strategy.
+
+---
+
+## Entry Criteria (Definition of Ready)
+
+Conditions that must be met **before** testing can begin at a given level.
+
+### Unit Test Entry
+
+- [ ] Code is committed and buildable
+- [ ] Dependencies are resolvable
+- [ ] Test framework configured
+- [ ] Coverage tooling in place
+
+### Integration Test Entry
+
+- [ ] Unit tests passing
+- [ ] Services/APIs available (or mocked)
+- [ ] Test environment provisioned
+- [ ] Test data prepared
+- [ ] Database migrations applied
+
+### System/E2E Test Entry
+
+- [ ] Integration tests passing
+- [ ] Build deployed to test environment
+- [ ] Environment health checks pass
+- [ ] Test accounts and data ready
+- [ ] Smoke test suite available
+
+### UAT Entry
+
+- [ ] System testing complete (or agreed partial completion)
+- [ ] Known defects documented and accepted
+- [ ] UAT environment matches production parity (or agreed delta)
+- [ ] Business scenarios and acceptance criteria documented
+- [ ] UAT participants identified and available
+
+### Performance Test Entry
+
+- [ ] Functional tests passing
+- [ ] Performance environment sized appropriately
+- [ ] Load profiles and SLAs defined
+- [ ] Monitoring/APM configured
+- [ ] Test data volume representative
+
+### Release/Go-Live Entry
+
+- [ ] All test levels completed per exit criteria
+- [ ] Critical/high defects resolved or accepted
+- [ ] Rollback plan documented and tested
+- [ ] Sign-off from required stakeholders
+
+---
+
+## Exit Criteria (Definition of Done for Testing)
+
+Conditions that must be met **to complete** testing at a given level.
+
+### Unit Test Exit
+
+- [ ] Target coverage achieved (e.g., 70%+ for critical paths)
+- [ ] No failing unit tests
+- [ ] Linter/static analysis clean
+- [ ] Code review completed
+
+### Integration Test Exit
+
+- [ ] All integration tests passing
+- [ ] API contract tests passing
+- [ ] No critical integration defects open
+- [ ] Integration coverage report reviewed
+
+### System/E2E Test Exit
+
+- [ ] All planned E2E scenarios executed
+- [ ] Critical user journeys pass
+- [ ] No critical/high defects open (or accepted with waiver)
+- [ ] Test execution report complete
+- [ ] Regression suite run and results documented
+
+### UAT Exit
+
+- [ ] All UAT scenarios executed
+- [ ] Acceptance criteria met or explicitly waived
+- [ ] Business sign-off obtained
+- [ ] Feedback and defects logged
+- [ ] UAT report delivered
+
+### Performance Test Exit
+
+- [ ] Load tests executed per profile
+- [ ] SLAs met (response time, throughput, error rate)
+- [ ] No performance regressions vs baseline
+- [ ] Performance report with recommendations
+- [ ] Bottlenecks documented
+
+### Release/Go-Live Exit
+
+- [ ] All exit criteria for prior levels met
+- [ ] Release checklist completed
+- [ ] Stakeholder sign-off obtained
+- [ ] Deployment runbook validated
+- [ ] Post-release monitoring plan in place
+
+---
+
+## Level-Specific Checklists
+
+### Sprint/Iteration Level
+
+**Entry:**
+- [ ] Stories meet DoR (clear acceptance criteria, estimable)
+- [ ] Dev environment available
+- [ ] Test cases/automation ready for new scope
+
+**Exit:**
+- [ ] All committed stories tested
+- [ ] No critical bugs in "Done"
+- [ ] Demo completed
+- [ ] Retrospective held
+
+### Regression Level
+
+**Entry:**
+- [ ] Regression scope defined (risk-based or full)
+- [ ] Test environment stable
+- [ ] Baseline from last run available
+
+**Exit:**
+- [ ] Regression suite executed
+- [ ] Results compared to baseline
+- [ ] New failures triaged and logged
+- [ ] Regression report updated
+
+### Release Level
+
+**Entry:**
+- [ ] Release scope frozen
+- [ ] All test levels planned
+- [ ] Environments and data ready
+
+**Exit:**
+- [ ] All test levels passed per their exit criteria
+- [ ] Release notes and known issues documented
+- [ ] Go/no-go decision made
+- [ ] Sign-off obtained
+
+---
+
+## Measurable vs Subjective
+
+Prefer **measurable** criteria:
+
+| Avoid | Prefer |
+| ----- | ------ |
+| "Testing complete" | "All E2E scenarios executed; 0 critical defects open" |
+| "Quality is good" | "Pass rate ≥ 95%; no P1/P2 open" |
+| "Ready for release" | "All exit criteria met; sign-off from PM and QA lead" |
+
+---
+
+## Suspension and Resumption
+
+Document when to **suspend** testing:
+- Critical environment failure
+- Blocking defect in core flow
+- Missing test data or access
+
+Document when to **resume**:
+- Environment restored
+- Blocking defect fixed and verified
+- Access/data provided

package/skills/qa-test-strategy/references/risk-matrix.md

@@ -0,0 +1,102 @@
+# Risk Assessment Matrix Template
+
+Use this template when populating the risk assessment section of a test strategy. Covers risk categories, scoring, and mitigation strategies.
+
+---
+
+## Risk Categories
+
+| Category | Description | Examples |
+| -------- | ----------- | -------- |
+| **Technical** | Architecture, integration, performance, security, tooling | New tech stack, third-party APIs, legacy integration |
+| **Business** | Requirements, scope, stakeholders, compliance | Vague requirements, scope creep, regulatory deadlines |
+| **Process** | Team, schedule, environment, data | Resource turnover, tight timeline, env instability |
+
+---
+
+## Probability × Impact Scoring
+
+### Probability (Likelihood)
+
+| Score | Level | Description |
+| ----- | ----- | ----------- |
+| 1 | Low | Unlikely; rare occurrence |
+| 2 | Medium | Possible; has happened before |
+| 3 | High | Likely; frequent or expected |
+
+### Impact (Severity)
+
+| Score | Level | Description |
+| ----- | ----- | ----------- |
+| 1 | Low | Minor delay; workaround exists |
+| 2 | Medium | Notable impact; extra effort to fix |
+| 3 | High | Major impact; release blocker or critical defect |
+
+### Risk Score = Probability × Impact
+
+| Score | Risk Level | Action |
+| ----- | ---------- | ------ |
+| 1 | Low | Monitor; standard testing |
+| 2–4 | Medium | Mitigate; add targeted tests |
+| 6–9 | High | Actively mitigate; prioritize coverage, exploratory, early testing |
+
+---
+
+## Risk Matrix Template
+
+| ID | Risk | Category | Prob | Impact | Score | Mitigation |
+| -- | ---- | -------- | ---- | ------ | ----- | ---------- |
+| R1 | [Description] | Technical/Business/Process | 1–3 | 1–3 | P×I | [Strategy] |
+| R2 | | | | | | |
+| R3 | | | | | | |
+
+---
+
+## Mitigation Strategies by Category
+
+### Technical Risks
+
+| Risk Type | Mitigation |
+| --------- | ---------- |
+| New technology | Spike/POC; early automation; training |
+| Third-party dependency | Contract tests; mock in CI; fallback scenarios |
+| Performance | Early load testing; baseline metrics; capacity planning |
+| Security | OWASP scan; auth testing; penetration test |
+| Legacy integration | Integration tests; compatibility matrix; rollback plan |
+
+### Business Risks
+
+| Risk Type | Mitigation |
+| --------- | ---------- |
+| Vague requirements | Exploratory testing; early UAT; clarify DoR |
+| Scope creep | Change control; impact assessment; regression scope |
+| Compliance | Dedicated compliance test plan; audit trail |
+| Stakeholder availability | Async reviews; documented sign-off criteria |
+
+### Process Risks
+
+| Risk Type | Mitigation |
+| --------- | ---------- |
+| Resource turnover | Documentation; pair testing; knowledge sharing |
+| Tight timeline | Risk-based prioritization; reduce scope; parallel execution |
+| Environment instability | Dedicated env; containerization; env health checks |
+| Test data | Synthetic data; masking; refresh strategy |
+
+---
+
+## Example Risk Entries
+
+| ID | Risk | Category | P | I | Score | Mitigation |
+| -- | ---- | -------- | - | - | ----- | ---------- |
+| R1 | Third-party payment API changes without notice | Technical | 2 | 3 | 6 | Contract tests; mock in CI; monitor changelog |
+| R2 | Requirements unclear for checkout flow | Business | 3 | 2 | 6 | Exploratory sessions; early UAT; DoR checklist |
+| R3 | Single QA resource; vacation in release week | Process | 2 | 3 | 6 | Cross-train; document runbooks; automate smoke |
+
+---
+
+## Visualization
+
+Use **qa-diagram-generator** with `references/charts.md` (quadrant chart) to visualize risks:
+- X-axis: Probability
+- Y-axis: Impact
+- Quadrants: Low / Medium / High priority

package/skills/qa-test-strategy/references/testing-types.md

@@ -0,0 +1,143 @@
+# Testing Types Reference
+
+Reference for all testing types with descriptions, tools, and when to apply. Use this when selecting and justifying testing types in a test strategy.
+
+---
+
+## Functional Testing
+
+### Unit Testing
+| Attribute | Detail |
+| --------- | ------ |
+| **Description** | Tests individual units (functions, methods, classes) in isolation with mocks/stubs |
+| **Tools** | Jest, Vitest, pytest, JUnit, NUnit, xUnit |
+| **When to Apply** | All projects; highest volume in pyramid; developer-owned |
+| **Coverage Target** | 70–80% for critical paths |
+
+### Integration Testing
+| Attribute | Detail |
+| --------- | ------ |
+| **Description** | Tests interactions between components, modules, or services |
+| **Tools** | Supertest, pytest, TestContainers, WireMock |
+| **When to Apply** | API contracts, DB interactions, service-to-service calls |
+| **Coverage Target** | ~20% of test suite |
+
+### End-to-End (E2E) Testing
+| Attribute | Detail |
+| --------- | ------ |
+| **Description** | Tests full user journeys through the system from UI to backend |
+| **Tools** | Playwright, Cypress, Selenium, WebdriverIO, CodeceptJS |
+| **When to Apply** | Critical flows, smoke, release validation |
+| **Coverage Target** | ~10%; focus on happy paths and high-risk flows |
+
+### API Testing
+| Attribute | Detail |
+| --------- | ------ |
+| **Description** | Tests REST/GraphQL/gRPC endpoints for correctness, status codes, payloads |
+| **Tools** | Supertest, Postman, REST Assured, httpx, Pact |
+| **When to Apply** | API-first apps, microservices, contract validation |
+| **Coverage Target** | All public endpoints |
+
+---
+
+## Non-Functional Testing
+
+### Performance Testing
+| Attribute | Detail |
+| --------- | ------ |
+| **Description** | Load, stress, spike, endurance testing; measures response time, throughput |
+| **Tools** | k6, Locust, JMeter, Gatling, Artillery |
+| **When to Apply** | Before release; after major changes; SLA validation |
+| **Coverage Target** | Critical user paths, peak load scenarios |
+
+### Security Testing
+| Attribute | Detail |
+| --------- | ------ |
+| **Description** | Vulnerability scanning, OWASP checks, auth/authz, injection, XSS |
+| **Tools** | OWASP ZAP, Burp Suite, Snyk, npm audit, Bandit |
+| **When to Apply** | Pre-release; after auth changes; compliance requirements |
+| **Coverage Target** | Per OWASP WSTG baseline |
+
+### Accessibility Testing
+| Attribute | Detail |
+| --------- | ------ |
+| **Description** | WCAG compliance; screen reader, keyboard, contrast, ARIA |
+| **Tools** | axe-core, Pa11y, Lighthouse, WAVE |
+| **When to Apply** | Public-facing apps; regulated industries |
+| **Coverage Target** | All public pages; WCAG 2.2 AA minimum |
+
+### Visual Regression Testing
+| Attribute | Detail |
+| --------- | ------ |
+| **Description** | Pixel/screenshot comparison to detect unintended UI changes |
+| **Tools** | Playwright screenshots, Percy, Chromatic, BackstopJS |
+| **When to Apply** | UI-heavy apps; design system changes |
+| **Coverage Target** | Key pages and components |
+
+---
+
+## Specialized Testing
+
+### Contract Testing
+| Attribute | Detail |
+| --------- | ------ |
+| **Description** | Validates API contracts between consumer and provider |
+| **Tools** | Pact, Spring Cloud Contract |
+| **When to Apply** | Microservices; independent deployments |
+| **Coverage Target** | All consumer-provider pairs |
+
+### Mobile Testing
+| Attribute | Detail |
+| --------- | ------ |
+| **Description** | Native/hybrid app testing on iOS/Android; device fragmentation |
+| **Tools** | Appium, Detox, Maestro, XCTest, Espresso |
+| **When to Apply** | Mobile apps; cross-device validation |
+| **Coverage Target** | Critical flows on representative devices |
+
+---
+
+## Execution-Based Testing
+
+### Smoke Testing
+| Attribute | Detail |
+| --------- | ------ |
+| **Description** | Quick sanity check that core functionality works after deploy |
+| **Tools** | Same as E2E (Playwright, Cypress, etc.) |
+| **When to Apply** | After every deployment; CI gate |
+| **Coverage Target** | 5–15 critical paths; < 15 min |
+
+### Sanity Testing
+| Attribute | Detail |
+| --------- | ------ |
+| **Description** | Narrow, focused test of changed areas |
+| **Tools** | Manual or automated; subset of regression |
+| **When to Apply** | After hotfixes; quick validation |
+| **Coverage Target** | Changed modules only |
+
+### Regression Testing
+| Attribute | Detail |
+| --------- | ------ |
+| **Description** | Full or partial re-test to ensure no unintended breakage |
+| **Tools** | Automated suite; risk-based selection |
+| **When to Apply** | Before release; after major merges |
+| **Coverage Target** | Risk-based; high-risk + changed areas |
+
+### Exploratory Testing
+| Attribute | Detail |
+| --------- | ------ |
+| **Description** | Unscripted, session-based testing; learning and discovery |
+| **Tools** | Session sheets, heuristics, charters |
+| **When to Apply** | New features; complex flows; high-risk areas |
+| **Coverage Target** | Time-boxed sessions; charter-driven |
+
+---
+
+## Selection Matrix
+
+| Project Type | Primary Types | Secondary Types |
+| ------------ | ------------- | ---------------- |
+| Web app | Unit, Integration, E2E, API | Performance, Accessibility, Visual |
+| Mobile app | Unit, E2E (Appium), API | Performance, Security |
+| API-only | Unit, Integration, API, Contract | Performance, Security |
+| Microservices | Unit, Integration, Contract, API | Performance, Security |
+| Legacy | Smoke, Regression, Exploratory | Integration where possible |

package/skills/qa-testcase-from-docs/SKILL.md

@@ -0,0 +1,161 @@
+---
+name: qa-testcase-from-docs
+description: Generate structured test cases from requirements and specification documents using test model-based approach per ISO 29119-4.
+output_dir: test-cases/from-docs
+dependencies:
+  recommended:
+    - qa-requirements-generator
+    - qa-spec-writer
+---
+
+# QA Test Case from Docs
+
+## Purpose
+
+Generate structured test cases from Phase 1 documentation (requirements, specifications) using a test model-based approach per ISO/IEC/IEEE 29119-4. Transform requirements and specs into traceable, measurable test cases with coverage criteria.
+
+## Trigger Phrases
+
+- "Generate test cases from requirements" / "Create test cases from [spec/requirements doc]"
+- "Derive test cases from specifications"
+- "Build test model from [feature/module]"
+- "Test cases with traceability to requirements"
+- "Export test cases to Zephyr/TestRail/CSV"
+- "Coverage matrix for [requirement set]"
+- "Equivalence classes and boundary tests for [field/feature]"
+- "State transition test cases for [workflow]"
+- "Decision table tests for [business rules]"
+
+## Test Model-Based Approach (ISO 29119-4)
+
+1. **Normalize requirements** — Unify IDs, remove ambiguity, add missing acceptance criteria. Ensure each requirement is testable and uniquely identified.
+
+2. **Build test models** — Create formal models from requirements:
+   - **State models** — For workflows, lifecycles, multi-step processes
+   - **Decision tables** — For business rules, conditional logic, combinations
+   - **Equivalence classes** — For input domains (valid/invalid partitions)
+   - **Boundary values** — For numeric ranges, string lengths, limits
+
+3. **Derive test cases** — Generate test cases from models with measurable coverage:
+   - State coverage: all states, all transitions, transition pairs
+   - Decision coverage: all conditions, all branches
+   - Equivalence: at least one per partition
+   - Boundary: min, max, min-1, max+1, typical
+
+4. **Formalize tests** — Add traceability links (Requirement ID → Test Model → Test Case), assign types, priorities, and automation status.
+
+## Test Case Output Format
+
+| Field | Description |
+| ----- | ------------ |
+| **ID** | Unique identifier (e.g., TC-{module}-{number}) |
+| **Title** | Short, descriptive name |
+| **Module** | Feature/component under test |
+| **Priority** | Critical / High / Medium / Low |
+| **Type** | positive / negative / boundary / edge |
+| **Preconditions** | State, data, environment before execution |
+| **Steps** | Table: Step# \| Action \| Expected Result |
+| **Postconditions** | Expected state after execution |
+| **Test Data** | Input values, datasets, fixtures |
+| **Traceability** | Requirement ID(s) covered |
+
+### Steps Table Format
+
+| Step# | Action | Expected Result |
+| ----- | ------ | --------------- |
+| 1 | {user/system action} | {observable outcome} |
+| 2 | ... | ... |
+
+## RTM Output (Requirements Traceability Matrix)
+
+```
+Requirement ID → Test Model → Test Case(s) → Automation Status
+```
+
+| Req ID | Test Model | Test Case(s) | Automation |
+| ------ | ---------- | ------------ | ---------- |
+| REQ-FN-001 | EP: valid/invalid email | TC-LOGIN-001, TC-LOGIN-002 | Planned |
+| REQ-FN-001 | BVA: min/max length | TC-LOGIN-003, TC-LOGIN-004 | Manual |
+| REQ-FN-002 | State: login flow | TC-LOGIN-005..008 | Automated |
+
+## Auto-Categorization
+
+| Type | When to Use | Example |
+| ---- | ----------- | ------- |
+| **positive** | Valid inputs, happy path | Valid email + password → login success |
+| **negative** | Invalid inputs, error handling | Wrong password → error message |
+| **boundary** | At limits (min, max, exactly) | Password length = 8 (min) |
+| **edge** | Unusual but valid, concurrency, race | Empty optional field, simultaneous requests |
+
+## Output Formats
+
+- **Markdown tables** — Human-readable, version-control friendly
+- **JSON** — Structured, tool-agnostic, scriptable
+- **CSV** — Import into spreadsheets, bulk tools
+- **Zephyr-ready** — Structure compatible with Zephyr Scale/ Squad
+- **TestRail-ready** — Structure compatible with TestRail API/import
+
+## Workflow
+
+1. **Input:** Requirements document (from qa-requirements-generator) and/or specifications (from qa-spec-writer)
+2. **Normalize:** Unify IDs, resolve ambiguity, ensure acceptance criteria exist
+3. **Model:** Select and build test models per `references/test-design-techniques.md`
+4. **Derive:** Generate test cases with coverage criteria
+5. **Categorize:** Assign type (positive/negative/boundary/edge), priority
+6. **Format:** Output in requested format (Markdown, JSON, CSV, Zephyr, TestRail)
+7. **RTM:** Produce traceability matrix
+
+## Scope
+
+**Can do (autonomous):**
+- Generate test cases from requirements and specifications
+- Build test models (state, decision table, equivalence, boundary)
+- Derive test cases with traceability
+- Auto-categorize by type (positive/negative/boundary/edge)
+- Export to Markdown, JSON, CSV, Zephyr, TestRail formats
+- Produce RTM with requirement → model → test case links
+- Call qa-diagram-generator for state/flow diagrams
+
+**Cannot do (requires confirmation):**
+- Change requirement scope or priority
+- Add requirements not in source documents
+- Override stakeholder-defined test priorities
+
+**Will not do (out of scope):**
+- Write test automation code
+- Execute tests
+- Modify production code or environments
+
+## Embedding: Diagram Generator
+
+When visualization is needed, reference qa-diagram-generator:
+- State models → `references/state-diagram.md`
+- Decision logic → `references/flowchart.md`
+- Test flow → `references/flowchart.md`
+
+## References
+
+- `references/test-design-techniques.md` — ISO 29119-4 techniques: EP, BVA, decision tables, state transition, use case, classification trees
+- `references/test-case-format.md` — Detailed format reference with examples per test type
+
+## Quality Checklist
+
+- [ ] Every test case traces to at least one requirement ID
+- [ ] Steps are atomic and measurable (no subjective language)
+- [ ] Expected results are observable and verifiable
+- [ ] Coverage criteria stated (e.g., "all equivalence partitions")
+- [ ] Types correctly assigned (positive/negative/boundary/edge)
+- [ ] No duplicate test cases for same requirement + condition
+- [ ] RTM complete: all requirements have at least one test case
+- [ ] Preconditions and postconditions defined where relevant
+
+## Troubleshooting
+
+| Symptom | Likely Cause | Fix |
+| ------- | ------------ | --- |
+| Vague test steps | Specs lack detail | Run qa-spec-writer first, add acceptance criteria |
+| Missing negative cases | Only happy path modeled | Apply equivalence partitioning, add invalid partitions |
+| Low coverage | Few test models | Add decision tables, state models, BVA |
+| Duplicate test cases | Overlapping models | Deduplicate by (requirement, condition, expected result) |
+| Unclear traceability | Requirement IDs missing | Normalize requirements, assign IDs before modeling |
+| Export fails | Format mismatch | Check Zephyr/TestRail schema, adjust field mapping |