Back to Details

quality-assurance

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Quality Assurance

质量保证

Ensure quality throughout the spec-driven development process with validation techniques, quality gates, and testing strategies.
在规范驱动开发的全流程中，通过验证技术、质量门以及测试策略确保交付质量。

When to Use This Skill

何时使用该Skill

Use quality assurance practices when:
  • Completing any spec phase (requirements, design, tasks)
  • Transitioning between phases
  • Implementing features from specs
  • Reviewing completed work
  • Establishing team quality standards
在以下场景中使用质量保证实践：
  • 完成任一规范阶段（需求、设计、任务）
  • 阶段间过渡时
  • 基于规范实现功能时
  • 评审已完成工作时
  • 制定团队质量标准时

Core Principles

核心原则

  1. Requirements-Driven Testing: Every test traces to a requirement
  2. Phase-Appropriate Validation: Different techniques for each phase
  3. Continuous Quality: Checks throughout development
  4. Automated Where Possible: Reduce manual effort
  5. Fast Feedback: Catch issues early
  1. Requirements-Driven Testing: 每一项测试都可追溯至某一需求
  2. Phase-Appropriate Validation: 针对不同阶段采用适配的验证技术
  3. Continuous Quality: 在开发全程持续进行质量检查
  4. Automated Where Possible: 尽可能自动化以减少人工投入
  5. Fast Feedback: 尽早发现问题并反馈

Phase-Specific Validation

分阶段验证

Requirements Phase Validation

需求阶段验证

Quality Checklist:
  • All user stories have acceptance criteria
  • Requirements are unambiguous and specific
  • Each requirement can be validated/tested
  • EARS format used consistently
  • Requirements link to business objectives
  • No conflicting requirements
Review Process:
  1. Self Review: Author checks completeness
  2. Stakeholder Review: Business validates requirements
  3. Technical Review: Team assesses feasibility
  4. Approval: Formal sign-off before design
Validation Techniques:
  • Scenario Walkthroughs: Step through user journeys
  • Edge Case Analysis: Identify boundary conditions
  • Conflict Detection: Check for contradictions
  • Completeness Analysis: Ensure all needs covered
质量检查清单：
  • 所有用户故事均包含验收准则
  • 需求表述清晰、无歧义
  • 每一项需求均可被验证/测试
  • 统一使用EARS格式
  • 需求与业务目标相关联
  • 无冲突需求
评审流程：
  1. 自审： 作者检查需求完整性
  2. 干系人评审： 业务方验证需求合理性
  3. 技术评审： 团队评估需求可行性
  4. 批准： 进入设计阶段前获得正式签署同意
验证技术：
  • 场景走查： 逐步梳理用户旅程
  • 边缘用例分析： 识别边界条件
  • 冲突检测： 检查需求间的矛盾点
  • 完整性分析： 确保所有需求均被覆盖

Design Phase Validation

设计阶段验证

Quality Checklist:
  • Design addresses all requirements
  • Scalability considerations documented
  • Maintainability assessed
  • Security addressed
  • Performance requirements considered
  • External integrations defined
Review Process:
  1. Architecture Review: Senior team validates design
  2. Security Review: Security implications assessed
  3. Performance Review: Performance characteristics evaluated
  4. Integration Review: External dependencies validated
Validation Techniques:
  • Design Walkthroughs: Step through system interactions
  • Threat Modeling: Identify security vulnerabilities
  • Performance Modeling: Estimate system performance
  • Dependency Analysis: Map external requirements
质量检查清单：
  • 设计方案覆盖所有需求
  • 已记录可扩展性考量
  • 已评估可维护性
  • 已考虑安全因素
  • 已纳入性能需求
  • 已定义外部集成方案
评审流程：
  1. 架构评审： 资深团队成员验证设计合理性
  2. 安全评审： 评估安全影响
  3. 性能评审： 评估系统性能特征
  4. 集成评审： 验证外部依赖项
验证技术：
  • 设计走查： 逐步梳理系统交互逻辑
  • 威胁建模： 识别安全漏洞
  • 性能建模： 预估系统性能
  • 依赖分析： 梳理外部需求

Tasks Phase Validation

任务阶段验证

Quality Checklist:
  • Each task has clear deliverables
  • Task sequence is logical
  • All design elements covered
  • Each task can be validated
  • Tasks appropriately sized (2-4 hours)
  • Dependencies clearly defined
Review Process:
  1. Completeness Review: All design elements have tasks
  2. Sequencing Review: Task order is logical
  3. Scope Review: Tasks are appropriately sized
  4. Dependency Review: Dependencies clear
质量检查清单：
  • 每一项任务均有明确交付物
  • 任务顺序逻辑合理
  • 所有设计元素均被覆盖
  • 每一项任务均可被验证
  • 任务规模适中（2-4小时）
  • 依赖关系定义清晰
评审流程：
  1. 完整性评审： 所有设计元素均对应任务
  2. 顺序评审： 任务顺序逻辑合理
  3. 范围评审： 任务规模适中
  4. 依赖评审： 依赖关系清晰

Quality Gates

质量门

Requirements Phase Exit Criteria

需求阶段退出准则

  • All user stories follow proper format
  • Acceptance criteria use EARS format
  • Requirements are testable and measurable
  • No conflicting requirements
  • Stakeholders have approved
  • Edge cases documented
  • 所有用户故事格式规范
  • 验收准则使用EARS格式
  • 需求可测试、可衡量
  • 无冲突需求
  • 已获得干系人批准
  • 边缘用例已记录

Design Phase Exit Criteria

设计阶段退出准则

  • Architecture addresses all requirements
  • Non-functional requirements addressed
  • External dependencies identified
  • Data models clearly defined
  • Error handling documented
  • Security considerations addressed
  • Technical review completed
  • 架构方案覆盖所有需求
  • 已处理非功能性需求
  • 已识别外部依赖项
  • 数据模型定义清晰
  • 已记录错误处理方案
  • 已考虑安全因素
  • 已完成技术评审

Tasks Phase Exit Criteria

任务阶段退出准则

  • All design elements have tasks
  • Tasks properly sequenced
  • Each task is actionable
  • Requirements references included
  • Test approach defined
  • Task breakdown reviewed
  • 所有设计元素均对应任务
  • 任务顺序合理
  • 每一项任务均可执行
  • 已关联需求参考
  • 已定义测试方法
  • 已完成任务拆分评审

Task-Level Quality Gates

任务级质量门

Before Starting:
  • Task requirements understood
  • Test strategy defined
  • Dependencies available
  • Environment ready
During Implementation:
  • Code follows standards
  • Tests written alongside code
  • Coverage meets thresholds (80%+)
  • No critical vulnerabilities
Before Marking Complete:
  • All tests pass
  • Code review completed
  • Documentation updated
  • Requirements validated
开始前：
  • 已理解任务需求
  • 已定义测试策略
  • 依赖项已就绪
  • 环境已准备完成
实现过程中：
  • 代码符合规范
  • 代码编写与测试编写同步进行
  • 覆盖率达标（80%+）
  • 无严重漏洞
标记完成前：
  • 所有测试通过
  • 已完成代码评审
  • 文档已更新
  • 需求已验证

Testing Strategies

测试策略

Test Pyramid

测试金字塔

       /\
      /  \     E2E Tests (10%)
     /____\    Integration Tests (20%)
    /      \
   /________\   Unit Tests (70%)
       /\
      /  \     E2E Tests (10%)
     /____\    Integration Tests (20%)
    /      \
   /________\   Unit Tests (70%)

Unit Testing

Unit Testing

  • Fast execution (< 1 second per test)
  • Test individual functions/classes
  • Mock external dependencies
  • Target 80%+ coverage
  • 执行速度快（每个测试耗时<1秒）
  • 测试独立的函数/类
  • 模拟外部依赖项
  • 目标覆盖率80%+

Integration Testing

Integration Testing

  • Test component interactions
  • Use real dependencies where practical
  • Validate API contracts
  • Test critical workflows
  • 测试组件间交互
  • 尽可能使用真实依赖项
  • 验证API契约
  • 测试关键工作流

End-to-End Testing

End-to-End Testing

  • Test complete user journeys
  • Production-like environment
  • Focus on critical business flows
  • Minimal but comprehensive
  • 测试完整用户旅程
  • 类生产环境
  • 聚焦核心业务流程
  • 精简但全面

Test-Driven Development

Test-Driven Development

For each task:
  1. Write tests first based on acceptance criteria
  2. Run tests - verify they fail (red)
  3. Write code - minimal to pass tests (green)
  4. Refactor - improve while keeping tests green
  5. Validate - ensure requirements satisfied
针对每项任务：
  1. 先编写测试：基于验收准则编写测试用例
  2. 运行测试：确认测试失败（红态）
  3. 编写代码：编写最少代码使测试通过（绿态）
  4. 重构：在保持测试通过的前提下优化代码
  5. 验证：确认需求已被满足

Quality Metrics

质量指标

Code Quality

代码质量

  • Line Coverage: % of code lines executed
  • Branch Coverage: % of code branches tested
  • Cyclomatic Complexity: Code complexity
  • Technical Debt: Accumulated issues
  • Line Coverage： 被执行的代码行占比
  • Branch Coverage： 被测试的代码分支占比
  • Cyclomatic Complexity： 代码复杂度
  • Technical Debt： 累积的技术债务

Testing Effectiveness

测试有效性

  • Test Pass Rate: % of tests passing
  • Execution Time: Time to run tests
  • Defect Detection Rate: Bugs found by tests vs production
  • Test Maintenance: Time spent maintaining tests
  • Test Pass Rate： 测试通过率
  • Execution Time： 测试执行耗时
  • Defect Detection Rate： 测试发现的缺陷与生产环境缺陷的占比
  • Test Maintenance： 维护测试所需时间

Common Quality Issues

常见质量问题

Flaky Tests

不稳定测试（Flaky Tests）

Symptoms: Tests pass/fail inconsistently Solutions:
  • Identify timing dependencies
  • Use proper wait conditions
  • Isolate test data
  • Fix race conditions
症状： 测试结果不稳定，时而通过时而失败 解决方案：
  • 识别时序依赖
  • 使用合适的等待条件
  • 隔离测试数据
  • 修复竞态条件

Slow Test Suites

测试套件运行缓慢

Symptoms: Tests take too long Solutions:
  • Parallelize execution
  • Optimize database operations
  • Use test doubles for external services
  • Profile and optimize slow tests
症状： 测试执行耗时过长 解决方案：
  • 并行执行测试
  • 优化数据库操作
  • 为外部服务使用测试替身
  • 分析并优化慢测试

Low Coverage

覆盖率低

Symptoms: Insufficient code coverage Solutions:
  • Add tests for uncovered paths
  • Focus on critical business logic
  • Use mutation testing
  • Set coverage gates in CI
症状： 代码覆盖率不足 解决方案：
  • 为未覆盖路径添加测试
  • 聚焦核心业务逻辑
  • 使用突变测试
  • 在CI中设置覆盖率门控

Test Maintenance Burden

测试维护成本高

Symptoms: Tests require frequent updates Solutions:
  • Improve test design
  • Use page object patterns for UI
  • Reduce coupling to implementation
  • Regular test refactoring
症状： 测试需要频繁更新 解决方案：
  • 优化测试设计
  • 对UI测试使用页面对象模式
  • 降低与实现细节的耦合
  • 定期重构测试

Validation Checklists

验证检查清单

Requirements Validation

需求验证

markdown
undefined
markdown
undefined

Requirements Review

Requirements Review

Completeness:
  • All user roles addressed
  • Happy path scenarios covered
  • Edge cases documented
  • Error cases handled
  • Business rules captured
Clarity:
  • Precise language used
  • No ambiguous terms
  • Technical jargon avoided
  • Behaviors are specific
Testability:
  • Each requirement verifiable
  • Success criteria observable
  • Inputs/outputs specified
undefined
Completeness:
  • All user roles addressed
  • Happy path scenarios covered
  • Edge cases documented
  • Error cases handled
  • Business rules captured
Clarity:
  • Precise language used
  • No ambiguous terms
  • Technical jargon avoided
  • Behaviors are specific
Testability:
  • Each requirement verifiable
  • Success criteria observable
  • Inputs/outputs specified
undefined

Design Validation

设计验证

markdown
undefined
markdown
undefined

Design Review

Design Review

Architecture:
  • Requirements addressed
  • Components well-defined
  • Interfaces specified
  • Data flow documented
Quality Attributes:
  • Performance considered
  • Security addressed
  • Scalability planned
  • Maintainability assessed
Risks:
  • Single points of failure identified
  • Bottlenecks documented
  • Mitigations planned
undefined
Architecture:
  • Requirements addressed
  • Components well-defined
  • Interfaces specified
  • Data flow documented
Quality Attributes:
  • Performance considered
  • Security addressed
  • Scalability planned
  • Maintainability assessed
Risks:
  • Single points of failure identified
  • Bottlenecks documented
  • Mitigations planned
undefined

Implementation Validation

实现验证

markdown
undefined
markdown
undefined

Implementation Review

Implementation Review

Code Quality:
  • Follows standards
  • Well-documented
  • Tests included
  • No security issues
Requirements:
  • All criteria met
  • Edge cases handled
  • Error handling complete
Integration:
  • Works with existing code
  • APIs functioning
  • Performance acceptable
undefined
Code Quality:
  • Follows standards
  • Well-documented
  • Tests included
  • No security issues
Requirements:
  • All criteria met
  • Edge cases handled
  • Error handling complete
Integration:
  • Works with existing code
  • APIs functioning
  • Performance acceptable
undefined

Best Practices

最佳实践

Testing Best Practices

测试最佳实践

  1. Write tests first when possible
  2. Each test verifies one thing
  3. Use descriptive test names
  4. Maintain test independence
  5. Keep tests up-to-date
  1. 尽可能先编写测试
  2. 每项测试仅验证一个点
  3. 使用描述性的测试名称
  4. 保持测试独立性
  5. 及时更新测试

Quality Assurance Best Practices

质量保证最佳实践

  1. Find issues early (shift left)
  2. Automate everything possible
  3. Use metrics to drive improvements
  4. Make quality everyone's responsibility
  5. Continuous learning and improvement
  1. 尽早发现问题（左移测试）
  2. 尽可能自动化所有可自动化的内容
  3. 用指标驱动改进
  4. 让质量成为每个人的责任
  5. 持续学习与改进

Process Integration

流程集成

  1. Link tests to requirements
  2. Provide quick feedback
  3. Focus testing on high-risk areas
  4. Keep documentation current
  5. Integrate tools with workflow
  1. 将测试与需求关联
  2. 提供快速反馈
  3. 聚焦高风险区域的测试
  4. 保持文档更新
  5. 将工具与工作流集成

Quick Reference

快速参考

Phase Transition Questions:
  • Requirements → Design: "Does design address all requirements?"
  • Design → Tasks: "Do tasks cover all design elements?"
  • Tasks → Implementation: "Does code satisfy task specifications?"
Quality Gate Questions:
  • "Is this testable and measurable?"
  • "Have we considered what could go wrong?"
  • "Would another developer understand this?"
  • "Does this meet our standards?"
阶段过渡问题：
  • 需求 → 设计：“设计方案是否覆盖所有需求？”
  • 设计 → 任务：“任务是否覆盖所有设计元素？”
  • 任务 → 实现：“代码是否满足任务规范？”
质量门问题：
  • “该项是否可测试、可衡量？”
  • “我们是否考虑了可能出现的问题？”
  • “其他开发者是否能理解该项内容？”
  • “该项是否符合我们的标准？”