开发人员与测试人员的良好比率是多少?

首先,测试人员的开发人员是一个很好的 经验法则 但这是一个 坏的 规则 .

您需要考虑的是您的应用程序有多少个用例。将由用户以不受控制的方式进行交互的应用程序(即Web应用程序或桌面应用程序)将需要比类似控制台应用程序更多的测试人员。

一个应用程序只需要一个文件并在其中检测regex模式,与新的操作系统相比,它需要更少的测试人员。

虽然这些都是一般的准则,但实际的建议是使用基于这些因素的某种近似公式。

1) 有多少(划分的)用例?

我说的是划分用例,因为如果您包含状态更改和持久变量,那么程序中看似不相关的部分就会变成相关的。 即2+2=4(1个用例)2*2=4(2个用例)。这是两个简单的操作符,所以是两类用例。但是,如果可以的话 add 然后 multiply ,则不能只检查 添加 和 乘 单独地,您必须检查它们所有可能的排列。

在检查用例的数量时,请确保包括涉及链接命令的用例。

2) 每个测试需要多长时间?

这并不意味着(扩展计算器隐喻)只添加2+2并查看答案。您必须包括从崩溃中恢复所需的时间。如果答案不正确,您将期望测试人员使用屏幕截图和有关如何重新创建错误的具体说明来记录错误。如果你不给他们时间来做这种管理工作,那么你就是在你的计划中假定你没有错误。如果我们假设这一点,那么为什么还要有测试人员;)

一个复杂的项目将同时拥有大量的用例和大量的开发人员,但它们并不能保证相关性。您最好彻底地检查用例,并对需要多少测试人员做出有教育意义的决定。

增加奖金。一旦您彻底地分解了应用程序,您可能会发现一些在设计阶段从未考虑过的用例,并在测试人员发现它们之前修复它们。

Joel makes a good argument 对于每2个工程师1个测试人员,以及涵盖人们不使用这些测试人员的借口。

我写过一次博客 here . 最相关的摘录如下。

“我见过高质量的产品以10:1的dev:test比率生产,可怕的产品以1:1的比率生产。区别在于关注和关心质量。如果团队中的每个人(包括管理层)都非常关心产品质量,那么不管比例如何,都有很好的机会发生。但是,如果质量是应该在产品中进行测试的东西,那么每个开发人员都至少要有一个测试人员——如果你能得到的话,还要有更多的测试人员。”

最近有一篇关于 InfoQ 你可能会觉得有趣。

这根绳子显然很旧。但在我看来,这些答案似乎都没有抓住要点。

1)。开发人员和测试人员的比例是一个有效的问题,因为需求越复杂,需要的开发人员就越多,因此需要的测试人员就越多。相当多的回复似乎对此不予理睬。

2)。不管应用领域是什么,在现实世界中,“高质量”软件的好比率是2:1。你可能会以4:1的比例生活,但这真的很有弹性。当然,这个估计中有许多变量,不仅包括需求的复杂性、要部署的系统/环境,还包括开发人员的生产效率,以及交付计划的紧张程度。

高温高压

在我看来,确定所需测试人员数量的一个好指标是需求的复杂性,而不是开发人员的数量。如果我雇佣测试人员,我会查看需求列表(或者在必要时将设计文档分解为需求列表),并考虑每个需求需要多少测试时间来验证它是否正常工作。我将使用这个初始分析来雇佣一个测试人员库,然后在工作负载对我的初始库来说太高的情况下添加测试人员。

如果你正在制定一个预算,并且以后雇佣测试人员不是一个选择,那么你可能希望在比你的分析所指出的稍微多的测试资源中进行预算。太多总比不够好。

是否使用“纯”测试人员是另一个真正依赖于您需要多少测试资源的问题。我发现一个很好的折衷办法是雇佣能够胜任其他工作的测试人员,并在测试负载较轻的时候以其他身份使用它们。

编辑: 如果您很幸运能够在早期进行一组验收测试,请将“验收测试”替换为上面的“需求列表”。-)

没有普遍的“好”比率。

显然,测试某个东西所需的时间是与上下文相关的——这取决于与开发该特性所需的时间几乎无关或根本无关的因素。

还考虑:

• 什么是发展?
• 什么是测试?
• 如果我们无论如何都要执行回归测试,那是否算是“零”额外的测试小时?

见: http://www.sqablogs.com/jstrazzere/150/What+is+the+%22Correct%22+Ratio+of+Development+Time+to+Test+Time%3F.html

我会说(取决于您需要测试的速度),对于自动化,每5个开发人员就可以有1到2个测试人员。

为什么?

• 通过自动化,他们只需要担心测试新模块
• 回归测试将处理旧的测试。
• 1或2个测试人员可以轻松地覆盖5个开发人员将要做的所有工作,例如每周
• 我学到的一个很好的比率是,每开发10个小时,质量保证团队就要花3到4个小时来跟踪那些10个小时产生的大部分缺陷。

希望能有所帮助:)

另外,您会使用“纯”测试仪吗,或者 你能把测试和其他的结合起来吗 角色(例如文档、用户 培训等?

这取决于测试的类型,但我不会用其他角色给测试人员增加负担。称职的测试工程师和称职的软件工程师一样,身价不菲。如果你给他们的任务超出了他们的专长范围,你会放慢他们的速度,让他们放弃。软件工程师喜欢做文档或用户培训吗?通常不会。测试人员也是。

但是,用来自其他领域的人来补充您的测试团队并没有什么错,特别是在可用性测试、验收测试、快速评审等方面。

有一件事是肯定的。测试人员的数量应该大于开发人员的数量。对于开发人员创建的每个特性,测试人员必须在各种类型的测试下运行该特性:功能性、可用性、边界、压力等。尽管准确的比率将更多地取决于测试用例的数量和测试周期的长度(1周、3天、1天或半天),但单个开发人员将生成足够的测试多个测试人员的活动。此外,可能还有一些场景需要多个测试人员来模拟两个或多个同时在系统上工作的用户。