Stats
Actions
Tags
Help us improve
Share bugs, ideas, or general feedback.
Guides Verification (tests, reviews) vs Validation (user acceptance) for CMMI Level 3 SDLC quality. Use for test strategy, code reviews, shipping without tests, defect management.
npx claudepluginhub tachyon-beep/skillpacks --plugin axiom-sdlc-engineeringHow this skill is triggered — by the user, by Claude, or both
Slash command
/axiom-sdlc-engineering:quality-assuranceThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
This skill implements the **Verification (VER)** and **Validation (VAL)** process areas from the CMMI-based SDLC prescription.
Guides QA planning, review methods, test design, and debugging. Emphasizes combining detection techniques and achieving 5:1 dirty-to-clean test ratio.
Establishes QA processes for software projects: test strategies, Google-standard cases (AAA pattern), execution tracking, P0-P4 bug classification, OWASP security testing, quality metrics, reports, autonomous execution, and handoff templates.
Routes SDLC requests to specialist skills by detecting CMMI maturity level. Covers requirements management, design documentation, quality assurance, governance, metrics, and process adoption on projects.
Share bugs, ideas, or general feedback.
This skill implements the Verification (VER) and Validation (VAL) process areas from the CMMI-based SDLC prescription.
Core principle: Verification ≠ Validation. Tests prove you built it correctly (VER). Users prove you built the right thing (VAL). Both required at Level 3.
Critical distinction:
Reference: See docs/sdlc-prescription-cmmi-levels-2-4.md Section 3.3 for complete VER/VAL policy.
Use this skill when:
Do NOT use for:
| Situation | Primary Reference Sheet | Key Decision |
|---|---|---|
| "Skip tests to ship faster?" | Testing Practices | Level 3: Tests required before merge. Exception protocol for emergencies only. |
| "Reviews catching nothing" | Peer Reviews | Social dynamics issue, not technical. Psychological safety + reviewer accountability. |
| "Tests pass, customers unhappy" | Validation with Stakeholders | VER without VAL. Both required at Level 3. UAT process needed. |
| "Same bugs recurring" | Defect Management | Requires RCA (5 Whys, fishbone). Pattern = systemic issue needing process fix. |
| "Manual tests take 2 days" | Testing Practices | Ice cream cone anti-pattern. Migrate to test pyramid with economics. |
What: Ensuring product meets specifications and requirements
How: Testing, code review, static analysis, inspections
Who: Development team (internal)
When: Throughout development, before release
Level 3 Requirements:
Example: Unit tests pass, integration tests pass, code reviewed
What: Ensuring product meets user needs and solves actual problems
How: User acceptance testing (UAT), stakeholder demos, beta testing
Who: End users, stakeholders (external to dev team)
When: End of iteration, before production release
Level 3 Requirements:
Example: Users confirm feature solves their problem, stakeholders approve for release
| Scenario | VER | VAL | Outcome |
|---|---|---|---|
| Tests pass, users happy | ✅ | ✅ | SUCCESS - Built correctly AND right thing |
| Tests pass, users unhappy | ✅ | ❌ | FAILURE - Wrong feature, wrong UX, wrong problem solved |
| Tests fail, users would have been happy | ❌ | ✅ | FAILURE - Right idea, poor execution, bugs prevent use |
| Tests fail, users would be unhappy | ❌ | ❌ | DISASTER - Wrong thing built poorly |
Level 3 mandate: Both VER and VAL required before production release.
VER Requirements:
VAL Requirements:
Work Products:
Quality Criteria:
Audit Trail:
VER Requirements:
VAL Requirements:
Work Products:
Quality Criteria:
Audit Trail:
Statistical Practices:
Quantitative Work Products:
Quality Criteria:
Audit Trail:
CRITICAL: "Tests later" = tests never (documented historical pattern)
Level 3 projects - Absolute requirements:
Rationale: Risk too high, rework too expensive, reputation damage too severe
When: Production outage, immediate fix needed, no time for full test suite
Level 3 Requirements:
Frequency Limit: >5 TEST-HOTFIXes per month = systemic problem requiring process audit
Violation: Skipping retrospective tests = QA failure, escalate to engineering manager
If absolutely must ship without full coverage:
Retrospective required: Within 7 days, answer "Why no tests?" and address root cause
Enforcement: Violations escalate to engineering manager, process audit if patterns emerge
Detection: Tests written after code (or not at all), "We'll add tests later"
Red Flags:
Why it fails: "Later" never comes, test debt accumulates, bugs reach production, rework costs 10-100x more
Counter: TDD requirement (Level 3 can waive, but must justify). Tests = part of "done", not optional.
Detection: Code reviews <5 minutes, "LGTM" without specific feedback, defects escaping to production
Red Flags:
Why it fails: Social pressure not to block > quality, reviewers fear being "difficult", no accountability
Counter: Review metrics (finding rate should be 20-40%), reviewer accountability, psychological safety
Detection: Mostly manual E2E tests, few unit tests, regression testing takes days
Red Flags:
50% of testing time is manual
Why it fails: Doesn't scale, slow feedback, expensive to maintain, brittle tests
Counter: Test pyramid economics, migration to unit-heavy strategy, ROI calculation
Detection: Same bugs recurring in different places, no pattern analysis, firefighting constantly
Red Flags:
Why it fails: Treats symptoms not causes, waste effort on recurring issues, no learning
Counter: RCA requirement (Level 3 mandatory for recurring defects), defect pattern analysis
Detection: Stakeholders "approve" without actually using system, checkbox exercise
Red Flags:
Why it fails: False confidence, issues found in production, customer dissatisfaction
Counter:
The following reference sheets provide detailed guidance for specific QA domains. Load them on-demand when needed.
When to use: Deciding test strategy, coverage requirements, test pyramid, TDD
→ See testing-practices.md
Covers:
When to use: Code reviews ineffective, rubber-stamp approvals, unclear reviewer responsibilities
→ See peer-reviews.md
Covers:
When to use: Planning UAT, stakeholder acceptance, beta testing, demo preparation
→ See validation-with-stakeholders.md
Covers:
When to use: Bugs recurring, defect triage, root cause analysis, prevention
→ See defect-management.md
Covers:
When to use: Measuring quality effectiveness, tracking improvement, justifying QA investment
→ See qa-metrics.md
Covers:
When to use: Understanding appropriate QA rigor for project tier
→ See level-scaling.md
Covers:
| Mistake | Why It Fails | Better Approach |
|---|---|---|
| "Tests later" | Later never comes, debt accumulates | Tests = part of "done". Level 3: required before merge. |
| "Tests pass = done" | Conflates VER with VAL, skips user acceptance | Both required at Level 3. Tests AND stakeholder approval. |
| "LGTM rubber stamps" | Social pressure > quality, reviewers fear blocking | Reviewer accountability, metrics (20-40% finding rate), psychological safety. |
| "Automate everything" | Automation has costs (setup, maintenance), not always ROI-positive | Test pyramid economics. Unit tests cheap, E2E expensive. Choose wisely. |
| "Manual testing is bad" | Some testing should be manual (exploratory, one-time, usability) | Strategic automation. Critical paths automated, exploratory manual. |
| "Skip RCA, fix it quick" | Same bugs recur, waste effort whack-a-mole | Level 3: RCA required for recurring defects. Fix root cause, not symptom. |
| "Stakeholder approved" (without using system) | Validation theater, issues found in production | Hands-on UAT required. Stakeholder must actually use feature, not just demo. |
| When You're Doing | Also Use | For |
|---|---|---|
| Writing tests for Python code | axiom-python-engineering | pytest-specific patterns and idioms |
| E2E/performance/chaos testing | ordis-quality-engineering | Specialized test strategies |
| Implementing code review process | design-and-build | Code review checklist, CI integration |
| Designing acceptance criteria | requirements-lifecycle | INVEST criteria, user story format |
| Setting up CI for testing | design-and-build | CI/CD pipeline configuration |
Without this skill: Teams experience:
With this skill: Teams achieve:
Remember: Verification proves you built it correctly. Validation proves you built the right thing. You need BOTH.