在试图提倡更多的开发人员测试时，我发现了“这不是 QA 的工作吗？”的论点。被大量使用。在我看来，让 QA 团队承担所有测试职责是没有意义的，但同时 Spolsky 和其他人说你不应该使用 100 美元/小时的开发人员来做 30 美元/小时的测试人员可以做的事情. 在拥有专门的 QA 团队的公司中，其他人的经历是什么？分工应该画在哪里？
澄清：我的意思是 QA 作为验证和验证团队。开发者不应该做验证（以客户为中心的测试），但验证（功能测试）的划分点在哪里？
Joe Schneider
问问题
44569 次
9 回答
24
这是“黑盒”测试（你知道代码应该做什么，但不知道它是如何工作的）和“白盒”测试（知道它是如何工作的会决定你如何测试它）之间的区别。当您提到质量保证时，大多数人会想到“黑盒”测试。
我在一家 QA 团队也是软件开发人员的公司工作。（如果您想猜测这家公司，这会大大缩小范围。）我知道 Joel 的观点，而我的经验使我部分不同意：出于同样的原因，“白帽”黑客更有效地发现某些类型的安全漏洞错误由知道如何编写代码的白盒测试人员更有效地发现（因此常见的错误是什么 - 例如，内存泄漏等资源管理问题）。
此外，由于面向 QA 的开发人员从初始设计阶段就参与了流程，理论上他们可以帮助在整个流程中推动更高质量的代码。理想情况下，对于每个在精神上专注于功能的项目开发人员，您都有一个相反的开发人员，他们在精神上专注于破坏代码（从而使其更好）。
从这个角度来看，与其说将开发人员用于测试人员，不如说是一种脱节的结对编程，其中一个开发人员强调控制质量。
另一方面，坦率地说，很多测试（比如基本的 UI 功能）并不需要那种技能。这就是乔尔的观点。
对于许多企业，我可以看到一个系统，其中编程团队为彼此的代码权衡代码审查和测试职责。例如，业务逻辑团队的成员可以不定期地巡回测试和审查 UI 团队的代码，反之亦然。这样，您就不会在全职测试上“浪费”开发人员人才，而是获得将代码暴露给（希望）专家审查和惩罚的优势。然后，一个更传统的 QA 团队可以进行“黑盒”测试。
于 2008-08-18T01:08:58.443 回答
9
在适当的时候，质量控制团队应该能够进行安全、回归、可用性、性能、压力、安装/升级测试，而不是开发人员
开发人员应该对正在编写的代码进行单元测试，并将代码覆盖率作为最低目标。
在这两者之间，还有相当多的测试要做
- 完整的代码路径测试
- 组件测试
- 集成测试（组件）
- 系统（集成）测试
- ETC
基于对最有意义的一些共同协议，这些责任在质量保证和开发之间混合。某些组件测试只能通过单元测试来完成，而其他组件测试则在集成测试期间“充分”测试等。
互相交谈，找出每个人最舒服的做法。这将需要一些时间，但这是非常值得的。
于 2008-09-17T03:35:50.477 回答
8
应该总是有一些开发人员测试。如果开发人员产生了太多的错误，那么他/她就是在浪费时间修复这些错误。重要的是，开发人员不要形成这样的态度：哦，好吧，如果我留下一个错误，它就会被抓住，我将有机会修复它。
我们试图为产生的错误保持一个阈值。如果在测试期间超过此阈值，则开发人员应对此负责。由您决定这个阈值是多少（对我们来说，它可能因项目而异）。
此外，所有单元测试均由开发人员完成。
于 2008-08-18T00:24:24.243 回答
4
我在这个行业只工作了一年，但根据我的经验，开发人员负责对其功能进行单元测试，而 QA 负责测试场景。QA 还应该测试任何边界条件。
于 2008-08-18T00:26:17.420 回答
3
我将我的答案粘贴在我们的内部论坛上。如果你有一个小时左右的时间……听听 Mary Poppendieck 的基于 Speed的比赛视频。受到推崇的
注意（由测试人员 - 我指的是 QA 团队）
开发人员/单元测试________=_______ 可用性测试和探索性测试
'================================================== ==================
验收/客户测试___=_____属性测试
想象这是一个有四个象限的正方形。:)
左半部分应该是自动化的。
- 开发人员测试验证代码是否按照编码人员的要求工作。工具：NUnit / xUnit / 任何自制工具
- 客户测试验证代码是否按照客户的要求工作。测试应该很容易编写，不应该要求客户学习 .NET/Java。否则客户不会编写这些测试（尽管他可能需要开发人员的一些帮助）。例如，Fit 使用可以用 Word 编写的 HTML 表格。工具：FIT 回归工具也在这里。记录回放。
右半部分更好地利用了优秀测试人员的时间和精力。例如，没有自动化测试可以告诉您 X 对话框是否可用。人类在这方面比机器做得更好。
- 可用性。尝试打破系统，（捕捉未处理的故障场景，输入空值）。基本上抓住了开发者遗漏的东西。
- 属性测试再次需要人类。您可以在此处检查系统所需的客户强制属性。例如性能 - 您的搜索对话框是否满足 2 秒的响应时间？安全性——有人可以侵入这个系统吗？等可用性 - 您的系统是否有 99.99% 的时间在线？
测试人员不应该花时间在左半边执行测试计划。这是开发人员的责任，以确保代码按照客户和开发人员的预期工作。测试人员实际上可以帮助客户制定验收测试。
于 2008-08-18T06:46:35.080 回答
3
测试应该尽可能地自动化，如果测试人员正在编写添加到自动化测试套件的代码，这会将其重新投入开发工作。
此外，我发现我们在代码审查中完成了很多 QA，因为人们会建议他们希望看到的额外边缘和角落案例添加到正在审查的单元测试中（当然还有他们测试的代码） .
于 2008-09-17T03:41:53.787 回答
2
我的一般立场是测试人员永远不应该发现单元级别的错误（包括边界情况）。测试人员发现的错误应该在组件、集成或系统级别。当然，一开始测试人员可能会发现“快乐路径”错误和其他简单的错误，但这些异常应该用于帮助开发人员改进。
您的部分问题可能是使用每小时 100 美元的开发人员和每小时 30 美元的测试人员:}。但不管成本如何，我认为知道在开发周期早期发现的错误不可避免地会更便宜，您可能仍然可以通过让开发人员进行更多测试来节省资金。如果你有一个高薪的开发团队和黑客测试人员，你可能会发现很多明显的大问题，但是你会错过很多以后会回来困扰你的更模糊的错误。
所以，我想你的问题的答案是测试人员应该尽可能多地进行测试。你可以解雇所有的测试人员，让开发人员完成所有的测试，或者你可以雇佣一群测试人员，让开发人员检查他们想要的任何东西。
于 2008-09-15T20:45:00.303 回答
1
有 2 种类型的 QA 团体，即那些想要维持现状的团体。我们一直这样做。他们自然会讨厌并摆脱那些试图让事情变得更有效率并因此超越他们舒适区的人。这不止一次发生在我身上。不幸的是，质量保证经理和他们的质量保证团队一样无能。因此，过去 6 年一直在管理的 QA 经理会扼杀任何自动化，会引入大量流程来证明它们的存在。这是高层管理人员的责任，要认识到这一点。有一些了解工具的技术 QA 人员。不幸的是，编程语言不是一种工具，而是一种愿景。与这些人一起工作实际上取决于他们愿意学习多少，以及管理层愿意承担多少改变事情的风险。测试的编写方式应与编写主代码的方式相同，即编写易于维护的面向对象结构。我确实认为，开发人员应该审查 QA 测试。大多数时候我发现自动化没有测试任何东西。不幸的是，qa 工作被认为是低级的，所以开发人员不会打扰。我自己很幸运，当我得到团队中一位有影响力的开发人员的支持时，他愿意向经理解释我的努力。不幸的是，它只工作了一半。恕我直言，测试人员应向开发经理报告。并且所有团队都应对 QA 测试实际测试的内容负责。我自己很幸运，当我得到团队中一位有影响力的开发人员的支持时，他愿意向经理解释我的努力。不幸的是，它只工作了一半。恕我直言，测试人员应向开发经理报告。并且所有团队都应对 QA 测试实际测试的内容负责。我自己很幸运，当我得到团队中一位有影响力的开发人员的支持时，他愿意向经理解释我的努力。不幸的是，它只工作了一半。恕我直言，测试人员应向开发经理报告。并且所有团队都应对 QA 测试实际测试的内容负责。
于 2013-09-25T23:47:23.070 回答
0
以下是开发人员测试最有效/回报最高的一些方法：
- 开发人员在处理功能时修改共享库 - 开发人员可以深入了解 QA / 验证没有的可能副作用
- 开发人员不确定库调用的性能并编写单元测试
- 开发人员发现代码必须支持的规范中未考虑的用例路径，编写代码，更新规范，编写测试
在第三个示例中，开发人员应该执行多少测试任务是有争议的，但我认为这对开发人员来说是最有效的，因为来自多层文档和代码的所有相关细节都已经在她的短期记忆中。事后测试人员可能无法达到这种完美的风暴。
我们是在谈论 QA 还是验证？我认为 QA 包括检查清单、代码标准实施、UI 指南等。如果我们谈论的是验证，开发人员花大量时间编写和执行正式的测试用例是没有意义的，但是开发人员必须提供编写良好测试所需的所有基本原理和设计文档。
于 2008-08-18T00:32:30.280 回答