在尝试提倡更多的开发人员测试时,我发现"这不是QA的工作吗？" 经常使用.在我看来,为QA团队提供所有测试职责是没有意义的,但同时Spolsky和其他人说你不应该使用100美元/小时的开发人员做一些30美元/小时的测试人员可以做的事情.在拥有专门的QA团队的公司中,其他人的经验是什么？应该在哪里划分工作？
澄清:我的意思是QA作为验证和验证团队.开发人员不应该进行验证(以客户为中心的测试),但验证(功能测试)划分点在哪里？
这是"黑盒子"测试(你知道代码应该做什么,但不知道它是如何工作的)和"白盒子"测试(知道它是如何工作的驱动器如何测试它)之间的区别.当你提到质量保证时,大多数人都会想到"黑匣子"测试.
我在QA团队也是软件开发人员的公司工作.(变窄领域很多,如果你愿意猜测该公司.)我知道乔尔的意见,我的经验使我部分同意:出于同样的原因,一个"白帽"黑客是更有效的发现的安全漏洞,某些种类知道如何编写代码的白盒测试人员可以更有效地发现错误(因此常见的错误是 - 例如,内存泄漏等资源管理问题).
此外,由于面向QA的开发人员是初始设计阶段的过程的一部分,理论上他们可以帮助在整个过程中驱动更高质量的代码.理想情况下,对于每个从事项目工作的开发人员而言,他们专注于功能,你就会有一个反对的开发人员专注于打破代码(从而使其更好).
从这个角度来看,对于测试人员来说,使用开发人员不仅仅是一种断开连接编程的问题,其中一位开发人员强调控制质量.
另一方面,许多测试(例如基本UI功能)坦率地不需要那种技能.这就是乔尔有意义的地方.
对于许多企业来说,我可以看到一个系统,在这个系统中,编程团队将代码审查和测试职责交换给彼此的代码.例如,Business Logic团队的成员可以偶尔花一些测试和审查UI团队的代码,反之亦然.这样你就不会"浪费"开发人员进行全职测试,但你正在获得将代码暴露给(希望)专家审查和惩罚的优势.然后,更传统的QA团队可以进行"黑匣子"测试.
应该总是有一些开发人员测试.如果开发人员产生了太多错误,那么他/她以后就会浪费时间修复这些错误.重要的是开发人员不要养成这样的态度,哦,如果我留下一个bug,它就会被抓住,我将有机会解决它.
我们试图保持产生错误的门槛.如果在测试期间超过此阈值,则开发人员对此负责.由您来决定这个阈值是什么(对于我们来说,它可能因项目而异).
此外,所有单元测试均由开发人员完成.
适当时,质量控制团队应该能够执行安全性,回归性,可用性,性能,压力,安装/升级测试,而不是开发人员
开发人员应该使用代码覆盖进行单元测试,以便将代码编写为最小目标.
介于两者之间,仍有相当多的测试要做
完整的代码路径测试
组件测试
集成测试(组件)
系统(集成)测试
等等
质量保证和发展之间的责任是基于对最有意义的一些共同协议.一些组件测试只能通过单元测试完成,其他组件测试在集成测试期间进行"充分"测试等.
互相交谈,了解每个人最舒服的事情.这需要一些时间,但这非常值得.
京公网安备 11010802040832号 | 京ICP备19059560号-6 