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

Question

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

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

Answer 1

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

目标

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

使命宣言

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

质量检查的定义


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


产品积压

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


产品待办事项列表（PBI）将以自上而下的方式进行排序
即将进行的sprint中要完成的项目将首先出现
用户故事将变得简单，简洁和明确
如下所述，将遵循INVEST模型。


独立-用户故事将独立于其他故事
面议-用户故事不会停留在固定的时间内，并且可以随时更改或丢弃。
有价值-用户故事将为利益相关者带来价值
可估算的-用户故事的大小可以通过故事点得出
较小-用户故事将足够小，可以在准确度范围内进行计划/任务/优先级排序（良好的经验法则是，故事的迭代次数不会超过50％）
可测试的-用户故事的描述必须提供必要的信息以使测试开发成为可能

用户故事的格式为：作为[角色]，我想要[功能]，以便[收益]
每个用户案例将由明确定义的接受标准组成
场景（有效，无效和边缘情况）将被考虑并记录在用户故事中
完成用户故事后，开发团队和产品所有者必须对此进行审查
用户故事将被更新以包含任何更改或反馈


积压细化


在待办事项优化流程中，PO和Dev团队必须参与
团队中的每个人都将学习这些故事并有清晰的了解
屏幕设计将被审查
进行可行性分析
每个人都会对故事有相同的了解
开发人员将很好地理解故事中涉及的技术细节
开发团队将知道如何测试故事
障碍（如有）将在此处讨论
下一个冲刺项目必须与当前团队能力相匹配
必须完成至少50％的当前团队容量的待办事项优化


故事的发展定义


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


发展方针


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


质量控制准则


验收/健全性测试


为什么：为了确保满足客户的期望
内容：验证故事的验收测试，功能验证
时间：完成定义
在哪里：开发版本

UI测试


原因：为确保新功能的用户界面与样机完好无损
内容：将已开发功能的UI与Zeplin / Invision的模型进行比较
时间：完成定义
在哪里：开发版本

烟雾测试


为什么：为了确保关键功能按预期工作
内容：仅对关键功能进行基本流程测试
何时：验收，用户界面和探索性测试完成后
在哪里：临时构建

系统集成测试/回归测试


为什么：为了确保整个系统在集成时都能正常工作
内容：方案测试，端到端用户流和典型的用户旅程
时间：验收和探索性测试完成后
在哪里：临时构建

非功能测试


为什么：为了确保非功能性方面得到照顾
内容：兼容性测试，可用性测试，恢复测试
时间：验收/用户界面/探索性测试完成后
在哪里：开发版本

中断测试


为什么：要确保该应用在被中断时行为正常
内容：电池电量不足，电池电量已满-充电时，来电或视频通话，短信，其他应用程序的来话提醒，已插入充电项，已从充电中拔出，设备关闭，应用程序更新提醒，警报网络连接丢失，网络连接还原
时间：完成回归测试后
在哪里：临时构建