qa-skills 3.0.0 → 3.1.0

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

@@ -1,176 +0,0 @@
-# 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

@@ -1,102 +0,0 @@
-# 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

@@ -1,143 +0,0 @@
-# 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

@@ -1,161 +0,0 @@
----
-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 |