本系列博客探讨软件测试中的一个核心问题：“我们该如何测试？”我们将从塑造测试方法的基础概念入手：学习、建模和启发式方法。随后，本系列将深入介绍实用的思维工具：如何理解产品（产品分析）、如何识别重要的潜在问题（风险分析）以及如何有效地搜寻这些问题（测试策略）。最后，我们将讨论如何以有意义的方式传达测试发现（报告）。
本系列的所有观点都深受“快速软件测试”（Rapid Software Testing）方法论的影响。
“我们该如何测试？”是测试人员在实践中常遇到的棘手问题。我们常常担心测试没有覆盖真正重要的问题。由于开发周期短，团队常常跳过对风险和测试策略的深入思考。大多数测试依赖直觉完成，这很可惜，因为通过系统性的方法，测试可以做得更好、更轻松。测试人员天生倾向于过度测试。借助风险分析和测试策略，并定期与团队及产品负责人讨论，有助于避免测试过度。
人类喜欢确定性
人类沉迷于“知晓”，尤其是确切地知晓。确定性是我们所追求的，而不确定性会带来压力。然而，在我们工作的外部世界，尤其是软件开发领域，没有什么是绝对确定的。我们必须接受这一点。
像 ISTQB 这样的“结构化测试方法论”试图教授一种标准化的工作方式。特别是在 20 世纪 90 年代和 21 世纪初，几乎每种测试方法论都在倡导一种结构化、文档繁重的测试流程。他们称之为“结构化测试”。这听起来很有趣，因为他们所谓的“结构化”是指必须按照特定规定的结构，以系统化的方式行事。如今，我认为“结构化测试”这个说法有些同义反复（就像“白雪”或“绿草”）。在测试中采用探索性方法同样也是结构化的，只是结构化的方式不同。
我也注意到，有些人喜欢将问题解决和测试过程系统化（也称为机械化或算法化），将其过度简化以便于操作。例如，通过将概率和影响相乘来计算风险，或者总是采用标准工作流程而不考虑具体上下文。人类倾向于简化事物，我们的大脑就是这样构建的：大约 85% 到 90% 的行为是自动完成的，无需思考。我们必须让大脑进入主动模式，才能运用“系统 2”思维（如卡尼曼所述）。根据我的经验，许多测试人员更偏爱算法化的工作方式。
思维范式
直到最近，通过 Tanja Vos 教授，我才了解到理解知识的两种不同范式：理性主义与经验主义。经验主义强调通过经验、观察和迭代实验来学习，重视与软件、用户行为的直接互动以及持续的反馈循环。相比之下，理性主义植根于逻辑、推理和形式化方法，依赖系统化的过程和抽象理论来设计和“证明”软件的正确性。
虽然理性主义优先考虑结构、标准化和形式上的严谨性，但我早在职业生涯初期就发现这种方法并不适合我。那种高度方法论化、逻辑繁重的思维方式感觉限制性太强。相反，我被敏捷、上下文驱动测试和快速软件测试的经验主义精神所吸引——这些方法拥抱不确定性，强调在实践中学习，并根据现实世界的结果进行调整。
研究与开发
软件开发是一个持续的研究与开发过程。业务和 IT 部门需要共同努力，以寻找合适的解决方案、解决问题并预防问题。在用户需求与机器能力之间进行转换是一个具有挑战性的难题。我们必须应对复杂性、临时变更以及新的见解。归根结底，一切关乎什么有效、什么无效。
软件无处不在，它驱动着我们的日常生活，使事务变得更简单、更快速、更高效，并且通常也更令人愉快。它如此深刻地嵌入到我们的活动中，以至于没有软件的生活几乎变得不可能。软件不仅塑造了我们如何生活，还扩展了我们能够做的事情。
但是，当新软件上线时，你是否曾感到那种紧张和不确定的时刻？你并没有完全放心。如果出了问题怎么办？如果你的车明天因为系统故障无法启动怎么办？或者你的手机需要重装系统，导致所有照片消失怎么办？如果突然之间，你完全无法工作了呢？
软件的质量至关重要。要让优秀的软件正常运行需要付出很多努力。不仅软件本身要好，围绕它的流程、它运行的硬件和网络，以及开发和运维它的人员也必须优秀。许多不同的方面都会产生影响。协作、沟通和团队合作是决定性的因素，它们构成了成功的部门、项目和团队的基础。你会发现，在专业人士良好合作的地方，就能取得成功，用户的生活也会变得更轻松、更丰富、更令人兴奋。
质量
既然提到了质量，让我们来谈谈它的实际含义。在快速软件测试（RST）中，我们将质量定义为“对某些重要的人的价值”。我们将质量视为一种动态关系。质量是一种观点，而非绝对事实。关于质量的决策始于确定谁的价值重要、他们重视什么，以及这种价值可能如何受到威胁。质量特性帮助利益相关者建模价值。但请记住，这只是对质量的简化描述！
产品是用户获得的体验。规格说明只部分对应于客户的需求，也只部分对应于最终构建的产品。规格说明永远不可能完整。不同的人看待同一事物，可能会看到不同的质量。
应对复杂性与不确定性
软件开发是复杂的。要完全、深入地理解一个系统应该做什么非常困难。这是因为需求众多，也因为我们面对的客户并不总是确切知道他们想要什么，或者无法清晰地表达。IT 团队也并不总能很好地理解业务。此外，我们还必须应对一个 VUCA（易变性、不确定性、复杂性、模糊性）世界：复杂性、混乱、变化、新见解和半成品答案。因此，我们面临着相当大的风险。
软件开发是一个持续的研究与开发过程。业务和 IT 部门共同努力寻找合适的解决方案、解决问题并预防问题。在人的期望与机器能力之间进行转换是一个具有挑战性的难题。因此，软件开发关乎学习和应对风险。
复杂性是软件开发中一个严重且常常被低估的问题。意识到复杂性是第一步。我们需要持续降低复杂性：通过采用敏捷工作方式应对复杂性；同时，通过使用微服务构建模块化系统也有帮助。《团队拓扑》向我介绍了“认知负荷”的概念。这让我意识到，在许多情况下，我们期望团队处理过多的信息和复杂性，这必然会引发问题！建模和可视化是让复杂事物更容易理解的绝佳方式。
在我的职业生涯中，我逐渐培养了对不确定性的适应能力。作为一个快速思考者，我曾经以非常不同的方式应对不确定性。如果我不能足够快地完全理解事物，我会感到紧张和烦躁。如今，我明白深入理解需要时间和努力，并且可以通过创建自己的模型和视觉辅助工具来促进这一过程。
本系列的其余部分分为五个主要部分：
- 学习、启发式方法和模型
- 产品分析
- 风险分析
- 测试策略
- 报告
下一篇博客将深入探讨学习。
