开发者测试对比QA 团队测试 - 正确的工作分工是什么？[关闭]

StackOverflow https://stackoverflow.com/questions/14040

题

在试图提倡更多开发人员测试的同时，我发现该论点“不是QA的工作吗？”经常使用。在我看来，让 QA 团队承担所有测试职责是没有意义的，但同时 Spolsky 和其他人说你不应该使用 100 美元/小时的开发人员来做 30 美元/小时的测试人员可以做的事情。在拥有专门 QA 团队的公司中，其他人的经历如何？工作分工应该从哪里划分？

澄清：我的意思是 QA 作为验证和验证团队。开发人员不应该做验证（以客户为中心的测试），但是验证（功能测试）的划分点在哪里？

有帮助吗？

解决方案

这是“黑盒”测试（您知道代码应该做什么，但不知道它是如何工作的）和“白盒”测试（知道它是如何工作的决定您如何测试它）之间的区别。当提到质量保证时，大多数人都会想到“黑盒”测试。

我在一家公司工作，该公司的 QA 团队也是软件开发人员。（这缩小了范围 很多 如果你愿意猜猜这家公司。）我知道乔尔的观点，而我的经验使我部分不同意：出于同样的原因，“白帽”黑客可以更有效地发现安全漏洞，知道如何编写代码的白盒测试人员可以更有效地发现某些类型的错误（因此知道常见错误是什么 - 例如，资源管理）内存泄漏等问题）。

此外，由于面向 QA 的开发人员是初始设计阶段过程的一部分，因此理论上他们可以帮助在整个过程中推动更高质量的代码。理想情况下，对于每个专注于功能的项目开发人员来说，你都会有一个专注于破坏代码（从而使其变得更好）的反对开发人员。

从这个角度来看，这与其说是使用开发人员作为测试人员，不如说是一种脱节的结对编程，其中一个开发人员强调控制质量。

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

对于许多企业来说，我可以看到一个系统，其中编程团队可以为彼此的代码权衡代码审查和测试职责。例如，业务逻辑团队的成员可以偶尔进行巡回测试和审查 UI 团队的代码，反之亦然。这样，您就不会在全职测试上“浪费”开发人员的才能，但您可以获得将代码暴露给（希望如此）专家审查和惩罚的优势。然后，更传统的 QA 团队可以承担“黑盒”测试。

其他提示

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

开发人员应该以代码覆盖率为最低目标来进行单元测试。

在此期间，仍有相当多的测试要做

  • 完整的代码路径测试
  • 元件测试
  • 集成测试（组件）
  • 系统（集成）测试
  • ETC

这些责任由 QA 和开发人员混合承担，基于双方就最有意义的事情达成的共识。一些组件测试只能通过单元测试来完成，其他组件测试则在集成测试等过程中进行“充分”测试。

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

应该总是有一些开发人员测试。如果开发人员产生了太多错误，那么他/她稍后会浪费时间来修复这些错误。重要的是，开发人员不要养成这样的态度：哦，如果我留下一个错误，它就会被捕获，我将有机会修复它。

我们尝试为产生的错误设置一个阈值。如果在测试过程中超过了这个阈值，那么开发人员就要对此负责。由您决定这个阈值是多少（对于我们来说，它可能因项目而异）。

此外，所有单元测试都是由开发人员完成的。

我进入这个行业才一年，但根据我的经验，开发人员负责对其功能进行单元测试，而 QA 负责测试场景。QA 还需要测试任何边界条件。

我正在将我的答案粘贴到我们内部论坛上的一个问题上。如果你有一个小时左右的话..听听玛丽·波彭迪克的 以速度为基础的竞争 视频。 受到推崇的

注意（测试人员 - 我指的是 QA 团队）

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

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

验收/客户测试 ___=_____ 性能测试

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

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

  • 开发人员测试验证代码是否按照编码人员的预期工作。工具：NUnit / xUnit / 任何自制工具
  • 客户测试验证代码是否按照客户希望的方式工作。测试应该非常容易编写，不需要客户学习 .NET/Java。否则客户不会编写这些测试（尽管他可能需要开发人员的一些帮助）。例如，Fit 使用可以用 Word 编写的 HTML 表格。工具：拟合回归工具也在这里。记录重播。

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

  • 可用性。尝试破坏系统（捕获未处理的故障场景，输入空值）。基本上抓住了开发者错过的东西。
  • 属性测试再次需要人类。您可以在此处检查系统所需的客户强制属性。例如性能 - 您的搜索对话框满足 2 秒响应时间吗？安全性——有人可以侵入这个系统吗？ETC。可用性 - 您的系统在 99.99% 的时间内都在线吗？

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

测试应该尽可能自动化，如果测试人员正在编写添加到自动化测试套件的代码，那么测试就会重新回到开发工作中。

另外，我发现我们在代码审查中完成了很多质量保证，因为人们会建议他们希望看到的额外边缘和角落案例添加到正在审查的单元测试中（当然还有他们测试的代码） 。

我的总体立场是测试人员永远不应该发现单元级错误（包括边界情况）。测试人员发现的错误应该是在组件、集成或系统级别。当然，一开始测试人员可能会发现“快乐路径”错误和其他简单错误，但这些异常应该用来帮助开发人员改进。

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

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

有两种类型的质量保证团体，即那些想要维持现状的团体。我们一直都是这样做的。他们自然地讨厌并摆脱那些试图让事情变得更有效率并因此超出他们的舒适区的人。这种事在我身上发生过不止一次。不幸的是，质量保证经理和他们的质量保证团队一样无能。因此，过去 6 年一直在管理的质量保证经理将取消任何自动化，将引入大量流程只是为了证明其存在的合理性。认识到这一点是高层管理人员的责任。有一些懂工具的技术人员。不幸的是，编程语言不是一种工具，而是一种愿景。与这些人一起工作实际上取决于他们愿意学习多少，以及管理层愿意冒多大的风险来改变事情。测试的编写方式应与编写易于维护的面向对象结构的主代码相同。我确实认为，开发人员应该审查质量保证测试。大多数时候我发现自动化没有测试任何东西。不幸的是，质量保证工作被认为是下层阶级，所以开发人员不会打扰。当我得到团队中有影响力的开发人员的支持时，我自己很幸运，他愿意向经理解释我的努力。不幸的是，它只有一半的时间有效。恕我直言，测试人员应该向开发经理报告。所有团队都应对质量保证测试实际测试的内容负责。

以下是开发人员测试最有效/回报最高的一些方法：

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

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

我们是在谈论质量检查还是验证？我认为 QA 包括检查清单、代码标准执行、UI 指南等。如果我们谈论验证，那么开发人员花费大量时间编写和执行正式测试用例是没有意义的，但开发人员必须提供编写良好测试所需的所有基本原理和设计文档。

许可以下： CC-BY-SA 和 归因
不隶属于 StackOverflow
scroll top