如何最好地向管理部门提供单元测试？

Question

我正准备向管理人员介绍单元测试。我的团队多年来一直在编写单元测试，但该公司的其他领域似乎很难采用它。我可以让开发人员对此感到兴奋，但如果没有管理层的支持，它就不会成为标准。

你们有没有建议如何最好地处理这方面的管理？你曾经尝试过哪些有用的东西？什么东西不起作用？

Answer 1

对于非技术经理人而言，我已经贬低了建造房屋的类比。他们会在没有蓝图的情况下建造一个，只是从一堆砖块中取出砖块并将一个砖块放在另一个上面，并考虑到一个模糊的房屋形状的想法吗？如果没有，那么为什么他们不会在编码，设计评论等之前接受适当的文件？

对于单元测试，您可以尝试将它们与各个房屋组件的质量测试进行比较，然后将它们放在一起（砖块，水泥，门，窗户，管道）

对于那些掌握任何技术的人，我提到30％到50％处理错误条件和恢复（在关键任务的嵌入式系统中），并且如果没有单元测试你就无法测试它。 EG，如果你只进行黑盒集成测试那么你怎么能 - 以受控和可重复的方式 - 测试模块A无法在给定点分配内存时发生的情况，或者在等待回复消息时超时在模块C中到期从某个地方，或通常成功的数据库读取。解释一下，通过愚弄接口模块，你可以随意模拟他们的错误行为。

当然，我用一个轴上的$符号和另一个轴上的时钟绘制我的favouriite图。我凭借这一点击败了管理层，每次都有机会证明获取错误的成本会增加后来发现它们（在需求规格中更改一行 - 5分钟;设计文档中的几个小时 - 几个100代码行（在代码审查或单元测试阶段） - 天;在大海捞针中找到针并在系统测试中纠正它 - 周）。

这不仅仅是单元测试 - 您必须说服管理层 - 以及您的开发人员 - 文档，评论，测试的“不必要的开销”... s / w一般的流程（包括学习新工具）。 ..实际上节省了时间而不是为项目增加时间。换句话说，错误需要更长的时间和更多的成本。测量两次，切一次等

对于单元测试，请告诉他们continuous integration。我强烈推荐詹金斯，但使用适合你的任何东西。说明定期构建，无论是每晚或每次办理登机手续，都可以自动从VCS中提取单元测试并运行它们，发送电子邮件或以其他方式警告新代码，这些代码几乎会在发生现有测试时立即发生。

如果这些都不起作用，找一份新工作（如果你在新加坡，或想成为，请跟我说话; - ）

Answer 2

向他们展示一个示例，说明测试已经解决了问题并节省了一天。

Answer 3

不要误导。

当您引用降低成本时，您暗示质量保证和更容易重构的成本高于创建和维护测试的成本。最好指出这一点并尝试制定一些指标来支持你的观点。

问题在于你不能在没有采用的路径上加上一个美元价值（“我们避免了1000个需要花费100万美元修复的缺陷！”。）

但是你应该事先了解创建测试需要付出的代价，并且必须对它们进行维护。如果你创造它们，然后让它们年久失修，你就会一样糟糕。

当您添加新功能时，您的论点会得到提升，因为您保持代码清洁，因此更容易。

Answer 4

我认为就非技术管理人员而言，统计数据会成为最好的案例。 Code Complete, 2nd Ed.总结了几项研究，显示单位测试导致平均30％的缺陷检测率（表20-2，第470页）。我认为应该很容易从那里采取它，并说明减少错误转化为更多的钱节省。

Answer 5

在某些情况下，我发现等待合适的机会是关键。

例如，在一个案例中，我等到有一个客户的热门网站。这非常痛苦（想想$$$）。高层管理人员提出的一个不可避免的问题是如何避免将来出现同样的问题。那是我向管理层提交单元测试的时候......

所以我猜这很大程度上取决于具体情况。

Answer 6

1 - 他们需要知道甚至批准吗？你是工程师，你比他们更了解如何构建有效的东西，所以他们真的不应该干涉。如果它是您为他们制造的新车型，他们会关心您使用的工具和质量/安全保障方法吗？不会这么认为。

2 - 缺陷成本非常非常高。低质量，缺陷和技术债务是一个非常严重的项目风险，可能会危及软件项目的整个投资。与缺陷检测相比，缺陷预防更容易实现成本效益（根据研究，许多倍数）。单元测试可以实现最短的反馈循环，从而避免系统的低项目质量，并显着降低项目风险。

3 - 在没有非常低的缺陷率的情况下，你不能长时间快速行动 - 也就是说，投资节省开支/投机（他们应该得到）。

Answer 7

告诉他们它使代码更易于维护，并且从长远来看可以节省资金。如果正确完成，它还可以减少错误。

换句话说，它降低了成本并提高了软件的可靠性。

Answer 8

要建立@hvgotcodes答案，不要只告诉他们如何让事情变得更好，从你自己的团队中编制一些统计数据

1. 减少转身
2. 降低成本
3. 减少回归
4. 等

特别是成本，企业喜欢省钱:)。

Answer 9

单元测试，如果做得好，应该

• 提前捕获错误，从而减少质量保证或生产中发现的错误数量，并降低修复错误的成本
• 支持重构，从而保持设计的清洁和可扩展性，从长远来看应该使维护更便宜

贵公司是否收集了可以具体根据这些索赔的相关统计数据？即质量保证/用户在不同产品中发现的错误数量，或平均错误修正/功能实施成本，......

Answer 10

如果可能的话，我会尝试提供真实世界的例子，告诉您公司过去在没有测试的情况下支持实时代码时遇到的困难。然后继续强调可能通过具体示例来降低更新和修复的支持成本已经进行了测试。

祝你好运，让我们知道你是怎么过的。 ：）

Answer 11

将其显示为Behavior Driven Development或Test Driven Development，而不仅仅是单元测试。

BDD和TDD都有上升空间，非技术人员很容易理解。事实上，他们的一个主要优势是他们专注于非技术性的。

另一方面，单元测试是一个技术概念，对于非程序员来说可能是非常抽象的。测试你的代码？你不是在开发时那样做吗？我们为什么要为测试人员付费？等等。

Answer 12

对管理人员可能定期使用的内容进行类比 - 比如他们的邮件客户端或文档编辑器中的拼写检查程序....