逃脱缺陷

我想在这篇文章中插入一个拼写错误，只是为了讽刺。如果你找到了，请在评论中发表。

软件开发充满挑战。

“在敏捷世界中，烘焙质量的缺陷预防 - 是规范，或者至少应该是。”

如果做得好，这类开发可以获得极大的回报，反馈循环几乎是即时的。

当团队进行测试驾驶时，软件开发的世界只是以不同的方式出现。

“工作的，被测试的产品是进展的主要度量，客户可以快速地识别变更的新功能的价值。”

自动化和质量是可以做出的核心，但不是每个人都建立了连续集成（CI）和连续交付（CD），以便今天建造的东西也可以在同一天测试和发布生产。

已经建立了所做的定义（国防部）的团队，包括守则质量标准和测试标准和自动化，享有不同的存在，而不是我遇到的绝大多数团队。

敏捷的天堂是罕见的

至少在我的经验中，它是。对于许多组织来说，开发与测试分开，开发人员可能不会与测试人员坐在一起甚至与测试人员合作。工作像一个人从一个人到下一个虚拟装配线移动;一个环境到下一个环境。对于许多组织来说，从开发到生产的旅程（左右）看起来类似于下图。

通过多种环境 - 通过多个环境的多个测试阶段进行测试 - 在其中任何一个中都可能出现问题。实际上，当软件未测试驱动时，可以认为这些环境中的问题可以被视为常态。

的帮助!缺陷正在逃逸

但当出现问题时，问题可能会让组织感到不适。逃脱的缺陷是一种痛苦，在它们进入生产之前找出它们是至关重要的。对于一些组织来说，“逃避缺陷”是在生产中发现的一个问题，但我认为这将标准设置得太低了。在我的书中，逃逸缺陷是在开发团队完成后发现的任何问题。这意味着一个单独的缺陷会被记录下来，在它离开上面图中左边用绿色表示的“开发环境”之后发现的任何东西。

逃逸的缺陷是一个关键的质量度量。发现缺陷的时间越晚，解决缺陷的成本就会显著增加。补救和重新测试都是增量成本，基本上是解决方案交付成本的两倍。对于每一个逃脱的缺陷，组织基本上是在为最初产生的缺陷买单，然后在纠正缺陷时再次支付。基本上，对于任何涉及缺陷的价值，至少要付出两倍的成本

在我看来，这些成本以非线性方式增加。发现后来的缺陷，它产生的回复越多。回流的成本意味着不仅是必须重建的功能代码，而且还有与之相关的测试代码。每个测试阶段可以具有由改变功能影响的单独的测试代码。根据缺陷的程度，成本可以指数增加。

解决方案当然是永远不要产生缺陷。要是现实世界也这么简单就好了。学习测试驱动和改进DoD可以帮助团队不断提高质量标准，并更接近缺陷预防，而不是仅仅依赖缺陷检测。随着团队的学习，国防部可以改变以反映新的能力。任何正在学习TDD的团队都不应该从80%自动化测试代码覆盖率的质量标准开始。这是不现实的，自动化测试代码覆盖可能不是要跟踪的最关键的指标。无论您选择何种度量标准，从您所在的位置开始，然后随着团队开发满足标准的能力而提高标准。

这是你需要知道的

我希望你们能从中得到三个关键的启示:

1. 传统的缺陷检测是一种确保质量的昂贵方式。预防缺陷是最终目标。只想认为我们只有今天在泰坦尼克号弓上的前瞻性雷达。
2. 尽早从软件工艺和采用测试驱动开发开始。敏捷组织不断努力朝着防弹质量，完整的堆栈测试自动化，CI＆CD，以及越早才能开始更好。
3. 目标是不仅仅是“做敏捷”，而且“敏捷”，逃逸的缺陷可以用作朝向这种敏捷性的晴雨表。随着它们的数量下降，敏捷性上升。

现在，宣战关于逃脱缺陷的战争

敏捷的道路有时可以长期缠绕。您的代码和产品质量是成功使其成功的核心。宣战对你的逃脱缺陷！通过指定在团队宣布为逃脱缺陷之后宣布故事的每个问题来追踪您正在遇到的回流量。生活在瑕疵的痛苦中，使用缺陷作为迫使杆提高质量。缝合和Hawining at the缺陷只应记录泥泞的水域。如果一个团队表示已经完成，然后稍后发现更多的工作，请宣布它是一个缺陷，并了解您的流程，技能集，工具或任何内容需要改变什么，以防止未来类似的缺陷。

你找到了错字吗？我可能没有心脏添加它。

快乐的旅行。