请谈下您对探索式测试的理解，请分享下这方面的实践经验？
徐毅：其实探索式测试是什么，Cem Kaner和James Bach的一些文章、PPT都已经写得非常清楚。
首先探索式测试是一种测试的“方式”（Way，或Approach），而不是测试“技术”（Technique），方式也即是指完成整体测试工作所选择的办法，而技术则是指对于局部测试工作进行操作的方法。
其次，ET的目的在于“探索”，也即有一个明确的测试目标，但是目标的细节或是达成目标的步骤尚不清晰，所以需要边走边看，同时间地进行学习、设计、执行、解析的结果，与PDCA循环颇有相似之处。
第三要区分开ET和手工测试的关系。“手工测试”所强调的是执行的手段，也即“手工”。而ET主要强调目的，也即“探索”，当然还有就是，执行只不过是ET中的一部分而已，而这一部分，可以借助自动化。例如，修改某个已有自动化测试脚本中的部分测试数据，借助于脚本快速地执行某些操作，而去掉或暂停分析部分的脚本执行，因为此时测试的结果未知，需要依赖人工来判断、分析测试结果。
公直：探索式测试最近2年异常火爆，很多人以为是最新出的一个测试技术或者方法。Cem Kaner 在1983年（都快30年了）就提出了。这是一种强调个人自由与责任的测试方法，让独立测试人员可以借由不断的学习来改善测试的规划与测试的执行，而在测试的过程中也会同时改善测试用例从而达到相辅相成的效果。在一淘这边，其实很早就开始使用这种实践方法了，但很多一线的测试人员并不知道自己的做法就是探索式测试，在互联网研发模式下，一般都或多或少地使用敏捷模式，或者其他的土方法，但迭代周期都很短，一个月就要上线。在这样的环境下，文档少，在测试计划制定设计上都不可能完善，一般在测试过程中是用freemind等脑图工具来记录测试执行过程的同时做测试用例的设计，这种方式可以做常规测试的补充。
杨进：我很喜欢探索性测试，它让测试工作变得轻松和富有创造力，它能让你无需复杂的测试准备，就直接进入最核心的测试工作，并且不拘泥用什么方法、什么工具，也不用考虑能否能被自动化，只需要关注能否快速的找到bug就行。当然好的探索性测试实际上对工程师的逻辑分析能力和产品整体理解要求很高，这种依赖于个人能力的测试手段，执行的效果也比较难以控制。
探索性测试的实践方面，我们之前尝试过多人组队测试，这种方式适用于多人进行的大型项目，大家一起进行探索性测试，bug系统即时显示你在这个版本发现了多少个bug，并且排名，我们每天乐于寻找更多的bug，并且分享找bug的技巧，在这个过程中我们都得到了很多的成就感，并且对产品的理解和测试技巧也大幅提升。现在回想起来也还是一个很有意思的事情。
您怎么看敏捷测试，执行后会质量有哪些明显的改善？
徐毅：我认为，敏捷测试（关于敏捷测试的定义、介绍，请参考Lisa Crispin书中的描述）并无法单独的执行，必须在敏捷的环境下，结合开发人员方面的敏捷实践（以及组织结构）齐头并进方可实现。而此时，质量的提升乃是源于软件开发工作整体的改善，很难说一定是测试的功劳。另一方面则在于，测试本来就无法“控制”质量，自然也无法改善质量，因为测试工作本身并不改变那些可以影响质量产生的因素。但敏捷测试的实践对于质量的提升是肯定有影响的。
● 敏捷中对于团队内外参与、交流的追求，能够更容易“do things right”
● 快速地交付和反馈，有助于做到更多地“do right things”
● 完整团队、跨职能团队等实践，团队负责自己的工作方式改进，更容易做到“do things rightly”
公直：敏捷测试是一个被过度炒作的概念，和架构师、云计算一起被大家私下称呼“大忽悠”的工具，特别是最近几年。传统上将敏捷测试就是在敏捷研发流程下的测试，例如使用XP、或者scrum的研发流程下的测试活动，怎样在这样的研发背景下做测试，挑战在于如何使用敏捷的流程。另外一种敏捷测试，就是按照敏捷宣言中的几个关键词，“速度快”、“反馈”、“持续”，做的测试。由于敏捷强调的重点，还是在“快”上，无论中文含义的字面解释，“敏”、“捷”其实都是快的意思，这正是自动化程序的特长，机器的运行速度总是比人的操作要快，所以我们一般在敏捷项目中使用了非常多的自动化技术。个人感觉十分使用敏捷测试与质量提升方面没有直接关系。
杨进：我理解敏捷测试就是让项目相关的角色全体直接承担项目最终目标，由于都是为最终目标服务，因而角色也变得模糊，并且每个人的工作也需要考虑是否对当前最急迫的事情，这种集中所有角色力量为共同目标前进的开发方式，减少了大家沟通和项目迭代成本，最终很容易得到项目整体效率和质量的提升。由于各角色对目标理解一致，对产品理解都很深入，因而可以更多的把bug消灭在开发的早期，比如单元测试、新功能测试阶段，使得后期的集成和系统测试问题变得更少，尤其是产品最终的效果问题也会减少。
