敏捷测试过程中如何处理瓶颈

Question

我们的开发团队有一个问题，开发吞吐量远远高于QA成员所能测试的水平。

我们的测试团队发现，每两天需要测试一次新特性。

因此，我们必须进行函数、回归、探索和其他测试，这个循环需要很长时间，因为源代码中的任何更改或提交都会迫使它重复所有的事情。

他们现在正在等待开发人员在中间和sprint结束之前运行他的测试。对于敏捷环境中的这些瓶颈，是否有某种最佳实践？

• 因此，我们应该从项目所有者一方解决这个问题。在短跑计划中计划较少的任务？
• 为了避免这个瓶颈，应该拒绝任务吗？
• 短跑计划是否应该受到进一步惩罚？

我已经在复古中描述了这个问题，解决方案是缩短短跑计划。但是，取决于我们的努力，我们仍然有一个问题，就是我们一次又一次地遇到这个瓶颈。

但问题是，我们还编写和审查了测试自动化。但是，我们无法跟上通过“正常”测试、同时适应自动测试或创建新测试的步伐，所有的事情在一起都是无法实现的。

• 那么，测试自动化的执行是否也应该包括在sprint计划中呢？
• 但这不是会使问题更糟吗？
• 现在要确定的优先事项究竟在哪里？编写和修改测试自动化，或者只是普通的测试，即探索性的、功能性的测试。
• 什么是重要的白盒或黑盒测试？

特别是小团队，测试人员少，任务多，这些问题摆在他们面前。一方面，我们都知道，在敏捷世界中，速度是一切，但我们忘记了，QA有时负担太重。我们只是人类！

即使项目所有者正在寻找解决方案，并且所有的事情都在复古中报告，但并不是所有的事情都可以解决。取决于项目的规模，您总是有一个瓶颈，是的，它是绝望的！

Answer 1

整个团队对质量负责。测试工作-项目是在Sprint中的活动，而不是一个阶段，团队中的每个人都可以并且应该拾取测试活动。测试人员给团队带来QA知识，共享知识，而不是做所有的工作。打破交接模式。

是的，测试自动化应该在Sprint期间执行，产品应该是可移植的。这意味着PBI (Product项)应该是DoneDone。

我们的测试团队发现，每两天需要测试一次新特性。

一切都自动化了。执行敏捷团队实践"XP“，并从先试验实践开始。短周期工作意味着你需要改变你的工作方式。传统的手工测试不适合这些短周期。简短的探索性会议(检查测试自动化，没有遗漏任何东西)。

我建议您和您的团队(或者由敏捷教练/Scrum提供帮助)检查"敏捷测试教练指南“。

Answer 2

去年我发现自己也处于同样的境地。我们的团队大约有12个开发人员，只有2个QAs，我们使用了所有的时间测试特性，无法做(IMHO)更重要的改进过程的工作，使我们的测试基础结构更好，并且执行一些从质量角度改进事物的更长期的计划。另外，在一个更自私的方面，这是一个相当糟糕的职业生涯，因为我们不能做其他事情。

我所做的就是和我的经理进行讨论，我解释了问题的严重性，然后试图想出一个路线图来解决这个问题。在经理的批准下，我召集了整个团队，并开始研究整个“左移测试”方法。

1. 首先，我们两人培训每个开发人员如何阅读我们的报告工具，如何运行测试，以及在测试失败时寻找什么(检测不稳定、自动化缺陷或实际缺陷)。
2. 然后，我创建了管道和脚本，使运行的测试尽可能简单。我们的活动甚至试图将所有的事情都与Slack联系起来，这样就可以从聊天中触发一个倒退。但由于与Jenkins的其他联系的限制，不得不放弃了这一点。
3. 开发人员将负责测试他们的特性。起初，他们会给我们发送单元/int/e2e测试用例的PRs，这样我们就可以检查它们是否涵盖了所有重要的场景。
4. 在此基础上，我们继续致力于我们的框架和代码，以使一切尽可能容易扩展和理解。

在大约6个月之后，团队通过考虑测试来进行任务评估，他们对我们的框架足够满意，每个人都可以检查QA/测试PRs，所以我甚至不是瓶颈(剩下的人是我，我是唯一的QA)。最棒的是我再也不写测试了..。我编写了我们需要的基础结构和框架，并且一直在推动CI/CD，并且只有在出现一些重要特性时才开始编写测试。

您的里程肯定会有所不同，我很幸运有一个团队希望拥有他们所做的特性的每一个方面，因此他们非常适合于转换，但这就是我处理这个非常常见的场景的方式。

Answer 3

答案很简单！1-前面的工作。是的，提前工作将创建平衡的部署工作，准备好对sprint周期进行测试，并将使开发人员有时间对测试反馈做出响应，而远离sprint评审。2-为了实现上面的第一步，实现适当的敏捷规则，即低估和承担每个开发人员可以在sprint跨度内完成和测试的工作，为sprint天的测试留出适当的空间。

下面是我写的一篇关于我自己在主题：我解决了敏捷测试的瓶颈问题！的体验的完整文章

https://medium.com/@salibsamer/i-solved-scrum-sprint-end-testing-bottleneck-problem-bfd6222284a1