2

我们与 Scrum 合作，我认为我们走在正确的道路上，但有一件事困扰着我：测试人员还不是开发周期的一部分。现在我正在考虑如何让测试人员参与开发团队。现在它是分开的，测试人员有他们“自己的”冲刺。

目前我们有一个CI环境。每次开发人员完成用户故事时，他都会签入他的代码，并且构建服务器会在每次签入时构建代码。

我想要的是测试人员在实现用户故事的同一冲刺中测试用户故事。但我正在努力解决如何设置它。

我的主要问题是：测试人员可以在哪里测试用户故事？他们不能在构建服务器上进行测试，因为在每次签入时它都会创建一个新构建并且有很多签入。所以这不是一个选择。那么，我应该创建一个单独的服务器，供测试人员自行部署吗？或者..

我的问题是，你们是如何设置的？您如何将测试人员集成到开发过程中？

4

5 回答 5

2

您需要一个登台服务器并每隔一段时间部署一次构建。我们就是这样做的：CI->Dev->Staging->Live

编辑：我总是觉得发布维基链接的混蛋，但这篇关于多阶段 CI 的文章很好：http ://en.m.wikipedia.org/wiki/Multi-stage_continuous_integration

于 2012-12-18T08:16:53.050 回答
2

在我目前的项目中，我们有 4 个小团队，每个团队分配了 1 名测试人员。测试人员是日常站立会议、冲刺计划会议等的一部分。测试人员也有自己的日常站立会议，以便他们进行协调等。

在 Sprint 计划会议 2 期间，我们一起（测试人员、开发人员和 PO）创建验收标准/示例/测试用例（无论您想如何称呼它）。目的是建立对用户故事的共同理解，获得正确的方向并将其拆分为更小的功能（场景/测试用例），例如只是一条特定的快乐路径。因此，我们能够提供比测试人员测试的更小的工作特性。同时可以实现用户故事的下一部分。此外，还决定了哪些故事需要自动化验收测试以及哪个级别（单元、集成、gui 测试）最有意义。

正如 OakNinja 已经提到的 :) 您将需要至少一个额外的环境供测试人员使用。在我们的案例中，这些环境不是质量门，而是开发阶段。因此，每当开发人员完成某些功能时，他都会告诉测试人员，如果他愿意，他可以重新部署。

如果用户故事完成，它将被部署在登台服务器上，在那里接受用户故事。

部署过程：

Dev + Test => Staging（用于验收）=> Demo（用于每 2 周演示用户故事）=> SIT 和 End2End 测试环境（每 2 周部署）=> 生产（大约部署 6 个月）

于 2012-12-18T09:45:19.453 回答
2

我们在整个 sprint 中都有 QA 资源：估计、计划等。当开发人员第一次开始编码时，团队的 QA 成员开始创建测试用例。当代码被签入时，它会按计划（或根据需要）部署到单独的环境中，以便 QA 可以在冲刺期间执行他们的测试。在故事大部分完成后，QA 也会参与回归。

我们的设置使用 TFS 或 TeamCity 中的构建配置自动部署，具体取决于项目。我们的环境是这样拆分的：

  1. 本地开发服务器。开发人员拥有自己的源代码、IIS 和数据库（如有必要），以便在工作时将它们相互隔离并进行 QA。
  2. 构建服务器。用于 CI、自动化部署。这里没有网站或数据库。
  3. 每日构建环境（又名“开发”或“开发测试”）。功能齐全的站点，QA 可以在其中审查在冲刺期间完成的工作并提供反馈。
  4. QA 实验室（又名“回归”或“UAT”）。用于回归测试、演示和 UAT 的隔离实验室。

我们使用构建配置来保持这些更新：

  1. CI 在签入上构建以处理来自本地开发人员的签入。
  2. 每日计划构建和自动部署到每日构建环境。显然，开发人员或 QA 也可以手动触发此操作，以便在需要时进行推送。
  3. 用于部署到 QA 环境的手动触发器。
于 2012-12-18T15:39:03.297 回答
1

上面的解释中遗漏了一点，将测试人员添加到 SCRUM 流程的最佳方法是确保他们是 Scrum 团队的一部分，并在 Sprint 中与团队的其他成员（开发人员、PO 等）一起工作. 大多数情况下，这并没有真正完成，你最终拥有的只是（在最好的情况下）一个迷你瀑布过程。

现在让我解释一下。上面大量的硬件和环境解释几乎没有什么可添加的，您可以使用分阶段的服务器，或者甚至更好地将脚本设置为内部功能，以允许测试人员在需要时创建自己的环境（如果您正在使用任何 CI 框架，很可能您已经拥有其中所需的所有部件）。

困扰我的是你说你的测试人员“有他们自己的 sprint”。

在让测试人员参与 SCRUM 流程时，我看到的主要问题是他们实际上并不是流程本身的一部分。有时感觉是他们的技术不足以与开发人员真正接近，有时开发人员只是不想被向测试人员解释他们正在做什么而烦恼（直到他们完成 - 没有完成！），其他时候它只是管理层没有解释这是团队的期望。

简而言之，每个用户故事都应该有一个技术所有者和一个测试所有者。他们应该一直一起工作，并且应该尽快开始测试，即使是在开发人员环境中进行简短的“非正式清理测试”。毕竟，这个想法是通过消除过程中所有不必要的官僚主义来减少繁文缛节。

测试人员还应该向开发人员解释他们应该进行什么样的测试，然后再告诉 QA 他们可以继续使用该功能。手动测试既是开发人员的责任，也是测试人员的责任。

简而言之，如果你想让测试人员成为你的开发的一部分，比拥有正确的基础设施更重要的是，你需要有正确的思维定势，这意味着改变游戏规则，在许多情况下团队中每个人看待自己的任务和责任的方式。

我在我的博客上写了几篇关于这个主题的文章，如果到目前为止我没有打扰你，你可能会觉得这些很有趣。

切换到敏捷，并不像换 T 恤那么简单

敏捷思维而不是敏捷测试

于 2012-12-19T06:50:48.180 回答
0

我建议阅读Clemens Reijnen的文章“在 Scrum Sprint 中完成软件测试的 5 个技巧”。他解释了如何在 Scrum 冲刺期间整合软件测试团队和实践。

于 2013-01-03T10:13:43.883 回答