Scrum 如何使用 TFS 2012 处理测试？

Question

我们第一次尝试使用 TFS 2012 在我们的公司上实施 Scrum。到目前为止，这个过程做得不是很好，因为我们有一些问题，到目前为止还没有人能找到答案。

我们主要关心的是如何处理测试阶段。以下是或场景（就人员/工作而言）：

• 我们有6个程序员
• 我们有一个 scrum master
• 我们有 2 名测试人员（不是程序员）

这就是我们迄今为止所拥有的：

• 所有的愿望都进入董事会
• 我们召开了 sprint 会议，在会议上我们根据这些愿望添加任务
• 我们准备冲刺
• 人们开始做他们的工作

我们对完成的定义阐明，只有当故事交给测试人员并且其中一个人（在这种情况下，是我）说故事已经完成时，才能认为故事已经完成。到目前为止一切顺利。

我们有一个测试服务器，所有测试都在其中执行，该服务器类似于生产服务器（网络应用程序）。

正如我所说，主要关心的是如何处理测试：

• 由于所有开发人员都可以提交他们的代码（使用 SVN），他们应该在什么时候提交？任务何时完成或积压项目何时完成？
• 什么时候应该发布测试版本？
• 应该什么时候开始测试？我们应该在完成任务后开始测试还是在完成积压项目后开始测试？我们如何才能在开始测试时收到通知？
• 我们应该为每个积压项目创建一个部署任务和一个测试任务吗？

任何帮助都会很好。

Answer 1

- 由于所有开发人员都可以提交他们的代码（使用 SVN），他们应该何时提交？什么时候完成任务或完成积压项目？

Ans：我认为您应该在代码准备好后立即提交。如果您在用户故事下创建了任务并且任务涵盖了一些小型开发，您可以提交并关闭该任务。因此，同样明智的是，您有更小的任务来开发用户故事。完成所有任务后，用户故事（待办事项）就完成了。

要测试这些提交，您可以做的是拥有一个针对 CI 环境运行的自动化测试套件。所以你可以涵盖冒烟测试和回归测试。可以根据时间确定运行哪种类型的测试套件。例如，您可以每周运行回归测试套件，每晚运行烟雾测试套件。

- 什么时候应该发布测试版本？ - 什么时候开始测试？我们应该在完成任务后开始测试还是在完成积压项目后开始测试？我们如何才能在开始测试时收到通知？

回答：不应有严格的截止日期，例如发布测试版本。测试可以在用户故事发展的同时开始。测试人员如何提供帮助是测试人员可以对开发人员使用的代码进行“展示会话”并提供一些反馈。并在解决用户故事后开始功能测试（您可以在 tfs 中拥有此状态）。但请确保在 sprint 结束之前完成测试。

如果测试债务很高，您可以进行强化冲刺。

-我们是否应该在每个积压项目上创建一个部署任务和一个测试任务？

回答：是的，每个用户故事应该有两个不同的任务。一项任务涵盖功能测试（用户故事测试）。这对于估算和获得正确的团队速度很重要。

Answer 2

在 Scrum 中处理测试的方式并没有特定于 TFS。事实上，Scrum 在处理测试方面并没有什么特别之处！你的团队已经同意一个故事（或待办事项）完成，只有在它经过测试之后，Scrum“关心”的唯一事情就是你满足你对完成的定义.

关于您的具体问题：

• 您应该尽早并经常提交更改。您提交的越多，您就越容易与团队的其他成员交流更改，并且在发生灾难时（您搞砸了代码，或者您的硬盘驱动器出现故障） - 您就越容易恢复。根据我的经验，最好在您的代码稳定且安全足以添加到存储库时提交。这应该在您完成任务时至少完成
• 您应该尽早并经常发布（在这里看到一个反复出现的主题？）。这意味着只要您的产品有一个有价值的增量，并且它稳定和安全足以暴露给您团队之外的利益相关者。在您的第一个版本之后，您应该能够在完成一个积压项目时执行此操作 - 每个 Minimally Viable Product 增量。
• 您应该测试 - 你猜到了 - 尽早并经常。这意味着，只要对您的产品所做的更改足以进行测试。对于开发人员单元测试，这意味着几乎每次您添加一个场景（如果您正在进行测试驱动开发）。对于“QA”测试，应该尽早完成 - 只要完成了任务，如果您可以管理它。事实上，如果有必要，您可能希望重新考虑如何将积压项目分解为任务，以提高任务的可测试性。例如，如果您通过 组件 或 代码层 来分解任务，则不可能在整个故事代码完成之前测试代码。另一方面，如果您按用例或场景分解积压项目，您将能够每当您完成一项任务时进行测试 - 开发人员将在完成任务后立即获得他们的反馈！
• 如果您需要部署每个积压项目（并且您确实这样做了），则应考虑所涉及的工作。如果每个部署都略有不同（一个故事可能需要发布到网络上，另一个故事可能意味着将应用程序上传到移动应用商店），以一种不平凡和不明显的方式，那么你应该有一个任务它，解释如何部署。但是，如果每个部署任务的标题看起来像“deploy”并且估计值相同，那么您应该考虑不浪费您的时间，并简单地向积压项目的工作流程添加一个状态（例如：待办事项 --> 进行中 --> 测试 --> 部署 --> 完成）

Answer 3

总体而言，Scrum 不会为您提供可遵循的流程。它只提供了一个框架，您可以在其中凭经验对您的流程进行试验，以找到最适合您的团队的方法。

由于所有开发人员都可以提交他们的代码（使用 SVN），他们应该在什么时候提交？任务何时完成或积压项目何时完成？ 你能在不提交的情况下实现一个集成的、完成的增量吗？如果没有，请在有意义的时候提交。选择一个并谈论它的影响。当您批量处理所有更改直到积压项目“完成”时会发生什么？可以在不提交的情况下完成积压项目吗？

什么时候应该发布测试版本？ 当产品负责人认为他们有足够的价值可以运送或有运送价值时。您在 sprint 中创建的增量应该是可发布的。

也许您在问能否在冲刺中期发货。当然！将其视为在 Scrum 框架内执行的另一个经验实验。您可以尝试这个实验并根据经验检查结果。

应该什么时候开始测试？我们应该在完成任务后开始测试还是在完成积压项目后开始测试？ 再次，选择一个并使用 Scrum 来检查影响。作为建议，不要等待太久。尝试让自己处于并行构建测试/测试用例的位置。在这些技能之间进行协作。

我们如何在开始测试时收到通知？ 您有 6 名开发团队成员。问对方。电子邮件，Skype，转过头，站起来走过去。也许你可以把 Daily Scrum 当作plan the day的地方@

我们应该为每个积压项目创建一个部署任务和一个测试任务吗？ 同样，有些团队这样做。如果这对您有帮助 a) 了解剩余的工作 b) 执行您的流程，然后尝试一下。也许“可通过 xyz 脚本部署”是正在制定的完成项目的新定义。