应对规模过小的QA团队

Question

我们正在建造两种内部产品：

第一个版本有web、android和iOS (总共有9个开发人员)，有2个QA工程师(1个全职手动/自动化工程师，另一个是50%的专用手动QA工程师)。

2-另一种产品有一个网络版本(3名开发人员)，配备1名全职手册/自动化QA工程师。

我们的项目1的QA团队的规模显然超过了开发团队的发布效率。这是延迟获得宝贵的反馈，我们的发行。

尽管我们正在尽最大努力雇佣新的QA资源，但事实证明，这是很有挑战性的，而且很费时。我们的最后期限即将到来(一个月内的产品#1，2个月后的产品#2 )，我们需要快速有效的方法来处理质量保证方面的不足。

对于这种情况，您有什么建议可以提供吗？

Answer 1

我不认为你的团队人手不足。我们的运作比你更精简。

在现实生活中，开发人员与集成/系统/功能自动化测试人员的比率仅为10:1。

如何才能保持质量？通过更多地关注单元测试(由开发人员编写和维护)。

单元测试应该是您的第一道防线。因为如果单元测试失败了，那么很明显是什么故障以及如何修复它。许多项目在单元测试中比在生产代码中有更多的代码行。并使用覆盖率分析来确保单元测试练习了大部分核心代码。

有了如此全面的单元测试，自动化UI/功能/系统级测试只需覆盖20%的代码，即80%的通用功能(以最少的自动化保持合理的质量)。自动回归测试是代码，需要在测试代码更改时进行维护，因此您需要最少的回归测试(因此您需要维护的测试较少)。

在我看来，您的项目的问题不是QA测试人员数量少，而是单元测试不足和单元测试覆盖率低。

还请参阅关于测试金字塔和Pareto原理的争论关于需要集中精力的内容。

Answer 2

基于

风险的测试可以帮助您快速反馈

这是你应该研究的另一个好方面。

正如其中一个答案所述，应该要求开发人员测试他们的工作。这肯定会有帮助的。我完全同意这一点。

但是，除了“基于风险的”测试，还可以进一步帮助您。

• 在基于风险的测试中，您尝试确保对大多数常见的应用程序流进行测试。
• 这样，您可能会错过一些“最罕见”的场景，但至少您将有一个最常见的工作流的列表不工作。
• 因此，您选择“高”和“中等”优先级测试用例并对它们进行测试。你留下低优先级的案子。如果时间太紧，那么您可能只测试“高”优先级测试用例；目的是进行初始反馈。
• 但是，这并不意味着测试已经完成。但是，这确实意味着常用的应用程序区域要么是“工作正常”，要么是“有问题”。

一旦您已经招募了QA资源，并且您的团队不再处于平衡状态，您就可以弥补之前由于时间不够而错过的内容。

但是，这给了你一个公平的想法(如果不是完整的)项目的健康。开发人员也会发现一些重要的缺陷。

Answer 3

在我看来，project#1中的开发应试比率显然过于乐观。一个开发人员可能会更改一行代码，这将需要大量的测试工作。

然而，一旦您面临这种情况(如果您有这样的比率，项目开始时似乎有一些缺失的风险评估)，我建议您的开发人员进行测试(给他们一个机会再次展示他们的生产力)，除非您有足够的QA资源。毕竟，这就是Scrum所声明的价值-团队交叉功能。