说到
探索性测试，大家都耳熟能详，特别是在敏捷测试的条件下，探索性测试成为了高频词。其中HTSM模型、SBTM模型，包括探索性测试如何结合到项目研发流程中等等，也已被大家所熟知。这次本文并不想探讨上述这些话题，而是结合自己团队的实践经历，重新聚焦到探索性测试活动本身的实施和开展上，简而言之就是如何更好的实施探索性测试？
为了保证逻辑上的完备性，首先还得提提 探索性测试的定义和本质。定义当然是由探索性测试的提出者CemKaner博士所说，探索性测试一种自由的软件测试风格和思考方法，强调独立测试人员的个人自由和责任，为优化工作价值，在项目过程中并行测试相关学习、测试设计、测试执行和测试结果分析。
好吧，细细研究这个定义，我们首先就发现了探索性测试的实施难点，它只是一种测试风格。这就和人的穿衣风格类似，有些人喜欢小清新韩范儿，有些人喜欢西装革履职业范等等，这只是一种思想和个性的展现，无关好坏优劣。
其实，CemKaner也明确的说到，探索性测试不是测试技术。这也就是说，探索性测试在理论上来说谈不上“术”。但我们现在恰恰需要和大家来探讨怎么穿衣搭配，能让自己变的小清新。这个确实不太容易。
第二，探索性测试要并行的进行测试学习、测试设计、测试执行和测试结果分析。探索性测试其实是希望通过不断的同时进行学习和设计，并把想法及时注入到被测系统中，快速获得系统反馈，然后再来决定下一步的动作。怎么样，这个定义是不是有点似曾相识？没错，这很符合敏捷思想，所以我们也应把探索性测试看做敏捷方式的测试过程。
虽然谈实施不太容易，但根据我们自己的实践，还是把如何开展探索性测试简单的用下面几个短语串联起来： 汇信息、画地图、定范围、做记录、讲思路、理报告。 每个词很容易理解，但是有很多细节，听我一一道来。通过这个过程，想传递给大家的信息是，想做好探索性测试，不仅仅需要从个人层面来努力，作为团队组织层面，也非常有必要帮助个人来完成探索性测试，辅助个人进行测试分析、测试决策，提升个人的思维水平。
一 汇信息搜集信息，KYM，这已深入人心。但是为什么要把它再拿出来谈，是因为对于探索性测试来说，搜集信息格外重要。在 测试三角形中，从塔底的UT，到塔尖的ST，最后再到尖尖一角的ET，可以说对于测试量最小的ET，一定要做到最高效。UT/FT/ST对ET来说都是重要的基础信息输入（当然这还远远不够）。想想我们的特性移交过程，需求分析说明书、特性移交表、自动化用例等等，除了这些你还能收集到什么信息？你和特性团队聊过了吗？业务代码你获取了吗？你和测试专家沟通了吗？你了解BA（当前最接近需求的人）知道的所有外场应用的信息吗？等等，这些都是你最容易忽略的地方，这些都需要你面对面去沟通，千万别局限在业务实现文档上，那样你肯定做不好ET。
为了保证逻辑上的完备性，首先还得提提 探索性测试的定义和本质。定义当然是由探索性测试的提出者CemKaner博士所说，探索性测试一种自由的软件测试风格和思考方法，强调独立测试人员的个人自由和责任，为优化工作价值，在项目过程中并行测试相关学习、测试设计、测试执行和测试结果分析。
好吧，细细研究这个定义，我们首先就发现了探索性测试的实施难点，它只是一种测试风格。这就和人的穿衣风格类似，有些人喜欢小清新韩范儿，有些人喜欢西装革履职业范等等，这只是一种思想和个性的展现，无关好坏优劣。
其实，CemKaner也明确的说到，探索性测试不是测试技术。这也就是说，探索性测试在理论上来说谈不上“术”。但我们现在恰恰需要和大家来探讨怎么穿衣搭配，能让自己变的小清新。这个确实不太容易。
第二，探索性测试要并行的进行测试学习、测试设计、测试执行和测试结果分析。探索性测试其实是希望通过不断的同时进行学习和设计，并把想法及时注入到被测系统中，快速获得系统反馈，然后再来决定下一步的动作。怎么样，这个定义是不是有点似曾相识？没错，这很符合敏捷思想，所以我们也应把探索性测试看做敏捷方式的测试过程。
虽然谈实施不太容易，但根据我们自己的实践，还是把如何开展探索性测试简单的用下面几个短语串联起来： 汇信息、画地图、定范围、做记录、讲思路、理报告。 每个词很容易理解，但是有很多细节，听我一一道来。通过这个过程，想传递给大家的信息是，想做好探索性测试，不仅仅需要从个人层面来努力，作为团队组织层面，也非常有必要帮助个人来完成探索性测试，辅助个人进行测试分析、测试决策，提升个人的思维水平。
一 汇信息搜集信息，KYM，这已深入人心。但是为什么要把它再拿出来谈，是因为对于探索性测试来说，搜集信息格外重要。在 测试三角形中，从塔底的UT，到塔尖的ST，最后再到尖尖一角的ET，可以说对于测试量最小的ET，一定要做到最高效。UT/FT/ST对ET来说都是重要的基础信息输入（当然这还远远不够）。想想我们的特性移交过程，需求分析说明书、特性移交表、自动化用例等等，除了这些你还能收集到什么信息？你和特性团队聊过了吗？业务代码你获取了吗？你和测试专家沟通了吗？你了解BA（当前最接近需求的人）知道的所有外场应用的信息吗？等等，这些都是你最容易忽略的地方，这些都需要你面对面去沟通，千万别局限在业务实现文档上，那样你肯定做不好ET。
做ET你需要的是灵感，需要重新思考你的测试维度和思路，特别是在特性团队已经完成FeatureDone的情况下，特别是在特性团队是按照你原先的测试方案完成FeatureDone的情况下，新思路对后续的测试分外关键。而这些过往过程信息越详细，你才有可能捕捉到某个被N多人忽略的方向，获得你的新思路。
二
画地图有了这些信息，接下来，需要做的是一个简单设计。其实，这个过程，最重要的内容是测试分析。测试分析和测试设计，严格意义来说是两个不同的过程。实例化一下，当你通过“汇信息”获取了大量信息后，你应该如何测试？有哪几个方向可以进行探索测试？在哪个具体方向探索？这些都需要进行分析。
随着敏捷的逐步深入，我们的测试应该越来越多的注重测试分析。而对于测试执行，特别是在一个技能相对成熟的团队，关注度是不应该过高的。通过分析，我们可以对待测试特性的过往情况和风险有明确的了解，其中需要进行测试的部分，就进一步细化，进行测试设计，不需要测试的部分，就直接Pass。
在测试分析的过程中，可以通过思维导图等方式，来书面化我们的想法，形成 测试地图。为什么需要这个地图，首先它能够在后面ET执行过程中，辅助我们进行ET深度和广度的控制和收放（这一点非常重要，涉及ET执行人员的过程自我管理，下文也会提到）。第二，在进行ET Debrief时，可以清晰的表达ET过程（这一点也会在下文详述）。
三
定范围定范围包括两个方面，一个是内容，一个是时间。ET中的Session和Charter其实说的就是这个事。关于内容的选取，可以选择你认为风险最高地方的入手，也可以抱着学习基本特性的目的入手，选择的依据更多在于你的测试目的。在时间上，对于大型电信设备，一个Session可能需要2-3小时。这些内容，可以参考ET基础知识，本文不赘述。
本文想说的是，通过实践发现，不受打扰的时间盒对于ET开展的效果有比较大的影响。 时间盒，顾名思义，是一段不受打扰的时间，而在绝大多数情况下，这个时间盒在ET过程中很难保证，经常会被ET以外的事情打扰，甚至完全打断这次Session。其次，在ET的过程中，我们也可能会因为发现了一些疑点，而不断进行深入测试，超出了时间盒等等。这些情况，其实涉及到ET过程的自管理。这也是ET理论里面“Dynamic循环”提到的“自我管理循环”。包括时间管理和内容管理。想要做好一个ET，一定要有比较好的 自我管理能力。
要把时间和内容规划好（请注意，重点是ET执行人员的时间和内容的自我规划，而非组织安排），要在ET的执行过程中，控制好自己的测试内容。这时“画地图”的成果——测试地图，就可以提醒我们进行合理的收放控制，是不断深入，还是广度为先。这种自我管理能力，才能保证ET的测试效果。所以“定范围”更多的是自我管理。（当然，涉及组织的集体决策部分，在下文描述）
四
做记录请大家记住这句话，在ET的过程中，请一定要做好记录，虽然在ET理论中没有这种强制要求，但是记录对ET真的非常非常重要。为什么要做记录。在回答这个问题前，我们先来尝试回答一下，为什么有些同学会被称作牛人？他到底牛在哪里？如果抛弃形而上的物质事物，他的思维可能是他最超出常人的地方吧。而这也是决定ET效果的重要因素。
做好记录，实际上是在帮助我们梳理ET执行过程中的思考路径。同时，请一定记住，这个记录是做给你自己看的，不是用来给别人看的。通过这个记录，当做完一个Session后，你仍然能够清楚的回忆出走过的测试路径。
做记录的时候，需要记什么？这个没有固定的内容，你可以记测试点、时间、发现的Bug等等，但是有一点一定要注意，如果在测试的过程中，你做了什么决策，请务必记录下来。也就是说，在记录中要能够看出你的决策点，这些决策点是下面Debrief的重要内容。
在记录的形式上，有些同学爱用鱼骨图（有时间轴的感觉），有些同学爱用思维导图，有些同学爱用即时贴，有些同学就随手记在本子上，这些都不是问题。你想怎么记就怎么记。说起来很简单，而在实践过程中，大家往往不太容易去尝试记录测试过程（注意是测试过程，而不是单纯的测试点），同时记录本身也需要花费一点时间，但是你一定要尝试着去做，不一定太复杂，你自己看懂就好。
五 讲思路说到这一步，就涉及到ET当中非常关键的一个活动——Debrief。Debrief的原意是审查，其实是由ET的执行者和其他干系人，比如SM、TL、DEV等一起来沟通Session的测试情况，然后决定下一步的测试方向和计划。
其实，在Debrief的时候，有三点需要留心，首先，你在刚开始做Debrief时，可能会按照下面这种说法来描述：这个Session，我测试了palapala，发现了什么什么，下面决定干啥干啥…… 这样其实挺好，达到了Debiref原本的要求。但是我想说，这样做远远不够。我们知道，ET和个人能力有很大关系，那么我们的测试能力又如何提高呢？重要的话说三遍：牛人牛在他的思路。我们在Debrief时，邀请了那么多牛人，那我们为什么不看看他们的测试思路是什么呢？但是怎么看？你首先就要说出你这个Session的思路，和它走过的测试路径，特别是你在测试过程中的那些决策点。这时“做记录”的成果就能排上大用场了。它能够帮助你清楚的复述出你的测试思路和测试决策。而大牛们重点要关心的，或者可以提出有价值建议的，就是告诉你，你这个决策可能还不完备，你的思路还有哪些缺漏，你应该怎么思考问题。而具体的某个测试点是不是要测，你自己完全可以做确定。所以，应该充分利用Debrief过程向大牛们去学习他们的精髓。我自己亲身经历过一次成功的Debrief，当执行者讲述到我当时是这么想的…..，所以我决策这么干时，一位同学马上跳出来说，我觉得你应该重点测试…..，原因是…，你应该按照这个方向走。大家听完，立马一股清风扑面的感觉。
第二，做Debrief时，不要包含过多的内容。为了保证debrief的效果，应该加大Debrief的频度，让每次Debrief的内容精简、聚焦。我们在一个测试执行工作量3天的特性中，尝试做了5次Debrief。每一次，都会有一些新想法冒出来，然后就会立马在下一个Session去尝试。
第三，我们建议，不一定要等到测试执行一段时间后，或者测试完成时，再进行Debrief，这样做更类似于复盘。我们应该尽量让Debrief做到承上启下，做到提前为主、预防为主。我们现在的做法是，在完成“汇信息”、“画地图”后，就做第一次Debrief，先整体聊聊这个特性的ET测试价值，决定我们第一步往哪里做。其实Debrief，是ET当中一个相对比较容易落地的小实践，它体现了ET在实施过程中一个非常重要的方式——ET不是一个人在战斗。作为团队来说，有责任利用团队优势，更好地帮助、指导、教练（注意是教练，不是管理）我们的同学更好的实施ET。让我们就从Debrief做起。
六
理报告这一步骤，相对来说比较容易理解。但要注意两点，首先，ET理论中推荐进行TBS分析，也就是整体分析我们在真正的测试工作、Bug发现与定位、准备工作上的时间分布，从而发现问题。这一部分，大家可以尝试。第二，我们需要把整个ET过程中的所有信息进行汇总，注意是所有信息，包括没有测试的地方、风险等等，信息愈多越好。因为作为测试工作，我们的核心价值并不是判断结果，而是提供信息。
说完了上面几步，还有一些零碎的东东，再花一点篇幅进行说明。
首先说说ET在执行中的一种形式—— 结对。结对是敏捷中一个比较经典的实践。在ET执行过程中，也有应用。结对这种方式会更有助于ET的开展吗？通过我们的实践发现，在ET中使用结对方式可能也会有一些问题，这可能也是ET本身的特点所决定的。回想ET给执行者所创造出来的自由空间，它希望执行者能够在这个空间内根据自己的想法、实践去进行尝试，而在这种自由空间下，很难说某种尝试、某种路径的是非好坏。而结对则希望在执行的过程中，能够通过交流、碰撞，来达到相对更好的一致。我们在结对ET的尝试中发现，在很多情况下，双方的思路其实并不能很快达成一致，更没有好坏之分，大家之间互相的研讨反而导致个体的思路受到干扰，效率降低。其实我们更推荐，由多个人分别独立的去做同一个特性的ET，这种方式大家在各自探索时能够保证各自的独立性和连贯性，而在Debrief时，又能够看到双方的思路差异，互相启发。
其次，随着个人不断的进行ET，个人可以尝试总结自己的 HTSM模型。把自己曾经的测试过程、Debrief、以及其他渠道获得的启发点进行归类整理，形成自己的启发式模型。这对于自己测试技能的提升非常有意义。
最后，一定要说一下对于 ET质量的评价和度量，因为这是一个非常引人关注的问题。ET的质量到底应该如何评价？可能被问的最多的一个问题就是，通过ET发现了多少故障？其实当你仔细去思考ET质量这个问题时，你一定会发现对于ET的评价肯定不能这么简单。举个例子来说吧，还是上文提到的那个我们做了5次Debrief的特性，我们通过ET并没有发现什么传统意义上的Bug。但是当我们去和执行人员、项目干系人沟通，询问他们对这个特性的质量感受和评价，他们都觉得测试很靠谱。是什么给了他们这种判断？其实就是我们通过ET所汇总呈现出来的各种信息。对于ET，个人认为使用360度评估更加合理，如果所有的人都认为质量可控，那么我们没有理由说，不发现故障的ET就是效果不好的ET。如果我们把ET比作画家的一副作品，我们真的很难用KPI来说明这幅画有多美，因为做ET的不是机器。
随着敏捷的逐步深入，我们的测试应该越来越多的注重测试分析。而对于测试执行，特别是在一个技能相对成熟的团队，关注度是不应该过高的。通过分析，我们可以对待测试特性的过往情况和风险有明确的了解，其中需要进行测试的部分，就进一步细化，进行测试设计，不需要测试的部分，就直接Pass。
在测试分析的过程中，可以通过思维导图等方式，来书面化我们的想法，形成 测试地图。为什么需要这个地图，首先它能够在后面ET执行过程中，辅助我们进行ET深度和广度的控制和收放（这一点非常重要，涉及ET执行人员的过程自我管理，下文也会提到）。第二，在进行ET Debrief时，可以清晰的表达ET过程（这一点也会在下文详述）。
三
定范围定范围包括两个方面，一个是内容，一个是时间。ET中的Session和Charter其实说的就是这个事。关于内容的选取，可以选择你认为风险最高地方的入手，也可以抱着学习基本特性的目的入手，选择的依据更多在于你的测试目的。在时间上，对于大型电信设备，一个Session可能需要2-3小时。这些内容，可以参考ET基础知识，本文不赘述。
本文想说的是，通过实践发现，不受打扰的时间盒对于ET开展的效果有比较大的影响。 时间盒，顾名思义，是一段不受打扰的时间，而在绝大多数情况下，这个时间盒在ET过程中很难保证，经常会被ET以外的事情打扰，甚至完全打断这次Session。其次，在ET的过程中，我们也可能会因为发现了一些疑点，而不断进行深入测试，超出了时间盒等等。这些情况，其实涉及到ET过程的自管理。这也是ET理论里面“Dynamic循环”提到的“自我管理循环”。包括时间管理和内容管理。想要做好一个ET，一定要有比较好的 自我管理能力。
要把时间和内容规划好（请注意，重点是ET执行人员的时间和内容的自我规划，而非组织安排），要在ET的执行过程中，控制好自己的测试内容。这时“画地图”的成果——测试地图，就可以提醒我们进行合理的收放控制，是不断深入，还是广度为先。这种自我管理能力，才能保证ET的测试效果。所以“定范围”更多的是自我管理。（当然，涉及组织的集体决策部分，在下文描述）
四
做记录请大家记住这句话，在ET的过程中，请一定要做好记录，虽然在ET理论中没有这种强制要求，但是记录对ET真的非常非常重要。为什么要做记录。在回答这个问题前，我们先来尝试回答一下，为什么有些同学会被称作牛人？他到底牛在哪里？如果抛弃形而上的物质事物，他的思维可能是他最超出常人的地方吧。而这也是决定ET效果的重要因素。
做好记录，实际上是在帮助我们梳理ET执行过程中的思考路径。同时，请一定记住，这个记录是做给你自己看的，不是用来给别人看的。通过这个记录，当做完一个Session后，你仍然能够清楚的回忆出走过的测试路径。
做记录的时候，需要记什么？这个没有固定的内容，你可以记测试点、时间、发现的Bug等等，但是有一点一定要注意，如果在测试的过程中，你做了什么决策，请务必记录下来。也就是说，在记录中要能够看出你的决策点，这些决策点是下面Debrief的重要内容。
在记录的形式上，有些同学爱用鱼骨图（有时间轴的感觉），有些同学爱用思维导图，有些同学爱用即时贴，有些同学就随手记在本子上，这些都不是问题。你想怎么记就怎么记。说起来很简单，而在实践过程中，大家往往不太容易去尝试记录测试过程（注意是测试过程，而不是单纯的测试点），同时记录本身也需要花费一点时间，但是你一定要尝试着去做，不一定太复杂，你自己看懂就好。
五 讲思路说到这一步，就涉及到ET当中非常关键的一个活动——Debrief。Debrief的原意是审查，其实是由ET的执行者和其他干系人，比如SM、TL、DEV等一起来沟通Session的测试情况，然后决定下一步的测试方向和计划。
其实，在Debrief的时候，有三点需要留心，首先，你在刚开始做Debrief时，可能会按照下面这种说法来描述：这个Session，我测试了palapala，发现了什么什么，下面决定干啥干啥…… 这样其实挺好，达到了Debiref原本的要求。但是我想说，这样做远远不够。我们知道，ET和个人能力有很大关系，那么我们的测试能力又如何提高呢？重要的话说三遍：牛人牛在他的思路。我们在Debrief时，邀请了那么多牛人，那我们为什么不看看他们的测试思路是什么呢？但是怎么看？你首先就要说出你这个Session的思路，和它走过的测试路径，特别是你在测试过程中的那些决策点。这时“做记录”的成果就能排上大用场了。它能够帮助你清楚的复述出你的测试思路和测试决策。而大牛们重点要关心的，或者可以提出有价值建议的，就是告诉你，你这个决策可能还不完备，你的思路还有哪些缺漏，你应该怎么思考问题。而具体的某个测试点是不是要测，你自己完全可以做确定。所以，应该充分利用Debrief过程向大牛们去学习他们的精髓。我自己亲身经历过一次成功的Debrief，当执行者讲述到我当时是这么想的…..，所以我决策这么干时，一位同学马上跳出来说，我觉得你应该重点测试…..，原因是…，你应该按照这个方向走。大家听完，立马一股清风扑面的感觉。
第二，做Debrief时，不要包含过多的内容。为了保证debrief的效果，应该加大Debrief的频度，让每次Debrief的内容精简、聚焦。我们在一个测试执行工作量3天的特性中，尝试做了5次Debrief。每一次，都会有一些新想法冒出来，然后就会立马在下一个Session去尝试。
第三，我们建议，不一定要等到测试执行一段时间后，或者测试完成时，再进行Debrief，这样做更类似于复盘。我们应该尽量让Debrief做到承上启下，做到提前为主、预防为主。我们现在的做法是，在完成“汇信息”、“画地图”后，就做第一次Debrief，先整体聊聊这个特性的ET测试价值，决定我们第一步往哪里做。其实Debrief，是ET当中一个相对比较容易落地的小实践，它体现了ET在实施过程中一个非常重要的方式——ET不是一个人在战斗。作为团队来说，有责任利用团队优势，更好地帮助、指导、教练（注意是教练，不是管理）我们的同学更好的实施ET。让我们就从Debrief做起。
六
理报告这一步骤，相对来说比较容易理解。但要注意两点，首先，ET理论中推荐进行TBS分析，也就是整体分析我们在真正的测试工作、Bug发现与定位、准备工作上的时间分布，从而发现问题。这一部分，大家可以尝试。第二，我们需要把整个ET过程中的所有信息进行汇总，注意是所有信息，包括没有测试的地方、风险等等，信息愈多越好。因为作为测试工作，我们的核心价值并不是判断结果，而是提供信息。
说完了上面几步，还有一些零碎的东东，再花一点篇幅进行说明。
首先说说ET在执行中的一种形式—— 结对。结对是敏捷中一个比较经典的实践。在ET执行过程中，也有应用。结对这种方式会更有助于ET的开展吗？通过我们的实践发现，在ET中使用结对方式可能也会有一些问题，这可能也是ET本身的特点所决定的。回想ET给执行者所创造出来的自由空间，它希望执行者能够在这个空间内根据自己的想法、实践去进行尝试，而在这种自由空间下，很难说某种尝试、某种路径的是非好坏。而结对则希望在执行的过程中，能够通过交流、碰撞，来达到相对更好的一致。我们在结对ET的尝试中发现，在很多情况下，双方的思路其实并不能很快达成一致，更没有好坏之分，大家之间互相的研讨反而导致个体的思路受到干扰，效率降低。其实我们更推荐，由多个人分别独立的去做同一个特性的ET，这种方式大家在各自探索时能够保证各自的独立性和连贯性，而在Debrief时，又能够看到双方的思路差异，互相启发。
其次，随着个人不断的进行ET，个人可以尝试总结自己的 HTSM模型。把自己曾经的测试过程、Debrief、以及其他渠道获得的启发点进行归类整理，形成自己的启发式模型。这对于自己测试技能的提升非常有意义。
最后，一定要说一下对于 ET质量的评价和度量，因为这是一个非常引人关注的问题。ET的质量到底应该如何评价？可能被问的最多的一个问题就是，通过ET发现了多少故障？其实当你仔细去思考ET质量这个问题时，你一定会发现对于ET的评价肯定不能这么简单。举个例子来说吧，还是上文提到的那个我们做了5次Debrief的特性，我们通过ET并没有发现什么传统意义上的Bug。但是当我们去和执行人员、项目干系人沟通，询问他们对这个特性的质量感受和评价，他们都觉得测试很靠谱。是什么给了他们这种判断？其实就是我们通过ET所汇总呈现出来的各种信息。对于ET，个人认为使用360度评估更加合理，如果所有的人都认为质量可控，那么我们没有理由说，不发现故障的ET就是效果不好的ET。如果我们把ET比作画家的一副作品，我们真的很难用KPI来说明这幅画有多美，因为做ET的不是机器。
虽然有了“汇信息、画地图、定范围、做记录、讲思路、理报告”，但是在本文的最后，还是让我们再次
回归ET的本质。探索性测试，它是把测试学习、测试分析、测试设计、测试执行充分同步结合的测试方式，它更关注学习与分析；它是想通过实际的反馈来帮助我们进行测试决策；它更关注缩短测试反馈环。它只是一种测试的风格。而这种风格其实不就是测试原本应该的样子吗？