如何在敏捷开发环境中集成测试人员？ [关闭]答案

【问题标题】：How to integrate testers in agile develop environment? [closed]如何在敏捷开发环境中集成测试人员？ [关闭]
【发布时间】：2012-12-18 08:06:05
【问题描述】：

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

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

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

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

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

【问题讨论】：

标签： testing agile scrum

【解决方案1】：

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

编辑：我总是觉得发布 wikilinks 是个混蛋，但这篇关于 Multi-Stage CI 的文章很好：http://en.m.wikipedia.org/wiki/Multi-stage_continuous_integration

【讨论】：

您是否有一些文档对此进行了解释？是链接还是什么？
谢谢。我从未听说过登台服务器。我会深入研究:)

【解决方案2】：

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

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

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

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

部署过程：

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

【讨论】：

谢谢。什么时候部署到额外的环境（临时服务器）？
我已将其添加到答案中 :) 如果您还有更多问题，请随时提问
再次感谢。这也是心中所想。开发人员将项目标记为准备好进行测试，测试人员决定何时部署他们的登台服务器并执行他们的测试。当测试失败时，循环重新开始。我剩下的唯一问题是，你从哪里部署到生命服务器？
嗯，这实际上取决于，我不认为有正确的答案。在我们的例子中是这样的：（dev + test）=> staging（用于验收）=> demo（用于每 2 周演示用户故事）=> SIT 和 End2End 测试环境（每 2 周部署）=> 生产;我们在 6 个月内发布了一个版本，这是一个功能所经历的阶段。
您可以添加任意数量的步骤/阶段，以及适合您的方式。假设您有一个用于 alpha 的测试组和一个用于 beta 版本的测试组。那么你可能需要另一台服务器。

【解决方案3】：

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

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

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

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

CI 构建在签入之上以处理来自本地开发者的签入。
每日计划构建和自动部署到每日构建环境。显然，开发人员或 QA 也可以手动触发此操作，以便在需要时进行推送。
用于部署到 QA 环境的手动触发器。

【讨论】：

谢谢杰。这正是我的想法。我对你的帖子很满意。这表明我走在正确的轨道上:)

【解决方案4】：

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

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

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

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

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

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

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

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

Switching to Agile, not as simple as changing your T-Shirt

Agile Thinking instead of Agile Testing

【讨论】：

第一次发帖的答案非常好。

【解决方案5】：

我会推荐阅读 Clemens Reijnen 的文章“5 Tips for Getting Software Testing Done in the Scrum Sprint”。他解释了如何在 Scrum 冲刺期间整合软件测试团队和实践。

【讨论】：