作为开发人员，我们应该遵守这样一句话：“质量不是来自检查，而是来自生产过程的改进。”——爱德华·戴明
“测试即代码。”
太多的组织将任何未编码的东西视为一次性的。很明显，测试是必不可少的，但我们一次又一次地发现，团队将测试自动化和相关材料视为二等公民。测试是用户行为的文档，与产品组织产生的需求密不可分，并在虚拟层面与用于创建功能的代码相连。 如果它提供了价值，就应该对它进行版本化、维护、照顾和尊重，就好像它是产品本身的核心功能一样。这应该包括测试用例规范、设计和技术文档以及错误报告。
“时间扼杀信心。”
大多数人可能会认为，在一个功能上花的时间越多，就需要花越多的时间来完善、完善、测试和探索它。与直觉相反，这适合“旧世界”风格的开发，有一个测试环境、一个阶段环境，以及围绕用户将如何与之交互的许多宏大假设。 这些法则试图将SDLC（系统生命周期）引入云计算世界：微小的、渐进的变化，在推广到整个世界之前，先向有限的受众推广。“键盘在10分钟内完成生产”——这会带来更快的反馈、更少的逃脱和更高的信心。以下是编码新世界的10大法则。
1.人人皆测试
团队的每一位成员，无论使用什么流程，无论生产什么产品，无论哪个行业——每个人——都对产品的质量负责。产品、工程、测试，甚至周围的功能：客户支持、销售、营销、业务开发、早期访问测试版客户、高管——每个人都在测试。
2.度量风险而非覆盖率
假设团队甚至可以就“完美”的工作定义达成一致，那么仅仅追求完美就会导致注意力从最重要的事情上转移：关键缺陷转移到生产中对业务的风险。 在你开始担心所有功能的全面覆盖之前，先痴迷于对你的业务最关键的六个用户流。
3.测试的是“金钱”想要什么
每个业务、每个部门和每个团队都部署了一组核心功能，这些功能对收入的影响比其他功能更大。或者，每个团队都必须维护一组影响较小但仍然必要的功能。在考虑其他因素之前，将测试工作重点放在影响收入的部件上。对于电子商务，将结账流程优先于用户配置文件。对于财务，优先考虑安全和资金处理工作流程，而不是信息页面。
4.广度比深度更重要
浅层测试产品的所有区域比深层测试产品的某些区域更重要。业务逻辑的深度、多元组合旨在找到最模糊的边缘案例：这可能会在其他高优先级领域遗漏更明显的缺陷。 一旦达到了广度，那对某个特定功能的深度是多少？请参考法则2。
5.唯一完美的信号是用户的信号
在你的用户与你的软件交互之前，你所做的一切都是理论性的。 测试就是模型。它们是基于从过去用户行为中获得的信息的用户行为的近似值。我们从测试中得到的信号可能因环境、测试本身的逻辑缺陷、无意识的偏见，甚至之前模型中的错误数据而存在缺陷！ 了解用户使用软件时会发生什么的唯一方法是观察用户使用软件后会发生什么。生产分析的用户旅程应与测试覆盖率相关联，以评估测试策略的有效性。 此外，考虑到用户体验中包含的元素甚至不会被视为bug，也可能不会反映在分析中。当构建变为绿色时，并不意味着就是工作的结束。
6.代码在可测试（并经过测试）之前是不完整的
可测试性是对代码的各个部分进行检测的行为。如果不允许对这些信号进行轮询和解释，很难判断正确的行为。这导致了不成比例的额外工作，这增加了发布周期的时间，并将焦点从客户体验上转移开。时间将会扼杀信心。
7.每项测试都应导致明确的行动
如果不知道当测试失败时该怎么办（无论是从测试的角度还是从产品的角度），那么测试就没有提供价值。 这通常是由于测试步骤太多，或者产品没有提供足够的失败信息（包括没有充分的可测试性，参照法则2。）
8. 始终测试高层级
软件测试有“层”（从高到低）：生产、UAT、功能、集成和单元。 高层测试对于强制不同团队开发的不同组件之间的交互至关重要，但边缘案例的细节可能会向下移动到较低层。这些较低层测试具有较少的依赖性，避免了昂贵的管道配置/编排，并且运行速度比较高层测试更快。 例如，UI测试应该仅用于确定用户界面是否能够呈现API的输出。如果通过同一个UI重复测试业务逻辑，则应该将这些测试中的大部分“向下”移动到API层。
9.从不链接测试
所有测试都应在不考虑任何其他测试状态的情况下执行。测试数据的管理应确保每个测试都生活在自己的独立场景中，并且不能被另一个测试更改。 测试应该是原子化的、自主的。
10. 首选最紧密的反馈回路
所有测试都是反馈回路。他们从特定的角度贯穿产品，并向特定的人或团队提供反馈。最严密的反馈回路是尽可能多地切断以测试所讨论的特定操作的回路。测试一个比必要的更宽的循环会引入一些变量，这些变量可能会混淆你从测试中得到的信号。 这十条法则并不完整，测试领域还有很多限定守则，而且使用这些法则时的上下文环境也很重要。也许某次测试会打破一两条法则，那也无妨，不必把它们奉为金科玉律，重要的是寻求持续改进，而非特定一次的完美。
