问QA与开发比率

EN

答案是非常主观的，但这是我的经验。

在微软，我们有一个强大的测试开发组织。这与传统的QA略有不同，因为我们雇佣程序员进行测试，并在设计阶段就让他们参与到测试过程中来。他们的工作是测试，尤其是自动化产品的测试。根据我的经验，测试人员测试和自动化一个特性所花费的时间与开发人员编写代码和修复产品中的bug所花费的时间大致相同。这意味着1:1的映射。这与经验法则非常相似，即编写单元测试花费的时间与编写代码的时间大致相同。

此组合将根据以下几个标准而有所不同：

1. 开发人员做了多少单元测试。他们做的越多，需要做的测试就越少。
2. 开发人员从头开始编写多少代码，而不是利用现有的库。如果有许多预先存在的代码正在使用，并且测试人员也需要验证该功能，则必须考虑1:1映射的沉没开发成本。
3. 开发是多么动态。如果你正在编写一个UI，其中相对较小的开发人员调整会导致可测试表面的大变化，你将需要更多的测试人员参与进来。
4. 该功能是多么关键的任务。要编写像GMail这样的东西，可以随意使用，并且可以在现场容忍和修复错误，则需要更少的测试人员。在另一个极端，如果你在medical imaging devices上工作，你需要更多的测试，因为bug在现场很难修复，而且当它们发生时非常糟糕。

在公司的大多数项目中，我的工作比例是1:1。但这个比例可能会因以下几个因素而有所不同：

• 开发人员输出。我见过一位开发人员，他的产出很高，并且有3个QA在他的features.
• Quality栏上为产品工作。任务关键型、高可靠性的系统应具有比内部报告网站更高的QA标准，并且需要更多的QA人员。
• 某些项目必须在更多的配置和方案中进行测试。Devs可能会保持不变，但你显然需要更多的QA来覆盖完整的测试矩阵。
• 测试是多么自动化。如果测试不能很容易地自动化，你将需要更多的人来做手动测试。

在我的经验中，有两种主要的QA人员:一种是简单地遵循编写的脚本并与应用程序进行交互，以寻找边缘用例；另一种是实际上可以自己编写自动化测试代码，并寻求找到新的和创新的方法(模糊、Selenium、编写API客户端)来打破开发团队的代码。

如果你的QA团队主要由第一类人组成，那么1:1或更好的比率与你的开发人员可能是必须的。否则，他们将很难跟上开发团队引入的任何新功能，并且经常会抵制对产品所做的任何更改，因为这会使他们的测试工作流程更加复杂。

另一方面，后一种类型(即会编码的测试工程师)对任何高效的开发团队来说都是天赐之物。编码人员可以作为同行与他们通信，测试人员可以通过编写更智能和更抽象的测试工具和实用程序来找到有效的方法来自动化和改进自己的流程。一个真正好的测试工程师可能可以支持2-3个开发人员的工作，特别是如果这些开发人员已经在自己编写有用的单元和集成测试，测试人员可以将其用作起点。