意外的复杂性正在扼杀你的测试工作和IT预算

你正在努力改变你的工作方式，以实现一系列不同的目标。常见的数字化转型的目标包括:

1.变得更敏捷

2.通过DevOps实现更快地交付

3.将所有系统迁移到云端

4.启用定期更改

无论你希望取得什么样的成果，有一个常见问题是大多数人（其实是所有人）都会忽视的。然而，忽视这个问题最终意味着计划将失败、延迟、成本过高，或者总体上严重阻碍计划的推进。

这个长期存在(也一直被忽视)的问题是“意外的复杂性”。这包括在你今天做出改变的方式中已经固有的意外复杂性，或者由于你选择明天做出改变的方式而在未来引入的意外复杂性。

“虽然本质的复杂性是固有的和不可避免的，但意外的复杂性是由所选择的解决问题的方法造成的。”

—Hugo Sereno Ferreira，“不完整的设计:对敏捷架构的思考”(敏捷葡牙:2010)

当涉及到IT系统时，组织很少有机会重新开始。任何敏捷转型——本质上是向小的、迭代的、紧急的变化的转变——都是在棕场架构中完成的。这些不可避免地包含了意外的复杂性。

本文列出了意外复杂性的不同症状，讨论了它们是如何破坏你的转型计划的。我之前的博客为如何解决这种意外的复杂性提供了灵感。

UI测试过多

由于界面没有被很好地理解或文档化，组织被迫重新创建专注于用户界面的测试。这种对UI测试的过度关注是低效和昂贵的，同时破坏了我们早期和迭代测试的能力。它的总体覆盖率更低，使系统暴露于bug中。

组合爆炸—主观覆盖

因为我们对系统的理解是在端到端用户流的层面上，所以我们的业务逻辑成倍增长:

这种“组合爆炸”的复杂程度超出了人类的理解范围，而且不可能在合理的时间范围内进行测试。在这种情况下，在测试中获得有价值结果的唯一方法是应用基于风险的方法。然而，很少有人认识到这一点，或者风险是基于中小企业对什么是“足够”测试的看法。

膨胀的回归测试包和大量的重复

这种组合爆炸增加了测试的复杂性，也增加了你理解系统的能力。这个问题变得太大而难以理解。我们都被教导要把问题分解成更小的部分，但这似乎暗示了许多测试方法。

巨大的数据需求

在端到端往返过程中，需要通过多个系统进行大量测试，这增加了对测试数据的需求。测试数据变得非常复杂，这不仅是因为测试所需的数据没有得到很好的理解，还因为这些数据项所在的记录系统。

这些系统本身处于不断变化之中，在变化过程中，意外的复杂性发挥了作用。这些系统通常很难被理解，也很难被记录。反过来，为测试提供数据并不是你所认为的事务性请求。它面临着巨大的复杂性、大量的劳动力、错误和瓶颈。

巨大的测试环境需求

复杂性的雪球继续增长:因为我需要端到端测试，所以我需要端到端环境。

反过来，测试和开发也需要大量的渠道、中间件和记录系统。通常，这些都是传统的（大型机）系统，不可能在一夜之间建立起来。事实上，企业往往已经丧失了从头开始构建这些系统的能力和知识。因此，我们唯一的选择就是使用组织内有限的完全集成的端到端环境。

然而，即使是这些环境中的一个，仅在基础设施上就将花费数百万美元，并且在维护资源方面也将花费相同的数倍。这还不是唯一的问题。企业有许多团队在进行变更，他们都需要进行端到端测试。团队排队等待环境，造成了一个巨大的瓶颈，耗尽了组织的变更预算。

测试系统的测试漂移

如果你没有有效的方法来重构你正在测试的内容，那么将不可避免地出现正在测试的内容与系统实际工作方式之间的分离。你很少会看到一个团队谈论他们是如何重构测试资产的，因为大多数团队都不这样做。这不仅会导致测试膨胀，还会产生过时和无效的测试，以及测试工作所涵盖的内容不一致。

组织不仅仅是一个结构图表

迄今为止讨论的问题都是系统性问题，而不是测试问题。意外复杂性还源于组织及其结构。挑战包括:

· 组织是各自为政的，IT 变革团队也是如此。Conway定律告诉我们，这些 "孤岛 "形成的架构，其接口没有得到很好的理解或维护。除非迫不得已，团队之间是不会交谈的....

· IT 变革使人们对系统工作方式的理解出现 "分层"。随着系统的发展，它们变得越来越复杂，未知因素也越来越多。

DevOps的三种方式分别是流程、反馈和实验/学习。Flow谈到“绝不允许局部优化导致全局退化”。这应该导致团队重新思考他们处理变化的方式，但这似乎很少发生。

这句话表明了跨团队协作的必要性。而 "披萨盒大小的团队 "却阻碍了这种协作，他们继续各自为政，把工作夹在栅栏外，在大型端到端集成测试活动中发现问题。虽然一个团队可以尽可能在一个孤岛上工作，但他们不可避免地需要将他们正在开发的系统与组织的其他部分整合起来。

这种方法的选择可能被认为是开始时阻力最小的途径。它甚至可能以实验或大型组织内的“启动”计划的名义进行。无论理由是什么，它很可能没有考虑到这种方法在更广泛的组织中创建或贡献的意外复杂性。

在进行变更时，你可能会将测试视为组织成熟度的晴雨表。如果系统是可测试的，那么变化是可以理解和观察到的。如果讨论了质量和风险，你就拥有了一个健康的生态系统。如果所有这些看起来都太难了，那么不幸的是，你将继续沿着不断增加的复杂性螺旋前进。

不能改变，不愿改变

文化把策略当早餐吃。

——Peter Drucker

毫无疑问，你会认识到本文中提出的许多观点，但最大的挑战不是知道如何改变，而是想要改变。

许多组织都按一定的节奏工作。革新者走出去获得最新的技术，还没有意识到他们只是在用一个更花哨的工具制造同样的问题。还有一些落后者，他们从去年开始就被困在工作方式上。他们会说，“我们在敏捷之前就做了敏捷”，并渴望回到一个更少文档、更少变更或版本控制的时代。

每一种方法都有一些好的实践，但是它们都产生了更多意外的复杂性，并且在组织中局部优化，而不是全局优化。那么，你将如何面对组织的意外复杂性呢?

“意外复杂性是指某些东西可以按比例缩小或变得不那么复杂，而不会失去任何价值，并且可能因为被简化而增加价值。”

——Kristi Pelzel，《设计理论:偶然的和本质的复杂性》(Medium: 2022)

关注微信公众号【赛希咨询】，了解更多精彩内容。