如何在敏捷开发环境中集成测试人员？

Question

我们与Scrum合作，我认为我们是正确的方式，但有一件事困扰我：测试人员还没有参与开发周期。现在我正在考虑如何让测试人员参与开发团队。现在它是分开的，测试人员有他们'自己'的冲刺。

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

我想要的是测试人员在用户故事实施的同一sprint中测试用户故事。但我正在努力解决这个问题。

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

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

Answer 1

您需要一个临时服务器并且每隔一段时间部署一次构建。多数民众赞成我们如何做到这一点：CI-＆gt; Dev-＆gt; Staging-＆gt; Live

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

Answer 2

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

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

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

如果用户故事已完成，它将部署在登台服务器上，用户故事的接受将在该登台服务器上进行。

部署过程：

Dev + Test =＆gt;分期（用于接受）=＆gt;演示（用于每两周演示一次用户故事）=＆gt; SIT和End2End测试环境（每第2周部署一次）=＆gt;生产（部署大约全部6个月）

Answer 3

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

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

1. 本地开发服务器。开发人员拥有自己的源代码，IIS和数据库（如果需要），以便在工作时将它们彼此隔离并进行质量保证。
2. 构建服务器。用于CI，自动部署。这里没有网站或数据库。
3. 每日构建环境（a.k.a。'Dev'或'Dev Test'）。功能齐全的网站，QA可以在sprint期间审核工作并提供反馈。
4. QA实验室（a.k.a。'回归'或'UAT'）。用于回归测试，演示和UAT的孤立实验室。

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

1. CI构建签到处理来自本地开发者的签到。
2. 每日预定构建和自动部署到Daily Build环境。显然，Devs或QA也可以手动触发，以便在需要时进行推送。
3. 部署到QA环境的手动触发器。

Answer 4

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

现在让我解释一下。上面提到的广泛的硬件和环境解释几乎没有什么可增加的，你可以使用分阶段服务器，甚至更好地使它成为一个内部功能，让脚本到位，允许测试人员在他们想要的时候创建他们自己的环境（如果你正在使用任何CI框架机会你已经拥有了所需的所有部分。

困扰我的是你说你的测试者“有'自己的'冲刺”。

我在让测试人员参与SCRUM流程时遇到的主要问题是他们并不是流程本身的一部分。有时感觉是他们的技术不足以与开发人员非常接近，有时开发人员根本不想为测试人员解释他们正在做什么（直到他们完成 - 没有完成！），其他时候它仅仅是一个管理层没有解释这是团队的期望。

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

测试人员还应该向开发人员解释他们在告诉质量保证人员他们可以继续使用该功能之前应该进行的测试。手动测试与开发人员和测试人员一样负责。

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

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

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

Agile Thinking instead of Agile Testing

Answer 5

我建议您阅读Clemens Reijnen撰写的文章“5 Tips for Getting Software Testing Done in the Scrum Sprint”。他解释了如何在Scrum sprint期间集成软件测试团队和实践。