现在，在软件开发这样的热门行业的经济周期的高峰期，数钱已成为惯例。 从原则上讲，此过程通常被定位为一项创造性活动，无需证明任何理由，而艺术家则更了解什么以及如何写作。 特别是，关于单元测试和TDD的争论很多，但是，不幸的是，它们都陷入了未经证实的陈述和情感攻击中，方法论者通过成功地选择文章和书籍的证据证实了这一点，这些人从咨询和销售培训中获得收益，反过来，它们绝对不包含任何统计数据或计算结果，或者相反，它们完全包含对smushylebstvo的指控和其他青年罪恶。
与类似的空论点不同，本文将不仅为您提供思考的机会，而且还为您提供了一种评估在特定项目上引入单元测试的经济可行性的方法。 我将立即强调，与任何评估一样，我们对单元测试实施项目的评估将基于对产品，团队和各种指标的未来的假设，这些假设只能主观评估。 尽管如此，当程序员对至少与他的活动领域相关的指标进行专家评估时，情况要比直接问他使用公司的测试是否有利可图要好得多。 最后，程序员通常甚至不愿意考虑基本的财务指标，不仅开发人员，而且测试人员和管理人员都可以评估编写测试所花费的时间或在没有测试的情况下出现严重错误的可能性。
费用是多少
首先，如果我们要计算任何东西的成本，那么我们至少必须首先大体上理解什么是价值。 当我们购买香肠面包时，不会出现这个问题，因为价格标签挂在下面。 但是对于该项目，我们不是一次性付款，而是长期持续的现金流，我们先进行投资，然后再付款。 为了正确评估它，您需要考虑到明天收到的钱将比今天少。 如果香肠是通过订购出售的，那就不难了，可以通过将通货膨胀率减去以后的付款额来计算订购成本。 但是，在项目方面，我们需要考虑到公司投资于该项目，不仅希望补偿其成本，而且希望赚取足够的钱来承担其风险。 风险是巨大的，但最终归结为以下事实：无法保证在项目实施中投入的资金回报，而且预测不佳。 钱可以带到银行，也可以借给一些强硬的借款人，并保证可以定期支付利息，但是您无法投资于一个项目，因此最终会按计划产生可预期的支出流量。 因此，从投资者的角度来看，在这种情况下，对于公司而言，按项目产生的所需回报率（也称为净现值）折现的现金流量应为正：
为了进行计算，我们需要知道项目在第一年，第二年，第三年等会带来多少收入或吃多少钱，以及贴现率，贴现率不仅应该比在银行赚钱更多，而且还要承担风险。
实际上，这是一个简化的公式。 严格来说，比率会逐年变化，因此在分母中应使用WACC1 * WACC2 * WACC3等，但实际上即使是专业评估师也忽略了这一点，因为 借助WACC计算方法，市场对未来利率的期望已经纳入了今天的利率，因此对此做出假设毫无用处。现金流有不同类型，但是出于公司的目的，我采用了最方便的现金流，该现金流不仅考虑了欠所有者的钱，还考虑了欠债权人的钱。 当然，大多数IT公司之所以没有明显的债务，仅仅是因为没有人没有抵押就将其贷出，而且它们也没有任何质押，但是也有例外，例如，这种方法在评估贷款制造公司的内部开发中的项目时会很方便。 。 FCFF之所以引起我们特别关注的第二个原因是其计算的简单性，FCFF就是营业利润减去税金，净资本成本和营运资本的变化。
由于FCFF同时是所有者和贷方的现金流量，因此按拥有和借入的资本成本的加权比率对其进行折现。
在大型公司中，资金成本由财务部门监控，因此您可以提出要求，但是对于一般情况，我们仍然需要一个公式来计算WACC：
这里Re是权益成本，Rd是借入资本成本（即公司债务的有效利率），P是权益的市场价值，EV是企业的总成本（EV = P + D，其中D是债务）。
接下来，我们需要确定Re，为此存在不同的模型，但是最简单的方法是采用CAPM模型，其中Re = Rb +β* Premium，其中Rb是无风险利率，Premium是股票投资收益的溢价，而不是借入，β是一个风险因子，它表明我们的项目相对于某家普通公司的业务而言风险更大。
如何确保质量以及进行哪些单元测试
现在我们需要确定什么是单元测试。 奇怪的是，很多人，甚至是接近开发的人，都经常将任何自动化测试称为单元测试，但是事实并非如此。
测试分为功能性和非功能性。 非功能性包括与软件功能不直接相关的事物，例如，负载测试或与安全性相关的测试。 但是，功能性仅意味着检查对要求的符合性以及在实现中是否存在错误，将对此进行专门讨论。
确保质量的第一件事是从开发人员手中获得控制功能，并雇用负责该功能的人员。 因此，测试人员会出现在团队中，他们正在进行手动测试。 没有人工测试，就不会有一个严肃的项目是根本无法想象的；这是该项目迫切需要的基础，及时发现和纠正的绝大多数问题将是测试人员的优点。 在此阶段，一切看起来都很简单：如果您想要质量，请雇用质量专家。
随着项目的发展，手动测试的时间将越来越少，因此测试人员将越来越忙于使用新的系统功能，并且越来越少的人会检查系统中那些不应更改的部分。 但是，随着系统复杂性的增加以及在其组件之间可能会出现显式和隐式依赖关系（开发人员理论上可能会忽略它们）的可能性，建议每次发布前都进行一些检查仍然是可取的。 在具有短迭代和频繁发布的灵活方法中，这个问题尤其严重。 从逻辑上讲，这意味着需要使测试人员的工作自动化，例如编写脚本以单击按钮并检查结果本身，或者使用功能更强大的工具将普通的测试人员转变为能够使工作的日常工作自动化的自动化测试专家。
这些措施可以提供不错的质量水平，但完美无极限。 测试人员所做的事情称为黑盒测试，其职责是不了解实现的所有功能，因此测试通常着眼于典型场景，并且没有设定破坏系统或在非典型条件下检查系统行为的目标。 此外，某些事情由于缺少接口而难以验证，例如，如果迭代的目标是开发用于访问数据的库或某些特定的API，要对其进行测试，则需要编写一些应用程序或至少编写一些将使用此组件。 在这种情况下，您必须将质量控制功能部分退还给开发人员，并要求他们编写集成测试。 这是在项目上使用的第二种自动测试。 他们的目标是测试由不同人员编写的系统组件之间交互的正确性，在临界条件下测试这些组件的行为以及对环境故障做出反应的正确性。
好吧，我们有测试人员对整个项目进行测试，以确保它们符合要求，有一些测试可以使他们的工作自动化，还有一些测试可以测试由不同开发人员编写的项目部分，还有什么可以做的？ 单元测试声称是质量控制的第四级。 他们检查由一个程序员编写的代码，通常，他们测试代码的最小部分，这基本上适合于测试，例如，单独的类。 实际上，大多数情况下，开发人员自己为自己的代码编写单元测试，并且它们的数量和需求均受到控制。 根据我的观察，大约40％的时间用于开发功能部件本身可被称为开发人员在单元测试上花费的典型时间，尽管该比例可能会有很大差异。 SQLite项目的开源案例研究是众所周知的，由于大量想从事一个知名项目的人提供的低技能自由劳动力过多，该劳动力以军方的方式被利用，即通过编写无用的单元测试，其数量在一定程度上DBMS本身的代码量的100倍。 没有编写单元测试或最小化编写单元测试的相反情况也不足为奇。 最后，几乎所有开发到零末期（即在外包和敏捷时代之前）的软件都是在没有单元测试的情况下创建的。
成本，复杂性调整和神话般的人月
当然，如果您需要编写单元测试或其他内容，则将不得不花更多的时间在项目上，或雇用其他开发人员。 在这种情况下出现的主要问题是，开发时间和成本对代码量的依赖性是线性的，还是遵循其他定律。
曾几何时，我在臭名昭著的Assembla服务上拥有免费的SVN存储库，该存储库提供源托管服务和协作工具，即跟踪器，统计信息和其他废话。 后来免费赠品终止了，但是他们没有停止发送新闻通讯和通知。 因此，在2015年，他们的员工发布了一条简短的帖子，标题为“应该讨论多少人？” 现在，仅将其保存在
Web存档中 。 该职位的本质如下：该员工收集了有关客户的统计信息，绘制了任务持续时间与讨论该任务的人数的关系，结果如下：
可以看出，相关性是非线性的。 通常需要两个人来解决持续两天的问题，三个人-四天，而四个人-已经六天。 他们在那里做什么？ 我们可以假设该任务需要几个工作阶段，例如，在两个人的情况下，Vasya完成了他的部分任务，然后将其转移到Petya，因此持续了两天。 三人已经可以吵架，再一次分担责任，找出应该归咎于谁，该做什么。七个人组成的小组将再花六天时间互相讨论，谈判和互相支持。
当然，也可以假设一个由七个人组成的友好团队的艰巨任务要简单得多，并且人们越忙于这项任务，因为友谊是神奇的，所以任务就越多！ 因此，这些考虑因素似乎牵强，我不会在以后的计算中包括这些因素，但是，如果您想获得更保守的估计，就不会随着项目代码库的增长而对成本增长的非线性进行校正，这当然是不合适的。还包括单元测试，或在NPV水平要求中留出一定的安全裕度。
如果我们仅通过团队规模的增长来解释此计划的非线性，那么可以从下表根据沟通所损失的时间份额对工作组规模的依赖性来估算与该计划相关的成本：
例如，如果一个团队中有五个开发人员，并且您认为需要雇用两个开发人员，以便每个人都可以将其40％的时间用于单元测试，请为开发成本可能增加40％以上的事实做好准备。 团队将成长并变得不那么有效，而不是5 * 0.625 = 3.125常规生产力，它将具有7 * 0.539 = 3.77生产力，工作量将从1常规工作量分别增加到1.4常规工作量。将增加16％。
可以从图表中得出一个有趣的结论，当人数超过十时，每个新参与者的价值就会小于交流的额外费用，布鲁克斯法则开始起作用。 剩下的只是尝试将任务分解为较小的任务，或者让更多经验丰富且高效的员工参与执行。当然，很难说来自Assembla的图的非线性仅与团队的成长导致效率降低有关，但与对复杂性和布鲁克斯定律的直观理解高度吻合，因此，如果您不想冒险并且需要保守的估计，则此数据可以成为一个很好的帮助。
单元测试的好处
除成本外，单元测试还带来好处。 当然，在大多数情况下，单元测试可能捕获的错误将在其他级别的质量控制中被捕获，但是始终存在技术故障的可能性，并且理论上单元测试可以减少这种故障。 就我个人而言，我不知道这样的情况，幸运的是，我与之合作的所有测试人员都是非常负责任的人，但是当涉及到如此低的概率时，个人经验可能就没有代表性。 失败可能会产生不同的后果，例如一家公司可能有一项SLA，违反该SLA会造成一定的财务损失，例如，该公司将被迫向客户提供一个月的免费使用服务作为补偿，从而损失了收入的1/12。 在这种情况下，加强质量控制可以将一年中违反SLA的可能性从10％降低到8％，这将使年平均损失减少约0.17％的收入。 这笔钱将是现金流量的正组成部分，需要将其添加到模型中。
请注意，这种简单的计算仅在损失概率较低时才适用，如果损失概率高于15-20％并可能导致公司破产或清算，则建议使用可选的估值模型，例如决策树。 幸运的是，在大多数情况下，某种愚蠢的错误不会使公司破产，因此我们无需沉迷于计算期权成本的恐怖活动。示例一：野牛
野牛是一家大型在线商店，他们自称为俄罗斯第一大在线零售商。 该公司不是公开的，但在最近的一次资本重组交易中，其总资本估计为500亿卢布，是年收入的两倍。 由于经营亏损，需要额外的资本化，但是股东希望在公司成功获得更高的市场份额并在一年内使收入翻倍之后，实现10％的经营利润率，此后必须开始盈利，收入增长将会放缓第二年提高到30％，第三年提高到20％，最终在第四年及以后的几年达到10％。 但是，银行对此并不十分确定，因此请谨慎对待Bizon，该公司的总债务仅为100亿卢布，比率为11％。 Bison在运营层面上是一个相当笨拙且管理不善的公司，员工的无节制雇佣已经导致了这样一个事实，即它雇用了600名程序员，他们的总薪资预算为每年15亿卢布，并将约30％的工作时间用于单元测试。 该公司对客户没有义务，技术故障只会导致暂时停止销售，如果发生故障，回滚到旧版本的站点大约需要一个小时。
在野牛中使用单元测试得到的NPV是多少？
50, 65, 78 86 , , . 33%, , , . , 25% , DDOS . , 0,023% , 12 . , 11,5 , 14,8 , 17,8 19,6 .
, 450 .
, , , . , ! , - , , .
, , 10% , , -438, -480, -527 -579 , , , 10% . , , 20% , , 0.8: -351, -384, -421 -463 .
EV 50 + 10 = 60 , P 83% , D 17%, , 11% , WACC . , , 7,6%. , 4-6% , 5%, β (unlevered beta) 1,3. , , (levered beta):
WACC
, , , , 10% .
,
,
.
10% ,
, :
.
.
:
– . , , . , , , 50 . . .
在瓦西里（Vasily）参观车间的过程中，负责生产的专家大体上对他说：“亲爱的同事！请注意这个巨大的熔融金属桶。如果出了问题，我们不仅会灰心丧气，还会面临技术难题。事实是，如果高炉上升，里面的金属会变硬，并且要花三个月的时间才能消除事故的后果。 “在车间中处理一块巨大的金属并用新的高炉代替它并不容易。”瓦西里后来发现，高炉紧急停车可能使该公司损失80亿卢布。问题：Vasily是否担心编写单元测试？, : . , ( 50, - 10, ), , . , , - , , 100 10% * 8 = 800 .
: XSoft
XSoft是一家成功的外包公司，刚刚与另一位西方客户签订了合同。客户计划雇用7位程序员，他在这部分的预算为每年1500万卢布，其中XSoft将花费300万卢布。客户是牛d，对开发过程一无所知。从XSoft的角度来看，开发人员应该编写单元测试吗？! , , -, , - . , , , .
后记
, , . , . , , NPV / IRR. , IT. Excel .