如何向产品负责人提供单元测试的评估？

Question

“他的开发人员编写单元测试需要多长时间？”这正是项目所有者一直在问我的问题。问题不在于编写单元测试需要多长时间，而是TDD (特别是单元测试的编写)在以后的开发过程中给我带来了什么。

我总是回答“这要看情况，有些不会持续很长时间”，但是作为一个测试经理，我不能给出一个精确的说明。我总是建议在短跑计划中使用时间框。

但不幸的是，我被这个问题问得过头了，因为PO‘S真的想把这个作为一个可计算的单位。

那么，您如何计算至少粗略估计每个任务或每个sprint编写单元测试所需的时间？

您如何计算大小，以及哪个时间单位？

Answer 1

我想说，这个问题不会给出任何有意义的信息，如果你作为专业人士在实践中受到质疑，你应该表明立场。

我先从问题本身开始：

鲍勃叔叔的TDD的三个规则：

除非是为了通过一个失败的单元测试，否则你不能编写任何生产代码。2 -You不允许编写更多的单元测试，这足以导致失败；编译失败就是失败。3-您不允许编写更多的生产代码，这足以通过一个失败的单元测试。

这些规则意味着您将被“困住”在一个循环中：

1-编写一小块测试(可能只是一个MyObject obj = new MyObject())，它会崩溃，因为您没有类MyObject。

然后创建一个名为MyObject的类，使所有测试都通过。

然后再写一些测试：

Assert.equals(obj.name, null, "Default name is not null")

然后创建一个名为null的属性，使所有测试都通过。

然后你写更多的测试..。

这些步骤中的每一步都有几秒长，您一直疯狂地跳在测试代码和生产代码之间。编写测试的行为嵌入到编写生产代码的过程中，反之亦然。

那么，编写这个单元测试需要多长时间？也许您可以使用一个文本编辑器插件来跟踪您在测试文件夹中写入文件的时间。这些信息有用吗？可能不会。

也许你的主管会问：

但我们想知道TDD是否有积极的投资回报..。

我们不问医生为什么他们花时间清洗双手10次，每根手指的两侧和指甲下面都有10次划痕，这是因为他们是专业人士(字面上说是专业的)。他们对自己的手艺负责。

会计师使用复式簿记，这基本上是TDD的过程:在资产列上迈出最小的一步，然后在负债列上做出等效的操作，然后检查一切正常。

TDD是一种软件工艺实践，它的实现是因为有必要生产高质量的软件，它允许以安全的方式进行更改和改进，质量不会被贬低。

如果PO不重视这一点，并且更愿意(在财务上)处理设计糟糕的软件的后果，那么没有问题，但他/她将很难与那些看重高质量技术的专业人士打交道。

Answer 2

与应用程序代码一样，尝试在低级别(如小时、几天或几周)进行时间估计不仅是一种挫折(以及大量的浪费精力)，而且不可避免地会导致(正如我们所了解的)低质量。最后，质量是可选的，也是第一件可以削减的东西。

开创性的书“囚犯们正在管理庇护”首先向我揭示了这一点，在此后的20年里，其他作者也在这方面写了很多文章。

这是合理的，公司需要知道什么时候做的事情，以便他们可以计划许多其他相关的活动。因此，“第一季度我们将有一个新的版本”是好的。然而，一旦你开始沿着'x变化，需要y时间，需要z人‘的道路，它就会变得很混乱。快地。看“神话中的男人月”。就像上面说的：“9个女人一个月不能生一个孩子”。注意:新版本应该以极小的数量发布，而不是一次性发布(否则我似乎在推荐瀑布)。

问题是，与你打交道的人不知道/看到/认识/理解这一点。因此，任何向他们‘解释’的尝试，特别是在飞行中，都可能适得其反，使他们背起背来，增加阻力。他们期待一个日期，也认为期待一个日期是合理的。试图抹黑这将增加目前和长期的阻力。

这就需要高级别的领导给出明确的方向。

一旦完成了这个任务，你就可以把领导给出的方向作为对你努力的辩护。这几乎是我所知道的在这些情况下取得进展的唯一途径。确保它不是

“你和你的意见试图说服他们”

确保它是

遵循公司的方针和目标，以更高的质量，更快地前进，赚更多的钱(或任何东西)

你也可能认为答案是不能孤立地决定的。如果被问到，问题应该是‘编写应用程序代码的时间(必须包括附带的测试)。

一个典型的发布过程可能有多个阶段：

• 进入故事
• 分配故事
• 编写代码和测试故事
• 对新代码执行代码检查
• 将测试发布到暂存环境
• 执行集成测试
• 执行UI测试
• 执行性能测试
• 执行可用性测试

试图估计所有这些部分是一项巨大的努力(而且一点也不敏捷)。

你真正关心的是活动的滞后。如果您实际将实际时间添加到代码、测试等，您可能会得到12个小时的工作。问题是，由于所有的切换和处理12小时需要2周。或者更长时间。解决这个问题的办法？更多的过程？更多的估计？不是的。我建议：

• 过程和工具上的个人和交互
• 基于综合文档的工作软件
• 合同谈判中的客户协作
• 响应按计划进行的变更

https://agilemanifesto.org/https://agilemanifesto.org/

如果这一切都失败了:给你的新工作

Answer 3

其他答案为您提供了一些很好的理由，说明为什么您所要求的度量标准并不特别有用。您需要的是提供有用的度量来提供POs。要得到它们，您可能需要进行一些数据搜索，并与每一个参与其中的人交谈。

你要寻找的东西是(所有这些你都在寻找平均值，并尽你所能过滤掉特殊情况)：

• 您的开发人员通常需要多长时间才能生成一个工作的、经过单元测试的代码段--例如，在迭代中处理的一小部分功能。
• 您的测试人员通常对工作的、经过单元测试的代码有多少问题，以及需要多长时间才能完成单元测试的修复。
• 一旦单元测试和测试测试软件发布，客户通常会报告多少问题。要获得这些信息，您可能需要从伪装成问题、误解、客户过于挑剔和报告多年来满意的事情的特性请求中筛选实际问题，等等。您专门在寻找您所引入的更改的问题，而不是其他任何地方。
• 同一团队在没有单元测试的情况下编写相同类型的功能通常需要多长时间(取决于软件的复杂性，这可能是从更少到更多)。
• 测试人员在没有单元测试的软件中有多少问题，以及修复这些问题需要多长时间。(对于任何复杂的情况，这一测量结果可能会更糟糕)。
• 客户使用新功能报告了多少问题(这也可能更糟)。
• 通过运行测试作为构建过程的一部分(然后立即修复，而不是访问客户)，有多少潜在的问题被捕捉到了？

你想要的是你的数字来讲述一个故事，最好是你想让他们讲的故事。单元测试编写(可以不到一分钟)所需的时间并不能讲述一个故事--当它真的是保险时，它看起来就像是一个潜在的可移动的“成本”。

花费在单元测试(以及集成测试和其他自动化测试)上的时间的真正价值在于确保此更改不会破坏该特性。当我使用很少进行单元测试的软件时，具有单元测试和集成测试覆盖率的部分比无法进行单元测试的应用程序部分要健壮得多--而那些具有合理UI层自动化功能的部分比没有的部分更稳定。这是您的数字需要讲述的故事，如果您已经获得了原始数据，您的数字应该(也可能会)告诉您。