0

我正在阅读Scrum and XP from the Trenches这本书的中间，阅读我们如何进行测试一章，特别是关于验收测试阶段（我将其称为ATP）。作者建议一种方法：

方法 2：“可以开始构建新内容，但优先考虑将旧内容投入生产”</p>

但是（在我看来，或者我没有得到任何东西）这种方法根本不涉及 ATP。有一个冲刺，然后是另一个，但是 ATP 在哪里。或者在作者看来，第一个 sprint 中包含 ATP。如果是这样，那么它是如何引用语句形式的子章验收测试是否应该成为 sprint 的一部分？前几页：

我们在这里摇摆不定。我们的一些团队在 sprint 中包括验收测试。然而，我们的大多数团队都没有这样做，原因有两个： 冲刺是有时间限制的。验收测试（使用我的定义，包括调试和重新发布）很难进行时间限制。如果时间用完而您仍然有一个严重的错误怎么办？您是否要发布具有严重错误的生产？你要等到下一个冲刺吗？在大多数情况下，这两种解决方案都是不可接受的。因此，我们将手动验收测试留在外面。如果您有多个 Scrum 团队在同一产品上工作，则必须对两个团队工作的综合结果进行手动验收测试。如果两个团队都在 sprint 中手动接受，你仍然需要一个团队来测试最终版本，

所以伙计们，（这是问题）：你如何理解那一章？

除此之外，这是我的想法：作者提到由于严重的错误问题，ATP 不应该成为 Sprint 的一部分？好吧，如果没有 ATP，我们就不能在 sprint 中遇到这样的问题吗？我们可以。无论哪种方式（我们在 Sptint 中是否有 ATP）我们都遇到了麻烦。底线：如果 Sprint 时间盒足够长（也许这是作者在方法 2中的想法），它也可以处理 ATP。它将消除发布后到达的大量错误。

谢谢，帕维尔

PS你知道任何页面有变化与书的作者积极聊天吗？

PS 2 在发布之前阅读我的问题时，我只是开悟了：也许是这样说：

方法 2：“可以开始构建新内容，但优先考虑将旧内容投入生产”</p>

作者：Sprint 1 完成，代码库（版本 1.0.0）进入 ATP。同时，我们正在为 1.1.0 版本启动 Sprint 2，同时修复 1.0.0 版本中发现的错误。当 Sprint 1 期间准备的代码库一尘不染时，它就会上线。所以在这里，我们有一些重叠之王。但是，如果这是作者的意图（我敢肯定不是），那么它就违反了基本原则：

  1. sprint 新软件可用后（不是因为我们等待 ATP 结束）
  2. 如果我们将 sprint 视为 sprint+ATP :)，那么 sprint 没有时间限制。

总而言之，那本书读起来很棒，但是那一章对我来说有点模糊（我在那次阅读中也学到了一个很酷的词）。

4

2 回答 2

1

验收测试与构建软件几乎没有关系。

您可以尽可能快地构建。

用户接受某些功能（或拒绝某些功能）。

您不会通过验收测试找到“关键错误”。该软件已经可以使用。用户只是不喜欢它的工作方式。这不是一个错误。这是一个错误的沟通，将在下一个 sprint 中解决。

您可以（通过一些调整）部署 Accepted 软件，它是测试软件的子集。人们一直这样做。

我们经常隐藏功能、页面、按钮、屏幕等，因为它们不被接受。他们通过了单元测试。他们工作。但由于某种原因，他们没有被接受。所以他们没有被部署。

通常，用户的原始定义是错误的，需要修复单元测试，以便在下一个版本中修复和部署代码。

一个特性的接受与它是否工作以及它被内置在哪个冲刺中无关。如果它是一个完整的平滑包可能会很好。但是，它通常不是一个平滑的包。这就是为什么我们必须敏捷。

于 2011-06-20T21:00:20.403 回答
0

IMO 在 sprint 验收标准开始时应该众所周知并针对每个用户故事进行修复。为了能够在 sprint 评审中将故事标记为“完成”，验收测试必须成功。因此，IMO ATP 属于冲刺！

我想参考 Mike Cohn 的“敏捷估计和规划”。他提倡在用户故事便利贴上写下验收标准。它们是 sprint 评审中批准的依据。从这个陈述中，我得出了在冲刺中拥有 ATP 的必要性！

不断变化的需求或验收标准会产生新的用户故事。但是你永远不会改变正在进行的那些。

如果验收测试要自动化，这项工作可以在冲刺期间完成。但是基本标准应该在冲刺开始时就已经确定了。

于 2011-07-06T13:27:56.027 回答