背景：
记的看过一篇文章，《在效率这件事上，保守者谈“变革”，而激进者说“革命”》，当时，文章中提的很明确，之所以要“革”，是因为目前的方式，无法满足要求了。如果什么都不变，必死；如果变的方向不对，或过大，也必死；
所以，文中建议，对于保守和激进两种方式
· 都用，但要尊重环境，相互借鉴；
· 保守的运用一些东西，但不一定直达目标，迂回前进，因为直达目标的路，可能困难太大。
· 在必要的地方引进一些激进的方法，不要错过跳跃的机会。
这篇文章其实是在讲Scrum和Kanban的，但是看完后，第一反应，竟然是当时在团队提出和使用“探索式”测试这种新的测试时的考虑惊人的一致，所以，在这里权当借鉴了
好了，说到这，先说说当时的一些情况吧：
我们目前的团队一直在做导航的产品（美国，印度都有工程师），这款产品在美国的Verizon有几百万的付费用户（免费用户数量就不知道了，但肯定不少），所以，产品事实上对于质量和稳定性的要求，满高的。团队刚成立的第一年，确实，当时人手不足，而且，因为系统已经被美国人开发了不短的时间了，所以，当时的管理者们，把精力全都放到了如何熟悉当时已有的系统构架和技术上去了，培养团队，也是以开发为主。当时，确实是忽略QA团队挺多的
后来，随着我们对于开发越来越熟悉了，中国团队也是越来越被重视，测试团队移向中国，也越来越提上日程。当时我要是记的没错，测试团队的建设速度，真是挺快的，而且，也真够大的。QA团队最大的时候，美国估计至少40人，中国这边，也得有40多人。从最最早期的测试是一个团队，后来测试内部也分成了三个团队，包括：CT（组件测试）, FT（功能测试）, ST（系统测试）。当时美国测试的老大Randy是一个很有经验的测试管理专家，他在给美国介绍这个新的架构时，正好我也在美国，听着他当时的设想，CT负责什么，FT负责什么，ST负责什么，如何通过三个团队的合作，来让测试的效率最高等等。。。当时，我记的他还说过一句话，大意是：“要通过测试管理，让只了解我们产品怎么用的人（就算不是计算机专业的），也能有效的测试好我们的产品。”。。。说真的，当时我真觉得，厉害啊，这套方式如果真的可行，真的会大大的降低用人成本，而且，效率会提的挺高的。
我还记的当时中国这边的配置大概是这样的：10几个CT的，20几个FT的，8-9个ST的工程师。。。因为人数重多，当时招了3个测试的manager，其中还有一个外籍manager，来自新西兰。当时Manager们开会时，你会明显感觉到，几个人雄心壮志的，确实，有人，又有足够的支持，而且，manager的配置，都比我们这批土家伙们，强了不少，自然，成绩的期望值就是很高的。
当时，虽然我没有亲身经历，但确实眼见着QA团队
· 非常重视test case，case 的 review一轮接着一轮
· 培训做的越来越多（没参与，所以不知道具体内容，但次数真多）
· 自动化的CT工具，越来越多，有好多放到Perforce上，都不知道干什么的
· 测试工具的开发也越来越正规，有的工具的开发周期，都是以年来plan的。
· 测试团队的影响力，越来越有分量，质量标准定完后，就算可能延期，也不能变，比客户的要求，看上去都高。
· 团队真的很努力，有时候release出来的晚了，整个团队加班到很晚的次数，真不少
不过，几个月后，问题是一个接一个的来了
· 最重要的一个，项目的质量，没有因为人员大大增加而提高；记的特别清楚，我负责的vz android项目，测试结果让Verizon很恼火，因为大量的问题直接在用户那体现出来，公司上层很震怒。
· 看上去CT,FT,ST应该是一个合理的分组模式，但三个team之前，无法说清楚谁测什么，如何在一个项目中合作来保证质量，导致最后，ST的工作量和压力还是最大，但人最好，弄的开发周期是3个月，测试周期，也是三个月，还得再加一个月改bug的时间，projectmanager直接就说，这是本公司特色，别的公司，根本没这事。
· 矛盾，特别是开发和测试的矛盾也越来越体现出来了，记的挺清楚的一次，开发的老大找到测试的一个工程师，告诉他关掉一个bug，并明确告诉他，不是不尊重测试，而是希望他先professional些再提bug。
· 测试团队内部信心也不足起来，有不少人开始觉得自己做的事没法有成绩，没有被认可感，一部分人开始离职，或转开发了。
当时的几个经理们，意识到了问题的严重后，也确实考虑过很多方式，来尝试解决问题（这时候，不得不提的是，美国的Randy，QA的老大，离开了，很多人都说是解决不了目前的困境，不得不离开的），比如说：
· 更多的培训，特别是更多的工程师去US，和US工程师一起工作，来提高能力。
· 让开发参与测试，不能光让QA测试（特别是提出，开发才是质量保证中最重要的参与者）
· 让开发和测试一起review test case。
· 加强文档化，让文档化来驱动测试的准确度，由文档来尽量的保证质量。
我当时是开发的经理，Product manager我并不参与，所以，我事实上对1和4，没这么关心，但对2和3，我提的问题很直接
· 让开发参与测试，那开发的任务怎么办，还有，你建议开发怎么保证质量？（我们已经有代码review和单元测试了）
· 一起review test case，这个工作量，可真不小，弄个feature，基本都得出几百条case，一个个的过，别说让开发尽量保证case质量，就是过一遍，时间也不短了；要是只做为参与者，估计很多开发真的光参与，不说话了
同时啊，不光是开发经理，别人也都直接提意见了
· Boss对第一点提的很直接：出差的费用并不低，你能说明这笔钱的效果是什么吗？
· Product team的人也很有意见：文档的过细化，会大大降低product team的效率，你们要是完全依赖这个，Product team至少需要增加两倍的人手；而且，这家公司的文档一直都是，不算细，但也不算不细的，新加了QA后，反而效果降低了，太说不过去了吧。
这个讨论，似乎讨论了好久好久的，没办法，听上去大家全都有道理，所以，没法做决定。
当然，在这当中，也不是大家全都等着，各个team都在按自己的想法在做事，我的美国老板呢，因为要负责Verizon android的release，所以啊，压力特别大，特别是怕测试上再出问题。所以，她把参与release测试的几个QA的信息告诉了我，并直接要求中国管理层受权，让我来统一管理，别的不为，就为了保证项目运行正常。
当时，压力真的挺大的，毕竟，我没弄过测试的东西，人家说的不少东西，我只是熟悉，并不精通，不过，有一点现在想起来当时做的还不错的，就是一直在training参与的QA人员项目需求的东西，当时花了大量的时间来给测试的人来解释需求，甚至，都来给大家解释开发大概怎么设计的。整个项目，持续了大概半年，当时，至少我感觉有两个收获，还不错
· 和QA团队的关系，弄的不错了。因为我讲的时候，真算是努力的，所以，大伙对我不错。
· 项目呢，出了一些事，但相比之前，算少多了。（特别是，比其它的项目顺利，就让我的boss，被突出出来了）
可能也是因为开发部其它的老大们发现了我们的做法，能产生一些效果吧，所以，大家在后面的一年内，开始效仿的就多了起来，虽然各个模式不同，但情况真的好转起来了。
可能是因为公司高层认为就算是有变化，但还是太小吧，后期，新来的CEO，在推行iDev2.0的时候，同时将测试部门，整体的也分解，然后分进了不同的开发部门。也因此，开始了我探索式测试的参与以及推广。
第一阶段：问题暴露
刚刚开始带测试组时，本来感觉相对应该容易些，几个原因
· 和大家相对熟悉，而且因为之前帮QA不少东西，所以，大家也算比较认可我。
· 之前和大家的接触，也让我了解了不少测试的东西。
· 项目上因为一直都算成功，所以，在US和中国团队内部，都有一些威信。
但正式的接触了QA团队，特别是做为负责人的时候，马上我就开始发现问题了，比如说
· 很多测试成员，测试相关的技术的基础，确实差。。。举个例子，黑盒测试的几种方法，很多人都叫不上来名字。
· 很多自动化测试框架还在开发中，但深入之后，确实觉得对未来的作用，真不大。
· Test case的review，真的要花太多的时间了，而且，往往看来看去，因为看晕了，容易忽略到重要的部分。
· 开发和测试很难融合进去，要是让开发跑case,跑的结果其实挺对付的；让开发写case，就更有问题了，开发的时间全占了，测试又相对轻松，怨声哉到的。
· 因为测试“归”开发管了，所以测试很多人就在等你下决定，什么bug应该提，什么bug优先级高，弄的你也会觉得挺难受的。
· 测试的管理中，有不少流程化的东西，开发的manager其实不熟悉，也容易出错，让大家做起来都不痛快。
· 测试归了不同的“开发”组，导致不同部门在做的东西，有的重合了，有的呢，大家都没做。
· iDev2.0要求递归，要求把风险部分提前开发和测试，但测试上，写case等等工作，时间花的可不少，所以，越来越不适应这种快速迭代了（当然，其实不算多快速的）
其实还有其它的，但以上的，算是重点部分吧。所以，在刚一开始的过程中，其实效率在下降，有不少人开始质疑这种方式是不是真的是对的。
在当时，我也挺着急的，一方面，对于测试的管理上，需要进一步的熟悉，但几个“专家”给我介绍的时候，更多的是流程，比如bug scrub怎么做，case run如何运行，如何来评估测试所需要的时间，如何来给出test plan, test objective等等。我确实是试着运行了一段时间，但几个问题马上出来了
· 花了我太长的时间了
· test plan和test objective花了好长时间写文档，但最后，需求什么的一变，一没时间了，基本这个就没人在用了。
· bug scrub看上去测试在主持，其实product manager来决定什么bug应该如何处理，测试这边，主见真少。
· 忙忙活活的弄好了test run，但一轮轮run下来，发现bug真不多，有时候路测两天发现的问题，比这边测了几周的都不少，而且还严重的多。
· 每一轮测试都能发现新问题，就算build没变的情况下。（哈哈哈，对，没错，就是同一个build ）
· 开发开始抱怨测试占了他们太多的时间了，帮忙帮的自己手里的活都弄不完了。（确实，有时候，一个环境搭起来，没开发的帮助，测试花的时间就是太长，有开发的帮助，开发自已干活的时间，又短了不少了）
· 最重要的一点，和iDev2.0的冲突；原来不管测试时，只要开发满足了milestone的要求，我就轻松了，但现在，明显测试因为各种原因，跟不上milestone，也特别容易产生这部分代码一个月前写的，但一个月后，才测出来重大问题的情况。
第二阶段：各种方案探索
有了第一阶段各种各样的问题，事就来了，看看后面怎么解决吧，这种情况下，虽然很挠头，但一个一个来解决吧，好几种方法开始逐渐的尝试了
· 培训：我把这个叫QA基础重拾培训，黑盒测试方法啦等等的，每个测试选择一样，培训给组内的人。同时，也把相关的东西，培训给开发。（我们还培训了微软的测试体系，来给大家打开些见识）
· 共享：开发所有的设计的讨论，争取让测试全都参加，这样，看看测试的技术能力，有没有办法提高。
· 一快来review一下目前的白盒的测试的case，看看对于QA组来说，能不能减小一部分测试压力。
· Test case review中，花的比重比以前更大了。希望能够通过test case的review,来提高大家的能力。
· 抽查build，如果发现大家测试中没有发现的问题，及时反馈给团队，看看是case的问题，还是没测到的问题。
· 对于开发帮助测试的要求，从行政上给予大力的支持，甚至，有时候还“不得不”放慢开发的进度，来保证测试能够跟的上。
· 对于需求，开发和测试同时进行分析，而且，互相验证分析的结果，是不是共同的理解。
· 这个阶段，真的算是挺累的，而且，不光累，还是把好多时间，全都放到测试上的时候，开发这边，还好有几个不错的leader，所以，另外的三个组，算是有序的进行，要不，最后没准都得不尝失。
虽然累，但是吧，问题依旧有，而且还不小，比如：
· 虽然测试的进度好像是快了些，因为拉慢了开发的进度，所以，整体进度没有提高多少。
· case review越来越细是没错，但花的时间太长了。
· 路测和被用户发现的问题，依旧是很重要，但我们测不出来。
· 开发团队并不喜欢和测试团队合作，至少，并不主动。
· 测试团队也越来越消沉，因为对于好多人来说，和开发一起参与讨论，难度还是不小的，带着学习的心态去了，但是，有时候能听懂的东西有限时，心理打击挺大的。（有一部分QA成功了，但也有不少人，其实很明显看着跟不上）
有时候，我的boss为了鼓励吧，可能说我做的还不错，但是有了以上的问题，还是觉得，方法错了。。。
同时，白盒测试和自动化测试上，也越来越多的发现不足了，比如：
· 需求和接口一变，测试代码的改动，可真不小，导致一旦有项目压力，自动化测试就会被先放下，越积越多后，不容易再拿起来了。
· 没法说明自动化后，什么需求被覆盖了，所以，黑盒测试一点都不能少，项目的周期的帮助，并不大。
· 自动化测试的覆盖度，也不好说清楚了。。。什么逻辑被覆盖了，只要复杂一点，就不敢说。
· 跑了一遍自动化后全通过后，Client连接Server，竟然失败了，后面又加了近两周调试，才工作起来，让大家对于自动化的信心，真不足。
· 有的组稍微好些的，自动化的创建case，自动化的跑case都做到了，但是做不到自动化的验证，也让效率，很难让人满意。
（黑盒测试组的Leader，在公司呆了不少年了，曾经很蔑视白盒测试，认为做不了什么，投入还这么大，白白的花大笔的钱。。。）
第三阶段：思考。。。
有时候我会感觉，有困难有挑战的事情，会让我有很强的兴趣，虽然因为上面的原因，所以事情一度让我感觉很沮丧，但是同时，这段时间也确实是工作经历中最高兴的一段时间。
困难来了，想了不少的办法，但效果其实不高（相信大家也明白，有时候，纸面上的效果和真实的效果，有差距的，虽然公司一直说变化很出色，但我其实知道，没有解决根本问题，目前的情况，后面经不起风浪的）
当时我就在想这样一个问题，光中国公司的100多一点的人中，就有40几个QA，而且，效率还不高，这要是有一天公司有点风吹草动的，人再少些，我们的项目会因为测试，根本做不下去（很不幸，真的被说中了，两年半后，大风就真来了）
当时因为有些个带测试团队的经验了，所以，我就总结了在我们公司想要改变现状，新的方法必须要解决的几个问题
· 测试的效率：因为我们采用了迭代，所以，新方法必须要解决效率问题
· 对开发，得有帮助：相信大家也都会明白，如果一件事，对一批人没有帮助，又要很依赖人家，这事，人家上心的可能性，并不会太高。
· 得是现有方式的补充，不要轻易推翻：这个，真的不是保守，经历过的人都知道，推翻式的做法，有时候，就算好，但难度过大也会造成不小的问题。
· 策略下的自动化：我们公司的自动化弄的其实挺多的，但是如果一个需求过来了，却没人能说明，自动化跑过后，哪些需求能如何的被覆盖。大家讨论的更多的是代码覆盖度，但却无法说明需求的覆盖度怎么样。
· 让Review啊，容易些：当时公司内不少的管理者都发现了，测试的会是最多的，各种review的会，一弄就好几天。这个cost，真不小。但不review，又怕客户那抱怨质量。
· QA工程师的积极性，能调动起来。其实在没分组之前，不少工程师都离开公司了，大家统一的反映是，一遍一遍的跑case，发现不了问题，还被质疑工作不努力，没意思。
当时也是一个偶然的机会，看到了好多美国公司内部，都在推行探索式测试，后来也专门买了两本书来看看，刚看完的时候，觉得没什么用，怎么说呢，书上说的流程啊，确实会让人感觉不放心，特别是我们公司内部的开发流程，并不完全是敏捷的，如果按这测试“技术”或”方法“来做，相对于原来的规范都没有了，质量保证太难以做到了。
不过，外企的好处就是，你有机会接触到国外的牛人们。。。和一些国外的工程师聊的多些之后，他们给我一个很新的说法：探索式测试，是一种思考方式，不是行为标准；因为是思考方法，所以，它最大的作用，就是通过这种思考方法来解决你现有的行为方式中，不好解决的问题；当然，如果你是全新的公司和全新的团队，那一些国内翻译过来的探索式测试书中的工作方式，就可以裁剪后来采用了（注意”裁剪后“来使用，这和RUP非常类似，全部照搬，虽然没试过，但是，个人觉得风险还是太大了）
有了这个思路，我就列举了一个”新“方法必须要解决的几个问题
· 让review容易起来，让覆盖度更容易看出来。能够快速的帮助QA工程师发现测试中的事足。
· 减少文档化下，测试还能够被有效的追踪。
· 能给开发带来些帮助（开发其实也很关心质量，要是写代码时有人告诉他哪可能出错，很多人会喜欢的）
· 能让测试在不同的阶段，快速的发现重要的问题。
· 一套新的自动化方式，让”它“的test case能够直接的体现需求，同时方便的测试各种edge case，再加上，可以不依赖开发的进度来提前设计。
好了，先来介绍一下探索式测试中，我用的比较多的两个思路吧
· 局部测试法：特别是几大要素：用户输入（合法/非法，异常处理），状态（状态变化的状态机），代码路径，用户数据，运行环境。
· 全局测试法：定义测试目标，给出”漫游“的指导。。。
（具体的定义，网上很多，这里就不详细描述了）
好了，介绍一下我的思路吧
· 根据公司的情况，写test case呢，还是要写的；但是我会要求类似开发的概要设计和详细设计的流程；不要所有QA都是写了好几天后，拿来review时才发现思路不对。。。这时候，对于所有的需求，我会先让大家理解完后，分析一下“局部测试”中的几大要素，看看都需要考虑哪些内容，等大家这方面的理解一致了，再来写case（我把这个过程叫做测试的概要设计阶段之一）.
· 根据开发的进度，选择一个“漫游”的指导，来快速的进行build的测试；这时候，虽然case没有写完，但因为几大要素要是清楚了，又有漫游的指导，所以，效果会比以前强。这样，后期的话，case再补，也不至于成为项目的block因素。
· 改变写case的方式，把文字量尽量降低，我提倡test matrix的一种模式，其实就是列出一二三四级的需求分析树来，然后，再列出可能的“用户输入，状态，代码路径，用户数据，运行环境”，QA使用它来进行测试，虽然有一定的弊端，但速度上的优势，就会明显起来，特别是，有能力的QA的能力和潜力，会发挥的很大。
· 4．推行新的自动化测试框架，可以做到
o 在需求一致的情况下，一份test case可以测试不同的平台（android, iphone是至少的）
o test case基于xml或其它文本方式，QA也可以写，这样，降低对于测试人员开发能力的要求，同时，争取可以达到同样的效果。
o Test case与代码无关，只与需求相关，这样，代码啊，架构啊，接口啊的变化，不需要让测试重来，避免测试成为牺牲品。
o 写Test case时，可以产品代码还没做呢。。。（我当时想法很简单，TDD，就是让一批没有写代码能力的人，开始写Test case，开发可以拿着这个来测试他们写的代码，特别是，这是从功能角度上来测试他们的代码，而不是代码角度的）
o 能模拟各种异常环境。做过手机端测试的人都知道，正常情况下的测试其实容易做，也容易自动化，但是异常情况下的，就难了。比如说，服务器返回404，看看手机上的表现，正常的环境下，很难碰到的（这也是为什么好多QA测了好久，但一到用户那，就容易发现大问题的一个很重要的原因），这部分，要是手工测试，量很大，因为模拟这种环境很不容易，再有，如果是自己的产品，提新需求后，要是改的代码动影响了这部分，很难被发现，因为量太大了，就成了，测也不好，不测也不好的地方。所以，自动化测试，一定要覆盖这部分才有最大的意义。
o 测试和开发的讨论，以每个需求的为基础，避免进入技术细节过深，花的时间很多，但是效果并不明显。
当然，我在这里，还是想强调一下，我的思路中，并不想“颠覆”，只是想提高，同时，尝试解决上面提出的问题：
· 用局部测试法的思想，来让QA工程师描述出来写case或测试时，考虑的要点，如果要点是全的，测试或case的覆盖度，就容易有保证多了。
· 与开发的讨论，也重点是每个需求QA所考虑的几大要素，这样，用的时间短，同时，开发也容易在这其中找出一些他们没有想到的点（其实开发的思路很多是代码级别的，横向的思考，有时候是个缺陷，帮他们弥补这个缺陷，很多人很欢迎）
· Test matrix能在前期大大减少文档的工作量，写容易，review 容易，又能够快速的利用它进入测试状态，等测试完了，再补test case，不耽误项目周期，又兼顾质量和后期维护。
· Test matrix比一堆的test case，容易跟着需求变化而改变，这样，大家对需求变化的反映速度和理解态度，也提高了不少，而且，还没有真正意义上的改变流程。
· “漫游”方式的指导，也让测试能根据开发的阶段来定义测试方法，快，而且重点明显（比如，开发头几周的时候，好多功能开发自己都知道没完全弄完呢，这时候提一堆bug，没实际用处，但这时候如何整体的过一遍第一或第二功能要点的UI和基本flow什么的，如果有问题，肯定是需要被重视的）
· 测试框架不排外原有的白盒测试，只是更强调了“需求”相关case的自动化测试。形成现有的自动化框架的一个补充，当然，因为大家对于“需求”的完成情况，还有用户能看到的东西的重视，所以，这部分框架也容易被重视起来。
第四阶段：推广
上面想的这些东西，相信你刚看完时，也有很大可能性是持质疑态度的，一个新的东西，没被证明可行前，其实很难说服大家，特别是，我们公司的构架，其实有这样几层
· 中国的测试工程师。
· 中国的Manager。
· 美国的测试工程师和Leader。
· 美国的Manager和Director
· 美国的项目经理
· 美国的产品经理
说实话，就算是一个小小的变化，要想说服和证明给这么多关注点不同的人，也挺难的，所以，就算思路有了，其实也一样很难办（目前其实我在尝试一些互联网思维下的新产品的设计时，也碰到了这样的问题，有想法，但不知道怎么推广）
先不提推广，先来说说怎么让这批人意识到我的想法还算过的去的吧
· 中国的测试工程师和manager这部分啊，相对容易，因为我本身是manager，所以，在团队中，有一定的威望，大家听了我的建议，虽然并不是说很理解，但确实也会讨论的很细，讨论过后，也觉得只要得到US的支持，这个有可行性。
· 美国的测试工程师和Leader说实话，这部分挺难的，毕竟，我们的团队是在人家之后成立的，在他们的心中，我们技术和方法都落后于他们。所以，可以预见的是，碰的钉子，肯定不小。说来也算是巧，我当时，采取了另一种方式来让他们注意到这点。。。有一个机会，对方一个叫Satish的Leader，让我去review他们的一批test case，大概400多个吧，当时，我在五分钟后，给他们一个反馈，这部分case，有很大的不足。原因是：所有case的输入条件中，使用了同一个gps文件（什么是GPS文件呢，就是记录GPS点的文件，我们的产品，可以用它来进行GPS点的回放，对于让导航看上去是在美国取点和导航来说，很重要）。这件事，最后闹的挺大的，因为最后被证明，我的review的结果确实是对的，而且，按新方法要求后写的case的测试结果，用户的反馈就是高，当时的几个feature，几乎没出重大问题。。。所以，推广有时候不能光讲大道理，还要找准时间，弄点小技巧。
· 美国的Manager和Director有了上面的经历后，和美国Manager和Director的沟通，我强调的，就是快字。同时强调，次重要的文档性工作，可以放到大家有时间时再弄，这样，时间利用率高。（这个方式，很得不少老大们的认可，当时真让我感觉到，老大们看的，其实就是时间和数字，别的，他们会关心，但是更像是次关心的）
· 美国的项目经理
这个，在后期相对就容易了，给了两份计划，一份是按以前方式的，一份是按变化后的，end date上，前者时间比后者要长。项目经理的选择，就容易的多了。
· 美国的产品经理可能大家会觉得，产品经理管这些干嘛啊，这和我们公司的一些特殊情况，有点关系。我们公司的产品经理，有不少是有路测的职责的，特别是，他们要根据路测的结果，来评估一下用户的接受度什么的。他们经常在路测中发现一些测试中没发现的问题，所以，他们一直对测试有看法，认为测试力度不够。新的变化后，他们更是很担心，这个力度还不好说，而且测试的流程控制还变了，是不是会更坏。向他们推广其实也不难，找出几个他们测试出来的问题，分析一下我们的QA没测试出来是因为环境啊，还是输入啊造成的，然后给他们解释，说明我们的思路会如何贴近真实环境，他们的支持，就明显多起来了，甚至，会高于其它的美国“老大”们了。
说服大家相信这个会有帮助作用，其实说起来简单，事实上做过的人都知道，这个已经很不容易了，比这个更不容易的是，真正实施起来时，这里面就会有各种各样的问题了，比如说：
· 不适应感
相信带过团队的人都知道，一个改变，大家理解和大家适应，有时候，相差很大的，有时候，碰到很多细节时，会打消大家对这件事的积极性，让大家反而怀念原来的方法，特别是，原来的case，很容易就写好多，不少人觉得，没有功劳还有苦劳呢，现在，因为写的少了，所以，主要求快了，明显对于技术底子差的来说，各种能力上的问题就体现的更突出了。所以，为了解决大家的不适应感，要设定一系列好的样板，来让大家参考，如果有问题，也需要深入的来帮助；同时，还更进一步的要求培训上的力度，毕竟，压力=工作量/能力，能力大了，压力才会小，压力小了，才会适应的快些。
· 小范围内的不适用
任何一种方法，都会用的好和用的不好的区别，也会有适合某种方式和不适合的区别，这时候，就需要来参与，进行甄别，找出更合理的方法来处理，如果当时没有更好的方法，至少也要做进plan，未来进行改进。比如，当时有好多的错误处理，当时就计划着，在自动化测试能支持的更好的时候，再返回来改进目前的方法。
· 自动化之痛
新的自动化的工具的步伐，没有跟上测试思路的变化的时候，其实质疑声很重的，其实这个也有一定的道理，毕竟，很多看过中文资料中对于探索式测试的评价后的人，都会觉得，探索式测试和自动化，是应该一起推行的，一个不足，会让另一个出现很大的问题。在这里，就真的需要新老方法结合着用，然后，自动化工具的推进，也要同时进行，当然，这个自动化工具，是需要根据这个策略来的，不是胡来的。
推广真是挺累的，因为一定要深入细节，而且，在很多关键的地方，亲自参与，出谋画策是必不可少的。
推行了一年后，在原来所在的组，也自己认为是有点成绩了，毕竟：
· 原来七八个QA做的事，后来，两个QA就干了，而且，提出bug的质量，还越来越被认可，后来的几个采用这些方法比较熟练的工程师，都挺被认可的。
· 开发和QA的合作，也进行的不错，开发呢，也发现和QA的讨论，越来越能想一些个原来没想过的点了，而且，有的发挥的好的QA，提前就提出可能发现的问题，开发自主测试的动力，确实就多不少了。
· 周期越来越容易控制了，文档化越来越低了。到了后期，甚至US的Leader明确表示，测试紧的时候，不允许花时间写case，时间要花在有效测试上。这在以前，根本不可能。
· 对接iDev2.0更紧密了：以往两周时间开发，三天时间测试的周期，QA根本不接受，到了后期，最夸张的时候，1-2天，QA也能跟的上，而且这还是在需求变化相对频繁的时候。
第五阶段：变化着推广
好多人估计难以理解什么是变化着推广。。。这个，和我的个人经历就有关了，在原来的team，情况越来越好的时候，我被调组了，调来新组的原因很简单，大家觉得新组缺乏管理，容易出问题（具体的不提了）。。。
来介绍一下新组的情况吧：
· 新组其实分五个小组，每组六到七人，每组里都有两个或以上的QA
· 新组呢，QA和开发的合作更紧密，但是QAleader，其实没有，很多QA的技术能力都强，但测试的计划啊，文档啊什么的，不重视。
· 这五个小组中，互相还有一定的，算是隔阂吧，还有点互相不服气。
· 五个小组，看上去测试方法类似，但是，细听下来，因为每个组都是几年前是一个基础，但这几年全是自己发挥的，所以，相差越深入，感觉就越大。
· 几个组都重测试工具的开发，轻测试策略（开始大伙还不服，后来，有的人也意识到了）
所以，鉴于以上的情况，我在原来组推行的方式，其实就基本很难在用上了，毕竟：
· 我没这么多威信了，新来的吗
· 组内乱的多，一次培训，要分五份的话，时间占的太长了。
· 各组的测试方法不同，所以，要考虑五种不同的细节，再来推广
· 如果QA工程师重视的更多的是代码能力，认为这个高大上，再想改变大家的想法去考虑策略多些，真的挺难的（这点，很多人不理解，但真碰到了，可能就容易理解多了）
在刚进组时，我也确实尝试了一下和关键的测试工程师们讨论一下我的建议，但是明显的感觉是，推行成功了，肯定管用，但是成本太高了，我没这么多的时间，毕竟，开发的东西，我还不熟悉呢，我还要花大量的时间在开发的东西上呢（开发也是五个挺不相同的领域呢）
所以，不得不的情况下，九阴真经是用不上了，来点九阴白骨爪吧。。。在这个组，分析了一段时间后，我决定不提什么策略啊方法啊什么的了，而是，找出每个组，找出关键点来，其它的，加点引导，让大家自己来发挥
· 地图组：这个组呢，刚开始进入时，就发现了，主要的测试负责人能力不错，工具呢，也还可以，效率看上去可以，但是，也很容易被下游的“使用者”们发现这个组的bug.所以，和大家一块做了这样几个件事
o 重点列了一下测试的Matrix，看看有没有Miss的项
o 重新建议了一下自动化工具，这样，让配置测试工具的时间，大大减少了，有效测试的时间，增加了挺多。
o 虽然是自动化的case，也建议了新的分组模式，这样，在变动很局限的情况下，测试可以根据情况有重点的。
· 导航组：这个组和地图组很类似，主要的测试负责人能力很不错，但和地图组有所不同的是，这个组的case相当的多，而且在结果跑出来后，各种diff的检查，需要的时间也相当的高，所以，对这个组，最重要的建议就是列举测试的Martix来，然后根据不同的情况（引用局部法），来进行case有针对性的分类和抽样，这样，同时，也给出了根据不同的测试时间的要求，如何来更高效的测试的一个“漫游”方式。
· Geocoding组：
这个组的事，算是我一个痛点吧，这个组US的老大，相当的难缠，任何一点点的改变，要做的事真的太多了，因为当时我的时间，真的有限，所以，这个组上，我只是介绍了一下别的公司geocoding的测试大概怎么做，包括别的组大概怎么做的，真的没有精力再参与特别多了。
· Tools组：这个组是专门负责地图数据处理工具的，因为各种各样的原因，其实这个组本身没有专职的QA，虽然各种讨论一直很多，但是，当我进入不久，我也发现了，其实一个两个专职的QA，面对着近70个工具时，能够产生希望的效果的可能性，也不是很大。所以，最后我给这个组的建议，就是利用另外三个组的测试技术，形成一套对于自己组有用的case，同时，通过简化输入的方式，来进一步减小输出的复杂度，来让验证结果这一步能够更加快速，这样，将这个组的测试的重心，放到了能通过工具来进行“快速”初查的目的。
· 地图处理和地图测试组
这个组的特点，和上面的又不太一样了，第一，人数重多；第二呢，手工测试量很大；第三，测试周期长；第四，因为测试种类多，所以，测试工具集也多；第五，对其它组的依赖也大（测试数据，当时必须要Server大力的支持）。同时，这个组的测试人员中，也确实没有以上三个组中的几个关键人员的技术能力强。对于这个组的这些特点，其实真的花了我不少时间来去改善测试方式的，比如
o 自己总结Test matrix，找出需要测试的重点和次重点，对于重点和次重点，同时分析必要的局部测试法提到的几大要素
o 根据上面的分析结果，给出测试工具改进的建议（注：因为团队的特点，所以不轻易使用复杂的技术，都是很多简单的技术，比如，使用按键精灵来解决很多重复的手工操作的点）
o 重新定义了一些测试方式，来改变对外界环境的倚赖（这个团队挺支持的，毕竟，大家虽然技术能力不强，但也有不少人，希望做的更好些）
其实这里面要说的东西真的挺多的，但是因为篇幅的原因，重点提一下结果吧，通过以上的一系列变化，最后的效率优化的结果是：从原来的整个大组，近20个QA工程师，到最后，只剩下6个人时，测试的周期，比以前反而提高了一倍，举个例子，一个map data的测试周期，原来是1个多月，变化的后期，变成了两周。（公司后期因为各种原因，造成了需要大量减少人员的局面，因为这些个前期的工作方式的改变，也提供了一些可能性，当然，后面，也真是有些失控了）
之所以这个地方的标题是“变化着推广”，因为在这整个的过程中，我没有在大张旗鼓的推广“探索式”测试这个概念了，而是用这种思想，来找出一系列可以改进的点，通过改进点的方式，来改进效率。当然，如果后期再更多的推行这种思想，也许效果会更好，但很不幸，因为公司的变化，不大再有机会了。
总结
其实根据上面的经历，我到真的觉得，探索式测试之所以被不少人看好，也被不少人不看好，可能真的是因为大家有一部分人过于把它当成流程或工具，而没有把它当成“思想”，一种有一定指导，但又有各种各样充分发挥空间的“思想”。
在这种“思想”下，它能够帮你解决一部分问题，但同时，也会让你碰到一系列的问题，真正的能力，就是看你如何利用它，以较小的代价，解决更大的问题。它不是黑盒测试，也不是白盒测试，也不是自动化测试；它能够用于的，也包括了黑盒测试，白盒测试，还有自动化测试，同时，还有一点更重要，它可以给开发的自测和Debug，提供一些建议，这个，对质量的帮助，更加提前。
后来，团队中有一个人这样评价我：你像是一个测试架构师（这个人后来去别的地方，至少职位就是一个测试架构师了）。我当时其实也对这个评价感觉挺好的，特别是我自己把自己，定义为开发团队的管理者呢其实。
最后总结一下我的个人感觉吧
· 把它看成思想，别当成工具。
· 推广中需要技巧，包括时机。
· 测试其它的基础知识，也不可缺少，没有好的基础，思想也难起死回生。
· 使用探索式测试，是门艺术，而不是手艺。