如何将QA融入Sprint中

Question

Scrum中的一个挑战是如何将QA融入到该过程中。当然，在Sprint期间，QA会与开发人员一起处理每个单独的用户故事，但在发布到生产环境之前，让QA有时间进行完整的回归和负载测试呢？

我看到了两种方法:

1. 在Sprint的最后一天发布到生产环境; 或者
2. 在Sprint结束后一周发布到生产环境

这两种方法都存在着挑战，所以我想知道大多数公司在每个Sprint发布时都做些什么？

- ToddH

---

我投票关闭此问题，因为它与编程无关。 - Vadim Kotov

Answer 1

这两种方法都有挑战，所以我想知道在每个Sprint发布新版本的大部分公司采用哪种方法？

我认为，Scrum 的最终目标是能够在 Sprint 结束后发布一个新版本增量。换句话说，Sprint 的结果是一个可发布的增量（而不是已发布的增量）。

因此，选项＃1 对我来说有点太早了（我们的产品待办事项是在 Sprint 结束之前完成的，但在演示之前，我们不包括“发布到生产环境”在我们的完成定义中，因为这不是我们控制的范围，这是另一个团队的工作）。

而且，我认为选项＃2 意味着您没有在“DONE DONE”中包含完成所有必需步骤所必需的所有内容。我绝对不是说这很容易做到，并且很可能需要一些时间才能真正包括达到可发布状态的所有必需步骤，并进行必要的组织变更以实现目标。

就我个人而言，我仍然没有真正达到这种流畅的水平（在每个 Sprint 发布），虽然 QA 的一部分确实是在每个 Sprint（IST、UAT）期间完成的，但我们实际上是每 4 个 2 周的 Sprint 才发布一次，最后一个 Sprint 是一种特殊的发布 Sprint，其中包括“特殊”的产品待办事项，例如执行负载测试、如有必要进行优化（尽管现在没有太多坏惊喜）、编写文档（供生产团队和用户使用）。缩短发布周期需要进行更深入的变革，目前无法实现，在我们的情况下也不希望实现。当然，您的情况可能不同。

另请参阅

• Sprint 期间QA的陷阱？

相关问题：

• 如何在敏捷（Scrum+XP）团队中进行QA/测试的最佳实践？
• 帮我理解QA如何在Scrum中运作
• 将缺陷修复融入Scrum流程的最佳方法是什么？

- Pascal Thivent

---

不错的回答（+1）。你知道这本书http://www.amazon.com/Succeeding-Agile-Software-Development-Using/dp/0321579364/ref=sr_1_1?s=books&ie=UTF8&qid=1283060678&sr=1-1好不好？ - Arthur Ronald

@Arthur 谢谢。关于Mike Cohn的新书，我没有读过它（我读过他的两本书，但不是这一本），但我毫不怀疑它是一本好书。我会毫不犹豫地推荐它。 - Pascal Thivent

@Arthur - 是的，那本书相当不错。 - Don Roby

我也推荐阅读Mike Cohn的书。他非常实用，不怕提出（并回答）你对敏捷实践可能有的所有异议。 - Franco

Answer 2

这取决于行业、市场和其他因素。没有单一的答案。请记住，Scrum是框架，它并不适用于所有情况。我看到最多的是解决方案＃1。

在冲刺结束时，您应该拥有一个可能发布的产品版本。这对小型创业公司或小公司非常有效。这是他们的竞争优势之一。可以轻松地将QA人员放入团队中。当软件不重要（解决方案＃2）时，在大型公司可以实现这一点。

我曾在一个安全性至关重要的大型企业中实施Scrum。由于法规和认证限制，冲刺后发布是不可能的。你必须经过漫长的发布过程，开发人员必须参与其中。我们不得不应对这一点。

但是，在大多数软件工厂中，他们可以在演示后几乎只需单击即可发布。使这成为可能时，您获得了迭代开发的全部力量，这是一个非常大的竞争优势。

从商业角度来看，每次迭代结束时不发布是一个好的实践。

- user333306

Answer 3

如果我可以谦虚地假设您在软件行业，那么您的问题的答案或解决方案将是使用企业Scrum模型，具有坚实的项目发布计划和项目时间表。

应该有一个运营支持Scrum团队，其中可能包括DB管理员、应用服务器管理员、高级QA人员和高级生产支持分析师。这个团队可能负责开发Scrum团队的完整QA回归和负载测试、发布管理、代码部署和其他运营支持活动。另一方面，开发Scrum团队只需生成可发布的软件并将其放在操作支持团队的架子上。

在您的特定情况下，操作支持团队将在其产品待办事项列表中拥有回归测试和负载测试活动，以执行由开发团队制作的存储产品的任务 - 请注意，回归测试理想情况下应该是开发过程的一部分！

现在，每个Sprint都发布的组织需要使操作团队落后于开发团队一两周，因此例如，如果Scrum开发团队正在处理Release 2.0代码，则操作支持团队应该部署Release 1.0代码，而开发团队在2周前完成了“搁置”。

底线是需要制定正确的时间表来规划发布计划。在Scrum中，可能存在这样的误解，认为每个Scrum团队都有自己的发布计划，因为它们是自我管理的，会执行自己的部署等等，这在某种程度上是正确的，但团队的计划还需要与项目范围内的发布计划相适应，并相应地安排时间表。

协调时间表和按照项目时间表组织待办事项的责任主要落在PO和SM的肩膀上，后者负责培训PO如何最有效地使其工作。因此，简单的答案是=开发团队和运营团队进行QA或发布活动之间有2周的间隔很好，但时间表和间隔应根据项目需求进行调整。

如果您需要更多详细信息，请提问。一次讨论将更容易解释，但我希望这回答了您的问题。顺便说一句，我认为在开发团队的Sprint结束后的第二天发布（到生产环境）是一个坏主意，但您可以尝试并进行检查和适应；1周足够，但这取决于您的应用程序有多大，数据有多大，以及您拥有多少资源。

谢谢，Sid Telang。认证Scrum Master

- sjt

Answer 4

我的理解是，在Sprint结束时完成工作非常重要，不能将“技术债务”留到另一个Sprint，否则人们可能不得不重新制作以前发布的软件。

- Franco