从开始到结束测试更改的完整scrum流程是什么？

Question

我需要完整的开始到结束的scrum过程来测试一个更改。从从产品积压中获取bug/增强、获得BRD/FSD、编写测试scenarios......to........logging bug到Jira或任何结束的东西。

Answer 1

Scrum没有定义任何用于测试的过程，它更多地是关于一个通用的迭代软件开发工作流，并描述了通信点和人工。

sprint的循环是团队提交一定数量的故事，并在他们的sprint结束时。这些故事应该会遇到团队已完成的定义。这应该包括测试实践，但是团队应该想出他们需要带来的最高质量来创造并让他们的利益相关者高兴。我将从最简单的DoD开始，并在遇到问题时添加步骤。

在将测试过程定义到DoD中时，要记住一些事情：

• 尽量避免小瀑布，不要计划在冲刺或任务结束时进行测试。阅读这篇文章：http://www.agilecoachjournal.com/index.php/2014-02-03/scrum/a-sprint-is-not-a-2-week-waterfall/
• 介绍XP实践，如TDD，并确保每个故事都有自动测试覆盖率：http://en.wikipedia.org/wiki/Extreme_编程_practices#Test_驱动型_开发。
• 少就是多，不要在敏捷工作流中引入完整的流程，除非它是绝对必要的。确保您有一个持续改进过程，并且有一个团队工作流的自然发展，重点是更好的质量。
• 修复sprint中在sprint中创建的缺陷，并确保产品在任何时候都处于可发布状态。
• 阅读“敏捷测试：http://agiletester.ca/”一书

处理缺陷是一个更复杂的主题，可以以不同的方式处理：

1. 保持零错误政策。在下一个sprint中，首先修复所有的缺陷，从中学习并相应地降低团队速度。
2. 计划缺陷就像其他故事一样，因为缺陷和任何其他特性一样只是变化，为什么要以不同的方式处理它们呢？

记住，并非所有的缺陷都是平等的。有些可能会降低客户满意度，而另一些则可能被一些客户用作功能。确保以与特性相同的方式排列缺陷的优先级。这就是为什么我更喜欢数字2而不是数字1，但不要让你的错误列表失控。

Answer 2

你想要的是一本充满知识的书。这是一个来自国际Scrum研究所的真实世界的例子，让它滚滚而来。

此外，在其他堆栈站点中，这个问题也是被问到。