开发人员测试与质量检查团队测试-什么是正确的工作分工?

时间:2020-03-05 18:40:14  来源:igfitidea点击:

在尝试提倡更多的开发人员测试时,我发现" QA的工作不是吗?"用了很多。在我看来,让质量检查小组承担所有测试职责没有任何意义,但与此同时,Spolsky和其他人说我们不应该使用每小时100美元的开发人员来执行每小时30美元的测试人员可能要做的。在拥有专门质量检查团队的公司中,其他人的经验是什么?应该在哪里划分工作?

澄清:我的意思是将质量检查小组作为验证和验证小组。开发人员不应该进行验证(针对客户的测试),但是验证(功能测试)的划分点在哪里?

解决方案

回答

应始终进行一些开发人员测试。如果开发人员产生了太多的错误,那么他/她将在浪费时间来修复这些错误。重要的是,开发人员不要养成这样的态度:哦,好了,如果我留下一个错误,它将被抓住并且有机会修复它。

我们试图保持所产生错误的阈值。如果在测试期间超过此阈值,则开发人员对此负责。由我们决定此阈值是什么(对我们而言,每个项目的阈值可能会有所不同)。

此外,所有单元测试均由开发人员完成。

回答

我从事该行业仅一年了,但以我的经验,开发人员负责单元测试其功能,而质量检查负责测试场景。质量保证还将有望测试任何边界条件。

回答

以下是开发人员测试最有效/收益最高的一些方法:

  • 开发人员在使用功能时会修改共享库-开发人员可以深入了解质量检查/验证不会带来的副作用
  • 开发人员不确定库调用的性能,并编写了单元测试
  • 开发人员发现代码必须支持的规范中未考虑的用例路径,编写代码,更新规范,编写测试

在第三个示例中,开发人员应该执行多少测试职责是有争议的,但是我认为对于开发人员而言,这是最有效的,因为来自多层文档和代码层的所有相关细节都已经存储在她的短期记忆中。事后,测试人员可能无法达到这种完美的风暴。

我们是在谈论质量检查还是验证?我会根据检查清单,代码标准实施,UI准则等来考虑质量保证。如果我们谈论的是验证,那么开发人员花大量时间来编写和执行正式的测试用例是没有意义的必须提供编写良好测试所需的所有基本原理和设计文档。

回答

这是"黑盒"测试(我们知道代码应执行的工作,但不知道其工作方式)与"白盒"测试(知道其工作方式将驱动我们进行测试的方式)之间的区别。当我们提到质量保证时,大多数人会想到"黑匣子"测试。

我在质量检查小组也是软件开发人员的公司工作。 (如果我们想猜猜这家公司,那将大大缩小范围。)我知道乔尔的见解,而我的经验使我部分不同意:出于同样的原因,"白帽"黑客更有效地发现了安全漏洞,某些种类知道如何编写代码的白盒测试人员可以更有效地发现大量错误(因此,常见错误是什么,例如内存泄漏等资源管理问题)。

而且,由于面向QA的开发人员从初始设计阶段便是该过程的一部分,因此从理论上讲,他们可以在整个过程中帮助驱动更高质量的代码。理想情况下,对于每个在项目上专注于功能的开发人员,我们都有一个对立于专注于破坏代码(从而使其变得更好)的相反的开发人员。

从这个角度来看,与其说是将开发人员用于测试人员,不如说是一种脱机的结对编程,即一个开发人员强调控制质量。

另一方面,坦率地说,很多测试(例如基本的UI功能)都不需要这种技能。这就是乔尔的观点。

对于许多企业来说,我可以看到一个系统,其中编程团队可以权衡彼此的代码的代码审查和测试职责。例如,业务逻辑团队的成员可能会偶尔为UI团队进行巡回测试和审查代码,反之亦然。这样,我们就不会在全职测试上"浪费"开发人员的才能,但是我们获得了将代码暴露给(有希望的)专家审查和惩罚的好处。然后,更传统的质量检查团队可以进行"黑匣子"测试。

回答

我将我对某个问题的答案粘贴在我们的内部论坛上。如果我们有一个小时左右的时间..请根据Speed视频收听Mary Poppendieck的《竞争》。推荐的

注意(通过测试人员,我指的是质量检查小组)

开发人员/单元测试________ = _______可用性测试和探索性测试

'================================================= =================

验收/客户测试___ = _____财产测试

想象一下,它是一个有四个象限的正方形。 :)

左半部分应自动执行。

  • 开发人员测试验证代码是否按编码器的要求工作。工具:NUnit / xUnit /任何自制工具
  • 客户测试验证代码是否按客户期望的那样工作。测试应该非常容易编写,不应要求客户学习.NET / Java。否则,客户将不会编写那些测试(尽管他可能需要开发人员的一些帮助)。例如,适合使用可以用Word编写的HTML表。工具:FIT回归工具也位于此处。记录重放。

右半部分更好地利用了优秀测试人员的时间和精力。例如没有任何自动化测试可以告诉我们X对话框是否可用。人类比机器更擅长于此。

  • 可用性。尝试分解系统,(捕获未处理的故障情况,输入null值)。基本上抓住了开发人员错过的东西。
  • 再次进行性能测试需要人工。在这里,我们可以检查系统所需的客户委托属性。例如性能-搜索对话框是否满足2秒的响应时间?安全性-有人可以入侵该系统吗?可用性-系统是否有99.99%的时间在线?

测试人员不应该花时间在左半部分执行测试计划。开发人员有责任确保代码按客户和开发人员的预期工作。测试人员实际上可以帮助客户制定验收测试。

回答

我的一般立场是,测试人员永远不要发现单元级别的错误(包括边界情况)。测试人员发现的错误应该在组件,集成或者系统级别。当然,起初测试人员可能会发现"快乐之路"错误和其他简单的错误,但是这些异常应用于帮助开发人员进行改进。

问题的一部分可能是使用每小时$ 100的开发人员和每小时$ 30的测试人员:}。但是不管成本如何,我认为知道在开发周期的早期发现的错误不可避免地会更便宜,我们可能仍然可以通过让开发人员拥有更多测试来节省金钱。如果我们有一支高薪的开发团队和hack测试人员,我们可能会发现很多明显的大问题,但是我们会想念很多更晦涩的bug,这些bug稍后会困扰我们。

因此,我想问题的答案是测试人员应该测试尽可能多的测试。我们可以解雇所有测试人员并让开发人员进行所有测试,或者可以聘请测试人员大军,让开发人员签入所需的任何内容。

回答

在适当的时候,质量控制团队应该能够进行安全性,回归,可用性,性能,压力,安装/升级测试,而不是开发人员。

开发人员应在代码覆盖率下进行单元测试,以将编写的代码作为最低目标。

在两者之间,还有很多测试要做

  • 完整的代码路径测试
  • 组件测试
  • 集成测试(组件)
  • 系统(集成)测试
  • 等等

在最有意义的一些共识基础上,质量检查和开发之间的责任混在一起。某些组件测试只能通过单元测试来完成,而其他组件则需要在集成测试中"充分"地进行测试,等等。

互相交谈,找出每个人最舒适的做法。这将需要一些时间,但是这是值得的。

回答

测试应尽可能自动化,如果测试人员正在编写要添加到自动化测试套件中的代码,则它将变成开发人员的工作。

另外,我发现我们在代码审查中完成了许多质量检查,因为人们会建议将他们希望看到的多余的边角情况添加到正在审查的单元测试中(当然还有他们测试的代码) 。