如何在Scrum中编写质量检查策略？

Question

我想写一个Scrum团队进行质量检查时要遵循的最佳实践

本文档适用于启动组织。过去，我曾尝试搜索与启动组织有关的文档，但最终还是找到了适合大型组织或IEEE文档的文档。

Answer 1

我写了一个可能的质量检​​查策略文档，如下所示：

目标

质量检查策略文档的目的是列出团队可以遵循的最佳做法和某种形式的流程

任务声明

缺陷预防将优先于缺陷检测

质量检查的定义

质量保证是旨在确保产品满足以下要求的一系列活动 以系统，可靠的方式满足客户需求
• 产品质量优先于数量
• 在SCRUM（敏捷）中，质量保证是每个开发团队的责任 成员

积压的产品

软件开发失败的最常见原因是由于需求不明确以及团队中不同成员对需求的不同解释。

• 产品待办事项列表（PBI）将以自上而下的方式进行排序 即将进行的sprint中要处理的项目将首先显示在其中
• 用户故事将变得简单，简洁和明确
• 将按如下所述遵循INVEST模型。
  • 独立-用户故事将独立于其他故事
  • 可商议的-用户故事不会停留在固定的时间内，并且可以在产品待办事项列表中更改或丢弃。
  • 有价值-用户故事将为利益相关者带来价值
  • 可估算-用户故事的大小可以通过故事点来推导
  • 小-用户故事足够小，可以在准确度范围内计划/任务/确定优先级（良好的经验法则是，故事不会花费超过50％的迭代次数）
  • 可测试-用户故事的描述必须提供必要的信息以使测试开发成为可能
• 用户故事的格式为：作为[角色]，我想要[功能]，以便[收益]
• 每个用户故事都将包含明确定义的接受标准
• 场景（有效案例，无效案例和边缘案例）将被考虑并记录在用户故事中
• 完成用户故事后，开发团队和产品所有者必须对此进行审查
• 用户故事将被更新以包含任何更改或反馈

待办事项细化

• 在积压订单优化过程中，PO和Dev团队必须参与
• 团队中的每个人都将学习这些故事并获得清晰的了解
• 将审查屏幕设计
• 将进行可行性分析
• 每个人对故事的理解都相同
• 开发人员将很好地理解讲故事的技术细节
• 开发团队将知道如何测试故事
• 如果有的话，将在这里讨论
• 要带入下一个Sprint的项目必须与当前团队的容量相匹配
• 至少要完成当前团队能力的50％才能完成积压工作

为故事做的开发定义

• 满足故事定义的所有验收标准（将通过所有测试用例）
• 只有在定义并审核了该故事的接受标准之后，编码才会开始
• 代码构建时没有警告（技术任务）
• 必须通过100％的单元测试用例（技术任务）
• 必须通过100％的功能测试用例
• 任何故事都不得公开高优先级和高严重性的错误
• 功能分支已合并到发行/开发分支，没有任何冲突
• 准备将其部署到登台环境中以接受PO
• 将完成代码审查和必要的文档

开发指南

• 必须为所有故事编写单元测试，并结合所有验收标准和技术标准
• 必须对单元测试进行审查
• 代码质量必须由另一位开发人员审核
• 任何新代码和/或旧代码的重构都将具有适当的单元测试，这些单元测试将成为单元回归测试的一部分
• 将执行API /服务单元测试以确保组件之间的通信正常
• 功能测试用例将与代码开发同时编写并进行审查
• 仅在开发完成后才会提供测试版本
• 功能测试用例将在测试开始之前完成

质量控制准则

• 验收/健全性测试
  • 为什么：要确保满足客户的期望
  • 内容：验证故事的验收测试，功能验证
  • 何时：完成的定义已完成
  • 位置：开发版本
• UI测试
  • 为什么：要确保新功能的用户界面与样机完好无损
  • 内容：将开发功能的UI与Zeplin / Invision的模型进行比较
  • 何时：完成的定义已完成
  • 位置：开发版本
• 烟雾测试
  • 为什么：要确保关键功能按预期运行
  • 内容：仅对关键功能进行基本流程测试
  • 时间：完成验收，用户界面和探索性测试
  • 位置：临时构建
• 系统集成测试/回归测试
  • 为什么：要确保整个系统在集成时都能正常工作
  • 内容：方案测试，端到端用户流和典型的用户历程
  • 何时：验收和探索性测试完成
  • 位置：临时构建
• 非功能测试
  • 为什么：要确保非功能性方面得到照顾
  • 内容：兼容性测试，可用性测试，恢复测试
  • 时间：验收/用户界面/探索性测试完成
  • 位置：开发版本
• 中断测试
  • 为什么：要确保应用在被中断时行为正常
  • 内容：电池电量低，电池电量已满-充电时，来电或视频通话，短信接收，来自其他应用程序的警报，已插入充电，已从充电中拔出，设备关闭，应用程序更新提醒，警报网络连接丢失，网络连接恢复
  • 时间：回归测试完成后
  • 位置：临时构建