建立起来，测试下来

设置优先级是软件开发过程中重要且不可避免的部分。平衡开发速度和质量是程序员应该做出的基本折衷之一。为了确保质量，您应该发现破坏代码的方法。作为开发人员，您不想破坏您的实现。这种矛盾极大地降低了将开发和测试角色结合在一个人中的能力。对您的工作足够关键很困难。创作者需要一个对抗者，一个批评家，一个反派。

我喜欢TDD方法。从测试开始，首先要具有形状。用有效的代码填充脚手架，并立即获得有关您的进度的反馈，这是一个令人鼓舞和令人满意的过程。测试驱动的开发为流程提供了结构，替代了文档，并提供了团队成员之间的其他协作媒介。但是，我从来没有从避免幸福道路的测试开始。编写检查极端情况，不正确的功能输入和错误使用组件的断言，可以显着提高应用程序质量，但不会增加测试驱动的开发经验。从这个意义上讲，TDD与质量无关，而与开发过程有关。

因此，如果编写测试不是为了提高软件质量，而是为了作为功能验证框架而编写的，那么什么时候以及如何保护我们的产品免受崩溃和意外行为的影响？

在不同位置的不同团队工作之后，我得出一个结论，即独立的测试角色是提高软件质量的最有效方法。当然，您可以强制开发人员对测试进行100％的代码覆盖，在持续集成管道中引入质量检查器，并收集不同的验尸指标，但是不要期望开发人员会写出实际上会使他们的代码崩溃的测试。这需要以某种相反的方式思考他们在日常工作中的工作。

拥有没有交付期限负担的敬业质量工程师是对整体应用程序质量的一项重大投资。没有任何过程调整或其他工具可以替代专门的工程师，而后者的主要职责是发现破坏您所建事物的方法。“但是，嘿，您不是在谈论软件测试人员吗？”。我认为没有。这些角色在交付成果上看起来相似，但是在手段上却有所不同。通常，测试人员不要接触代码。

当然，拥有专门的质量保证工程师职位是一件很酷的事情，并且一个团队中的一个可以解决许多质量问题，但是有多少团队可以负担得起？我看到的是，没有那么多拥有专门的质量工程师的小型团队。这是很合理的，因为大多数团队都重视交付速度而不是质量。市场决定规则。

为了弥补缺乏专职质量工程师的作用，我建议练习交叉测试每个人的工作或临时转换角色。停止使用功能，并尝试从不同的角度看待您的代码。不是作为您心爱的孩子，而是作为狡猾的敌人。