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

时间:2008-08-18 00:19:05

标签: unit-testing testing process qa

在尝试提倡更多的开发人员测试时,我发现“这不是QA的工作吗?”经常使用。在我看来,为QA团队提供所有测试职责是没有意义的,但同时Spolsky和其他人说你不应该使用100美元/小时的开发人员做一些30美元/小时的测试人员可以做的事情。在拥有专门的QA团队的公司中,其他人的经验是什么?应该在哪里划分工作?

澄清:我的意思是QA作为验证和验证团队。开发人员不应该进行验证(以客户为中心的测试),但验证(功能测试)划分点在哪里?

9 个答案:

答案 0 :(得分:19)

这是“黑盒子”测试(你知道代码应该做什么,但不知道它是如何工作的)和“白盒子”测试(知道它如何工作的驱动器如何测试它)之间的区别。当你提到质量保证时,大多数人都会想到“黑匣子”测试。

我在QA团队也是软件开发人员的公司工作。 (如果你想猜这个公司的话,这会缩小很多的范围。)我知道Joel的观点,我的经历让我有些不同意:出于同样的原因,“白帽子”的黑客更多有效地发现安全漏洞,知道如何编写代码的白盒测试人员可以更有效地发现某些类型的错误(因此常见的错误是什么 - 例如,内存泄漏等资源管理问题)。

此外,由于面向QA的开发人员是初始设计阶段的流程的一部分,理论上他们可以帮助在整个过程中驱动更高质量的代码。理想情况下,对于每个从事项目工作的开发人员而言,他们专注于功能,你就会有一个反对的开发人员专注于打破代码(从而使其更好)。

从这个角度来看,使用开发人员进行测试的问题不如使用一种开发人员强调控制质量的断开配对编程。

另一方面,很多测试(例如基本的UI功能)坦白地说不需要那种技巧。这就是乔尔有意义的地方。

对于许多企业而言,我可以看到一个系统,编程团队将代码审查和测试职责交换给彼此的代码。例如,Business Logic团队的成员可以偶尔为UI团队进行巡回测试和审查代码,反之亦然。这样你就不会“浪费”开发人员进行全职测试,但你正在获得将代码暴露给(希望)专家审查和惩罚的优势。然后,一个更传统的QA团队可以进行“黑匣子”测试。

答案 1 :(得分:8)

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

开发人员应该使用代码覆盖进行单元测试,以便将代码编写为最小目标。

介于两者之间,仍有相当多的测试需要完成

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

基于对最有意义的一些共同协议,质量保证与发展之间的责任是混杂的。一些组件测试只能通过单元测试完成,其他组件测试在集成测试等过程中进行“充分”测试。

互相交谈,了解每个人最舒服的事情。这需要一些时间,但这非常值得。

答案 2 :(得分:7)

应该总是有一些开发人员测试。如果开发人员产生了太多错误,那么他/她以后就会浪费时间修复这些错误。重要的是,开发人员不要养成这样的态度,如果我留下一个bug,它就会被抓住,我将有机会解决它。

我们尽量保持产生错误的门槛。如果在测试期间超过此阈值,则开发人员对此负责。您可以自行决定该阈值是多少(对于我们而言,它可能因项目而异)。

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

答案 3 :(得分:4)

我只在这个行业工作了一年,但根据我的经验,开发人员负责对其功能进行单元测试,而QA则负责测试方案。 QA也可以测试任何边界条件。

答案 4 :(得分:3)

我在内部论坛上粘贴了我对问题的回答。如果你有一个小时左右的时间......听听Mary Poppendieck的Competing on the basis of Speed视频。 推荐

注意(由测试人员 - 我指的是QA团队)

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

“============================================== ====================

接受/客户测试 ___ = _____ 物业测试

想象一下,要成为一个有四个象限的正方形。 :)

左半部分应该是自动化的。

  • 开发人员测试验证代码是否像编码器所希望的那样工作。   工具:NUnit / xUnit /任何自制工具
  • 客户测试验证代码是否按照客户的意愿运行。 测试应该很容易编写,不应该要求客户学习.NET / Java。否则客户不会写这些测试(尽管他可能需要开发人员的帮助)。例如,适合使用可以用Word编写的HTML表。 工具:FIT 回归工具也在这里。记录重放。

右半部分更好地利用时间&好测试者的努力。例如没有自动化测试可以告诉您X对话框是否可用。人类在这方面比机器更好。

  • 可用性。尝试打破系统,(捕获未处理的故障情形,输入空值)。基本上抓住了开发人员错过的东西。
  • 物业测试再次需要人类。在此处检查系统所需的客户强制属性。例如性能 - 您的搜索对话框是否符合2秒的响应时间?安全 - 有人可以入侵这个系统吗?可用性 - 99.99%的时间是你的系统在线?

测试人员不应该花时间在左半边执行测试计划。开发人员有责任确保代码以客户和开发人员的意图运行。测试人员可以帮助客户制定验收测试..

答案 5 :(得分:3)

测试应尽可能自动化,如果测试人员编写的代码已添加到自动化测试套件中,则会将其重新设置为开发工作。

此外,我发现我们在代码审查中完成了大量的QA,因为人们会建议他们希望看到额外的边缘和角落案例添加到正在审核的单元测试中(以及他们测试的代码)当然)。

答案 6 :(得分:2)

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

您的部分问题可能是每小时100美元的开发人员和每小时30美元的测试人员:}。但无论成本如何,我认为知道在开发周期早期发现的错误不可避免地更便宜,您可能仍然可以通过让开发人员拥有更多测试来节省资金。如果你有一个高薪的开发团队和黑客测试人员,你可能会发现很多很明显的问题,但你会错过很多比较模糊的错误,这些错误会在以后再次出现。

所以,我想你的问题的答案是测试者应该按照你想要的那样进行测试。您可以解雇所有测试人员并让开发人员完成所有测试,或者您可以雇佣一大批测试人员并让开发人员检查他们想要的任何内容。

答案 7 :(得分:1)

有两种类型的qa组,那些想维持现状的人。 我们总是这样做。他们自然而然地讨厌并摆脱那些试图提高效率并因此超越自己舒适区域的人。这件事发生在我身上不止一次。不幸的是,qa经理和他们的qa队一样无能。因此,管理过去6年的qa经理会杀死任何自动化,会引入许多流程来证明他们的存在。这是一个高级管理层的责任来认识到这一点。     有些技术人员知道工具。不幸的是,编程语言不是一种工具,而是一种愿景。 与这些人合作真正取决于他们愿意学习多少以及管理层愿意承担多大改变风险的风险。测试应该以与编写面向对象结构易于维护的主代码相同的方式编写。 我认为,开发人员应该检查qa测试。大多数时候我发现自动化没有测试任何东西。不幸的是,qa工作被认为是较低级别的,所以开发人员不打扰。当我得到一个有影响力的开发人员的支持时,我自己得到了运气,他愿意向经理解释我的努力。不幸的是,它的工作时间只有一半。测试人员恕我直言应该向开发经理报告。并且所有团队都应该对qa测试的实际测试负责。

答案 8 :(得分:0)

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

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

第三个例子中开发者应该执行多少测试任务是有争议的,但我认为它对开发人员来说是最有效的,因为来自多层文档和代码的所有相关细节都已经在她的短片中了术语记忆。事后,测试人员可能无法实现这种完美的风暴。

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