你还记得夏洛克·福尔摩斯的帽子吗？这位由阿瑟·柯南·道尔创造的传奇侦探夏洛克·福尔摩斯最让人记住的是他在伦敦的雾天破解谜案，抽着烟斗，以及一顶帽子。这顶帽子成为了调查复杂案件的侦探们的标志性头饰。

在我们的日常工作中，我们每天都会戴上多个“帽子”。产品负责人、开发人员、设计师和质量保证工程师可能会根据新挑战切换角色。然而，质量保证工程师往往是团队中戴上想象中的侦探帽子的人。不得不说，如果你是好测试人员，这顶帽子会很合身。

我刚开始在软件测试领域的工作时是一名手动（或者说更好的是）质量保证工程师。几年后，我也学会了基本的自动化知识，特别是在使用Gherkin语法时。帮助开发人员挑选适合自动化的测试，并定期检查持续集成和持续交付管道中自动化测试的状态。不过，我的主要工作是应用人力驱动的测试方法，并帮助整个团队改进测试策略，包括手动和自动化测试在多个产品层面的应用。

现在，当我听到一些社区的声音说手动测试人员已经落伍时，我的眼睛就会不由自主地瞪大。我不认为这是针对个人的攻击。然而，这仍然让人难以理解：我们是否准备好让工具（机器）来进行这些评估和检测，并像人类一样去体验和测试产品？

业内专家指出，人工驱动的测试技术对产品的开发仍然至关重要。然而，我发现一些知名公司过于依赖自动化测试而忽视了人工驱动的测试技术，这可能对整体产品质量不利。我在一篇近期的文章中已经提到了过度依赖自动化的危险。在一些对话之后，这激发了我写更多关于最令人兴奋的手动测试技术之一——探索性测试技术的灵感。

首先，让我们澄清一下：手动测试是否依旧很酷？如果是，为什么？在一些怀疑论者开始反驳作者之前，我想澄清：是的，人工驱动的测试技术依然重要。如果没有像探索性测试这样的手工测试技巧，质量保证专业人士会变得多余，很容易被AI取代。但这种情况尚未发生（至少到目前为止还没有）。

听完苏·阿特金斯（Sue Atkins）在TestBustersNight（由鲁道夫·格罗茨（Rudolf Groetz）组织）上的精彩演讲《称赞手动测试》之后，我突然恍然大悟。苏强调我们还未到可以把所有人工测试活动都交给AI工具的地步。这次演讲还引发了关于人类执行的测试活动是否应该称为“手动”测试的讨论。类似朱利安·哈蒂（Julian Harty）最初提出的“亲自测试”这样的称呼可能更合适。

别误会，我支持在质量保证中采取平衡的方式。一个敏捷测试工程师应该能够采用人工驱动的方法，并自动化某些测试或与开发人员合作。然而，有些方面是工具（机器）不擅长的：它们缺乏创新力、同理心和直觉。

自动化测试很难发现开发人员和设计师未曾考虑到的边缘情况（“不愉快”的路径，即开发者和设计者未曾预料到的情况）。它们无法全面评估用户的深层体验，并根据产品品质的相关属性进行评估（参见ISO 25010: 系统和软件工程）。相反，人工质量保证在这些领域将表现出色。因此，现有的工具很难像人一样全面探索产品。

比如詹姆斯·林赛提到的（https://www.workroom-productions.com/why-exploration-has-a-place-in-any-strategy/）：

“自动化测试不会告诉你系统运行缓慢，除非你提前教会它关注这个问题。它也不会告诉你窗口留下的阴影一直存在，数据库中的每条记录都被破坏了，甚至错误的也被标记为正确的，除非它知道该查找什么和在哪里查找。不过，如果你仔细查看它收集的数据，你或许能发现一些问题，但这就又回到了探索性测试的手法。”

那么咱们就走近探索测试，再加上侦探的帽子。

探索性测试完全依赖于人类的创造力和好奇心。这些测试是在没有准备的书面脚本的情况下进行的，测试人员需要在现场即兴发现问题。这让我们能发现脚本测试，比如端到端测试，可能遗漏的系统行为。这样可以发现边缘情况、用户体验差异以及潜在的故障。

“探索性测试不需要预先编写的脚本，也不需要预先确定的一系列动作。测试者在测试时可以自由选择行动，选择信息和观察的内容不受预先设定的设计限制，而是受限于机会和资源。每一刻，测试者决定做什么，使用什么工具，如何验证结果。有趣的地方会被更仔细地探索，弱点会被尝试，门把手会被尝试。测试者会选择一起尝试两个不同的动作，这两者结合起来会暴露系统中的潜在风险。测试者会选择利用这些信息和动作，不仅为了找出什么是有价值的，而且要探索什么可能是可行的。探索性测试者更注重可能的风险。”

探索性测试比脚本化测试更随意和非正式，但仍需要一定的规矩才能做得好。通常，探索性测试通常有一个明确的目标，比如“测试新功能”，并且通常以限定时间的会话方式来进行。测试人员可能会用一个任务卡来记录他们的观察结果。

要想有影响，应定期应用探索性测试。正如马丁·福勒指出的那样，如果团队不进行探索性测试，那可不太妙：“即使是最优秀的自动化测试本质上也是脚本测试——这本身是不够的。”依我经验，我建议每周安排一些时间进行探索性测试，最好是定期举办探索性测试会议。

QA测试人员、开发人员、产品负责人或设计师可能会单独进行探索性测试。在这样的团队中，每个成员都可以通过探索产品并将其发现汇报给团队来为保证产品质量做出贡献。

探索性测试也可以通过结对的方式应用，采用结对编程的原则。正如 Mariia Hutsuk 和 Sivamoorthy Bose 所说，结对探索性测试涉及两个角色：一个人称为“驾驶员”，另一个人称为“导航员”。

“司机是握着方向盘的人，在进行操作时，司机应该专注于应用，并在有问题时提问。而导航员则是观察者，给出进一步检查的方向，并记录下步骤和发现。这些角色可以在必要时互换。”

从我的经验来看，你可以通过安排一个团队的探索性测试会议——所谓的“bug bash”（即有效的Bug Bash运行，参见：https://medium.com/@changbot/running-an-effective-bug-bash-317fafa9d963）——来达到乘数效应。为了尽早发现潜在的bug，在新功能被编码到开发人员的环境中后，团队应立即进行探索性测试。

这里是一个假想团队探索性测试会话章程模板的例子。

“嘿！今天的任务是代入用户身份，测试神奇门户的用户流程。利用你的技能和直觉，尽可能多地发现产品中的视觉或功能问题。一旦遇到 bug 或用户体验问题，请记录在测试日志中。下面是一些大致的指引。不过，你还需要即兴设计一些测试场景。”

任务一

作为顾客，你可以浏览Amazing Portal上的这些产品。

任务二

作为顾客，下单购买产品A、B、C、D

任务3

作为顾客，请更新您的资料中的数据。

任务四

作为顾客，可以探索神奇门户的其他区域。

一旦探索会议完成，发现的问题应在团队中报告和讨论。有时，由于会话中揭示的发现，功能可能需要完全重新设计。这对团队来说可能有点痛苦，但仍然是一种双赢的局面，因为在开发后期，设计师和开发人员将减少返工，客户也会感觉更少的麻烦和不满。

我相信没有任何由AI驱动的工具能够替代人类在测试中展现的创造力、同理心和直觉。因此，像探索性测试这样的技术仍然有很大需求，并且应该被团队成员积极应用，无论是开发者、设计师、产品经理还是质量保证工程师（如果你们团队幸运的话）。如果在开发早期就采用探索性测试，它将帮助你发现潜在的边界情况和产品问题，无论是用户界面级别的可见问题，还是API级别和后端行为的隐藏问题。这可能会真正影响产品质量，长远来看可以减少返工成本，并将整个团队的测试策略向左偏移。为了实现这一点，继续探索，并自豪地戴上你的“夏洛克”帽子。

如果你想和我联系或对我的背景感兴趣，可以查看我的领英页面。作为一名拥有7年以上行业经验的QA工程师，我准备好与那些需要指导和帮助以提升产品质量和测试的团队沟通。我现在正在寻找新的职位，比如QA分析师、QA工程师或QA负责人。

插图：我画的（用苹果铅笔和iPad，没有用AI :))

资源如下：

1. Sue Atkisson, 玩玩软件——像测试人员一样学习 : https://medium.com/@TestSprite/playing-with-software-learning-like-a-tester-ca7412537d6b
2. James Lyndsay, 为什么探索在任何策略中都有位置 : https://www.workroom-productions.com/why-exploration-has-a-place-in-any-strategy/
3. Mike Chang , 举办有效的 Bug Bash (漏洞狂欢节) :__https://medium.com/@changbot/running-an-effective-bug-bash-317fafa9d963
4. Mariia Hutsuk 和 Sivamoorthy Bose , 探索性测试的重要性 : https://medium.com/quality-matters/importance-of-exploratory-testing-3f02e34dc0c3
5. Martin Fowler, 什么是探索性测试 : https://martinfowler.com/bliki/ExploratoryTesting.html