敏捷ALM - 开发人员在测试过程中的角色

Question

我试图采用敏捷概念，并且已经做了大量的研究，但是我还没有遇到过一个问题的答案。我知道尽管开发人员最初编写迭代任务时，测试人员可以准备他们的测试计划和测试用例，但是当测试开始时，如果没有错误被确定用于进一步编码和重新测试，那么应该开发人员正在努力呢？在我目前的SDLC中，开发人员将开始研究下一个版本的内容，但在敏捷方面，似乎只能在当前的迭代/冲刺阶段完成工作，直到完成完成。

Answer 1

@ user3329073 - 出于好奇，你目前正在计划冲刺和发布 - 还是你还在使用瀑布？还是采用混合方式？

无论如何，在计划周期中，您的开发人员看起来会完成他们打算处理的所有任务，并将这些任务交给您的QA团队进行测试。根据缺陷或更改的数量，他们可能会修复这些缺陷或编码更改 - 或者 - 正在等待将新工作分配给他们。这似乎有点奇怪 - 但这可能是由于我完全不了解你的情况。

通常情况下，我会期望（尤其是在敏捷环境），开发人员可以做一个或多个以下的 -

1. 它们可以编写自动化测试脚本，让每一个新功能是由您的测试自动化套件覆盖。 （你目前正在做自动化测试吗？）
2. 他们可以在同一个sprint中选择下一个任务/用户故事/需求 - 并开始研究。
3. 他们可以选择一些工程任务 - 例如代码重新考虑性能或其他常见原因，以及其他重要的（但通常不是紧急的）任务 - 甚至是文档。

这一切都取决于您的团队运作的整体环境。代码质量，稳定性，性能和文档的组织目标是什么？什么是测试自动化策略？有哪些工具可以使开发人员和测试人员完成他们的工作？

在我们的工程组织中，例如，在我们遵循更多的看板方法来成为敏捷的时候，我们几乎没有测试人员。我们进行测试驱动开发，开发人员在开始编码之前必须编写测试用例。完成编码后，他们必须自动执行他们编写的测试用例，并测试代码以确保其正常工作。完成后，我们会根据需要，由我们的首席架构师和其他工程负责人进行代码审查。与此同时，开发人员继续处理下一个用户故事或缺陷。下面显示的是我们在整个产品开发板中的开发路线。

此外，我们跟踪重要的工程任务和工作一个单独的车道，需要做 - 如果开发商有时间在他们的手，他们会拉从该车道的工作 - 与工作有关它直到完成。

我们有一个1-2手动QA乡亲，谁 - 随着产品管理 - 做一组特定的功能，都确定了被运往下一个版本的一次大检阅。

所以，就像我说的，这取决于您的整体方法是管理团队以及产品部署和交付。看板在帮助您成为敏捷方面的优势在于它可以帮助您从现有位置开始，并从那里改进您的流程。

下面是关于我们的实践一些额外的阅读，可以帮助 -

• 所有的看板开发商的日子 - 看板http://bit.ly/1h7kBcH

• 好处 - 降低300％的循环时间 - http://bit.ly/1bmuYLy

希望这有助于！

Answer 2

这听起来确实如此，在您向敏捷过渡期间，您尚未实现团队成员的完全整合。考虑将日常构建工作纳入测试环境（如果可以的话，可以连续部署），以便测试人员可以随着工作进展对工作进行审查。

此外，正如@Mahesh Singh提到的那样，开发人员也可以帮助测试，并且可能会与测试团队进行交流，指导他们完成测试，因为新版本将用于审查。

不管你如何设置它，冲刺中总是有一个点，当冲刺开始时没有更多的故事留下，团队需要关闭迭代。这是你希望你的“跨职能的团队成员，使他们可以与任何可能会留帮助：

• 准备演示脚本
• 建筑安装包
• 文档
• 训练准备
• 自动化测试
• 回顾即将到来的故事，为下一次迭代
• 帮助细化估计
• 打一些乒乓球！