哪些因素会影响质量检查/测试人员与应用开发人员的比例

#1 楼

否-没有“正确”的比率。答案取决于产品（提供初级曲棍球成绩的Web服务还是太空飞船？），以及程序员和测试人员在团队中扮演的角色。我见过非常成功的团队，其中程序员与测试人员的比例为15或20：1，而制作废话软件的比例为1：1的团队。

在上面的高比例示例中，程序员编写了单元测试，功能测试，并与测试人员一起进行验收测试，集成测试以及许多级别的可靠性，性能和规模测试。

在我想的1：1例子中，程序员会在编译后立即将代码提供给测试团队，并在质量缓慢下降的情况下进行大量来回处理进入程序。

现在，您当然可以制作比例为1：1的出色软件，以及比例为10：1的拙劣软件-重要的是要弄清楚谁在做什么追求品质，每个人都知道自己在工作中的作用。

#2 楼

我不认为这是一个“正确”的比例。我认为需要比较接近的因素：


QA人员使用此特定模块的经验，因为新手将需要学习曲线特定模块（因为我不止一次要向开发人员解释功能）
由于复杂的功能需要更多的时间（希望它们能尽早完成以适应更多的时间），因此增加了功能的范围测试）
生产时间（我是否需要在紧要关头从其他部门或团队“借用”测试人员，或者压力很小？哈哈）
开发人员是否在运行任何单元测试或做任何同行评审？ （请漂亮）
在这个时间范围内还需要交付什么？ Service Pack发布等。
如果该比率偏离应有的目标，公司愿意承担多少风险？ （推迟日期？减少复杂性？增加部队？等）

#3 楼

没有答案是“正确的”。

我想说的是，大多数公司的主要影响因素是应用程序的目标质量，但这不是我的经验。

我多年来看到的最大的单一因素是，定义比率是公司愿意花费的可用预算，而且许多公司都认为成本比质量低。

我可以从过去的项目中为您提供一些真实数字，以供参考。 ：5或更高（测试人员较少）更常见。正在开发的应用程序类型是大型公司级的，通常是基于Web的内部应用程序。

我认为，当您购买商用软件时，随着tesitng配置数量的增加，该比例需要提高。

例如，如果我要测试内部专用应用程序，则通常只需要在一个浏览器上进行测试。对于在Internet上部署的公共站点，您需要测试很多其他内容。

如果要在iPhone上测试软件，并且需要定位包括iPod touch在内的所有出厂设备，那么现在会有类似考虑12种硬件设备，其中有3种主要的4种主要操作系统版本。

考虑到这一点，我倾向于集中精力从可用的现有人数中提供尽可能多的“物有所值”。

有效的测试自动化套件是我所见到的最大的倾斜秤之一。之所以如此重要，是因为它可以使测试人员从手动回归中“解放出来”，从而在其他地方更有效。指标以支持您需要更高比率的案例，然后捕获结果以供将来参考，并为同行们辩护。

#4 楼

尽管“开发与测试的比率”由于其简单性而成为一个吸引人的概念，但它是确定测试人员规模的一种糟糕方法。

开发时间与测试时间之间没有固有的预设关系。而且，开发/测试人员比例与开发/测试时间比例之间没有固有的预设关系。

假设您有以下新要求：


您的产品以前从未在Windows XP SP2上进行过测试，
现在必须支持该OS版本。


开发需要1个小时。一天（Windows XP SP1运行良好，他们不得不更改“系统要求”文档中的某些文本，但不必相信他们必须做其他事情）

您可以预测测试应该花费多长时间吗？ ？


对于某些公司，他们可能需要进行1天的临时测试。
对于其他公司，可能要花6个月的时间（也许他们处于受管制的行业中，并且丢失错误的成本非常高）

案例2

假设公司要更改其“关于”框。


用漂亮的图形替换以前的纯文本对话框。


由于开发人员不是很好的图形艺术家，所以需要他们需要3天的时间来学习新的图形工具，经过3天的市场部反复试验以使其看起来“恰到好处”，并有2天的时间将其集成到内部版本中。

您能预测测试需要多长时间吗？


在某些商店中，初级QAer可能会花一个小时或更短的时间进行检查。
在其他商店中，由于图形中嵌入了新的公司徽标，它必须与市场营销现在要求的新尺寸和颜色规格完全匹配，这可能需要更长的时间。

很显然，测试某些内容所需要的时间取决于上下文-取决于可能与开发该功能所需时间无关的因素。

还请考虑：


什么算作开发？什么算作测试？
如果我们还是要进行回归测试，那算不算额外的测试时间为“零”？

http：/ /strazzere.blogspot.com/2010/04/what-is-correct-ratio-of-development.html

要确定合适的人员配置模型，您必须确定您的QA / Test人员期望做的事以及他们不会期望做的事。您必须确定它们将按照哪种时间表运行。您必须确定他们需要具备什么专业知识水平（技术和领域专业知识）。您必须确定他们将获得多少外部帮助。

总而言之，请考虑对质量保证/测试的期望是什么，然后让其指导您的人员配备决策，而不是盲目遵循比率。 br />

#5 楼

有趣的问题。我一直对公司如何达到命题1的问题有一个疑问：X Devs

命题可以基于QA流程，SDLC流程和产品的复杂性得出。从我的角度来看，我们需要考虑以下方面的内容


测试团队的经验，团队成员可以独立运行还是测试人员经验不足
测试类型（白盒） /黑盒子）。取决于它，我们可以得出测试方案
如果测试条件是100％的代码覆盖率，我们需要考虑编写一个自动化套件来实现它
如果测试条件是100％的P1情况，这是与确定和执行方案有关的信息
每个测试项目的自动化和非自动化任务的百分比。测试的某些方面可能不是自动化的（频繁更改功能，新添加的待处理功能自动化，自动化中遗漏的浏览器很少）
发布的复杂性，功能之间的关系。如果发布了十个不相关的功能，则没有必要将其分配给一个人。如果功能相关，那么将它们组合在一起并进行测试是很有意义的。

查看执行模型并获得上述参数的数据将有助于我们为开发测试比率提供建议

#6 楼

是的，这里有一个“正确的”比率：
正确的比率是使公司实现其目标的比率。
我会考虑的因素：

公司目标
公司的年龄
公司的规模
采用敏捷
测试方法
SDET的经验
使用的框架
质量的测量方法
开发人员的经验
管理经验
就位的自动化程度
TDD，BDD和ATDD的用法
能够互相扮演的角色
已经存在哪些质量指标
工程师和SDET的可用性
存在大量且不断增长的积压
故障的影响，例如广告，手术，核电

#7 楼

要考虑的另一个因素是项目处于哪个阶段。
仅添加错误修复或相对较新的小功能的旧式项目需要较少的测试人员。