探索式测试实践之缺陷大扫除和结对测试
探索式测试的定义在我的blog都做了较多说明，其中也谈到了探索式测试在项目的实践方式，接下来会详细的说明其中来亮个实践方式的具体实施过程。
探索式测试四象限
探索式测试是一种测试风格和思考方式，它强调的是学习在测试过程中的作用。无论测试人员在做功能测试、性能测试、安全测试或其他类型的测试，都可以使用探索式测试的思维方法，来帮助自己找到初始测试设计未考虑到的危险区域。
探索式测试不只是在脚本测试后才开始，它可以应用于软件测试的各个阶段。作为一种测试风格，探索式测试可以使用适合当前情景的任何测试技术（包括脚本测试常应用的测试技术）。那为什么我们还要把探索式测试和脚本测试分开呢？这是因为探索式测试的优势来源于并行地实施测试学习、设计、执行和评估，来源于测试人员在此过程中的积极探索和主动调整，如果一再强调把探索式测试融合在脚本测试过程中，将不利于观察到探索式测试的内涵和潜在效果。
测试专家James Bach曾经对探索式测试(ET)和脚本测试(ST)在项目实践过程的变化进行了对比，请看图 1
从严格的脚本测试到自由式的探索式测试，James Bach做了如下解释：
最左边的Pure Scripted，是严格的按照测试用例来执行测试，而且测试用例非常详细，在项目测试过程中较少存在这种现象。
最右边的Freestyle ET，是自由式的探索式测试，在测试执行的时候不依赖于测试文档，只记录产品缺陷和风险除外；测试执行之前不需要任何特别的准备，比如测试设计。
这两种测试方式都是不常见的，有些走极端的倾向。在项目测试过程中，不可能完全采用Pure Scripted或Freestyle ET。比较好的办法是在项目中混合脚本测试和探索式测试，并在不同的项目中采取不同的混合方式来制定项目测试计划。在大部分的项目测试过程中，综合脚本测试和探索式测试的优点可以得到较好的效果。
目前许多测试团队以脚本测试为主导，偶尔在测试执行的时候发散性地去测试有疑惑的地方，但该发散性测试受经验、时间、功能特性、测试任务等众多因素影响，其结果无法跟踪，且经验不能传承。 为了更好的组合脚本测试和探索式测试的优点，可以考虑尽量减少编写文档的时间，也可以考虑增加在测试执行时学习产品和技术的时间，从而带来更强的思维扩展性。
下面简单介绍如何组合脚本测试和探索式测试过程中需要用到的几个关键性的因素：
Vague Scripted：比较简要的测试用例，是对脚本测试(ST)的初步简化，可以理解为测试人员需要编写测试用例，（但不必编写详细的预期结果）。测试用例可以包含操作步骤，但描述比较简单，其目的是留下更多的空间给测试人员在测试执行的时候自由发挥。
Fragmentary test cases：使用一句话或几个词语描述的测试用例，类似于脚本测试中的测试用例标题。
Charters：探索式测试过程中使用到的一个非常清晰的任务列表，指出了要测试什么、怎么测试（强调策略，不是详细测试步骤）、寻找什么样的Bug、有哪些风险、要去检查什么文档等。
Roles：测试过程中确定每个测试人员一个独立的角色去测试产品的某个部分。由测试人员自己掌控测试任务的进度和质量。
接下来将说明在实际的项目测试过程中，如何组合探索式测试和脚本测试。图2 展示了不同目的的探索式测试象限。
图2 探索式测试象限
象限编号的顺序与不同形式的探索式测试实践没有直接关系。例如，在我们进行 “Freestyle ET”形式的探索式测试实践时，完全可以采纳结对测试(Pair Testing)的形式，或进行探索式测试之后采用全民分享(All Sharing)方式来分享更多的测试经验。探索式测试属于软件测试的上下文驱动学派(Context-Driven School)，具体采用何种方式来进行探索式测试实践，或如何组合多种实践方式都是依赖于项目当时的情境，也就是项目本身的上下文环境。
由于本文只对第四象限的两个方式进行详细说明，则其他象限的具体实践方式不在此说明。特别说明的是象限一和象限四是两个面向探索精神的实践方式，象限二和象限三是两个偏向于流程和系统性的实践方式。这里需要强调的是ET主导的实践方式也是有一定的项目流程的基础和系统性的思维路径的，本文不做详细的说明。
象限四中的测试实践方式是由三个非常具有探索性的小活动(接下来称为趣味性的实践方式)组成。Bug大扫除 (Bug Bash)在微软使用得非常普遍，且效果非常好。 结对测试(Pair Testing)是与结对编程相对应，由两名或多名测试人员在一起同时测试一个SUT，并相互给出建议和指令，共享通过使用系统得到的(隐含)信息，从而不断的积累系统知识和测试经验。 全民分享(All Sharing)是测试执行前或执行后所进行团队分享的一个活动，具有不同背景和特长的测试人员分享自己发现Bug的思路，分享自己如何去测试软件，分享自己在某种测试类型上的策略。
缺陷大扫除
熟悉微软测试流程的测试人员应该都听说过缺陷大扫除（Bug Bash。它是一项短期的全员测试活动。在微软，许多开发团队会在里程碑（Milestone）的末期执行缺陷大扫除。程序员、测试员、程序经理、用户代表、市场人员在1~3天的窗口中，运用各自的技能和职业背景，集中精力来搜寻软件的缺陷。通常，每位参与者会获得一个小礼品，发现缺陷数目最多的冠军会获得一份大奖。
一般缺陷大扫除的组织者需要准备如下的内容：
l 活动对象：
l 活动时间：
l 测试环境：
l 如何访问：
l 测试数据：
l 项目功能：
l 问题反馈：
l 奖项设置：
l 已发现但在处理中的bug列表：
缺陷大扫除是常规测试的有效补充。测试团队将各个子系统连成业务系统，执行端到端（end-to-end）的系统测试，能够发现个人在子系统测试中难以发现的缺陷。此外，测试人员在测试不熟悉的子系统时，没有任何先入为主的“偏见”，往往能立即发现那些被“熟视无睹”的缺陷。而资深测试人员还可能发现一些初学者难以察觉的隐蔽问题。不过，相比找到的缺陷，我认为缺陷大扫除在以下两个方面更有价值：
(1) 团队建设。在日常工作中，测试人员更多的时间在独立地工作，彼此之间的联系并不紧密。在缺陷大扫除中，测试员进行渗透式交流，互通情报，一起嘲笑那些拙劣的设计、滑稽的缺陷，甚至说一些无关的笑话以相互逗乐。全部这些“小事”都在潜移默化中逐步凝聚一个团队。
(2) 团队学习。团队举行“缺陷检讨”会议，总结缺陷模式（bug pattern），完善测试策略，补充测试检查列表（check list）。这是一种积极的集体学习行为。在此过程中，测试人员可以积累经验、分享技能，测试团队可以沉淀知识、凝聚士气。
2011年度淘宝网的商品线也举办了几次缺陷大扫除活动，效果是比较显著的。对于互联网的测试行业，存在多个复杂的运行环境。用户群拥有的不同的浏览器、浏览器的不同版本、不同的硬件配置、不同的网络速度，这些都可能会影响网络应用的页面的展示和功能特性之间的交互。由于涉及到内部信息，本文不展示缺陷大扫除活动的具体数据。
我以前的blog也提到过国外有一个专门从事探索式测试的团队，有着非常高的单位时间缺陷发现率。我们可以通过多次开展缺陷大扫除活动，从而观察出每次活动缺陷发现前三名的测试人员。我认为这些测试人员可以是探索式测试团队的储备人员，他们还需要接收更全面更深入的培训，包括测试技术、产品知识、系统思维、测试方法等。这样的一个专门团队需要在实战和学习中不断的提高，让自己的处事效率更加专业和正确。一旦公司团队紧急需要（任务复杂度，紧急程度等），这些储备人员将以最高效的测试手段进行测试，最快速的反馈产品的质量，就像特种部队一样。但是公司领导需要明白的是，探索式测试团队测试产品后，仍有存在重要缺陷的风险。另外公司成立特种部队的主要目的是让他们传播经验、培训员工。让大多数员工都成长，才是团队的努力方向。
总体上来说，Bug Bash 不仅仅能给项目的质量带来新的思考方法和参考指标（质量和用户体验上都有所提升），而且还会驱使Bug Bash的参与者更加有激情和热度去从事测试工作。至于Bug Bash活动的相关细则可以根据自己团队的特点来定制化，目标就是提升项目的质量和提高测试人员的测试敏感度、测试关注度、创造性思维、团队分享精神。
结对测试
当开发人员都在关注结对编程的时候，测试人员应该关注什么呢，如何来解决单人测试带来的测试遗漏这个问题呢，结对测试行不行呢？结对测试是软件开发中的一种技术，它允许团队中两个人一起测试某个产品，一个测试人员实际操作测试产品，另一个测试人员分析或评审测试过程和测试结果。
结对测试也未必一定是两个人，多个测试人员合作共同测试的时候就称为结队测试。测试人员都是很敏感的，在自己执行测试的时候，程序稍有一点反常，都会意识到可能是缺陷，一定会去究根追底，去确认到底是缺陷还是操作问题引起的。当测试人员互相交流发现的缺陷的时候，可能会互相启发去发现更多的缺陷。一个测试人员发现了一个缺陷，另一个测试人员可能发现和这个缺陷类似的更多缺陷，特别是在复杂环境下的测试。
两个测试人员工作在一起，在一个固定的时间段内一起产生测试思路，且持续的交换测试思路。假设我们需要进行测试设计，则一个成功的结对测试实践需要三个具体的条件：
(1) 至少有一个测试人员可以被信任且能在没有指导的情况下进行测试。
(2) 另一个测试人员需要参与到测试设计过程中。
(3) 两个测试人员必须要有一起合作的能力和心态。
在结对测试过程中，实践者需要注意以下关键因素。
交换测试想法
在很多活动过程中，将你的想法解释给其他人听是一个负担，但是在测试活动中，这将是一种收益。因为测试的过程就是一个测试想法生成的过程，解释和质疑的过程有助于培养出更多新的测试想法。尤其当某个测试人员的知识远少于另外一个测试人员时更是这样。很多情况下，一个测试人员单独的测试容易陷入到一个错误的结论，除非另一个测试人员质疑该结论，否则他也不会重新审视该结论。
关注个人和社会因素
我们不知道每个测试人员的个人特质，如脾气、技能、经验对结对测试的效果有多大的影响。但是结对测试的实践表明该活动非常有趣，无论你的经验是丰富还是欠缺。当然，测试人员必须是友好相处的，且在过程中有一定的承诺，如果某一个测试人员在工作过程中感觉到被攻击、失去自主权、或变得沮丧都会影响结对测试的效率。结对测试是一个比团队测试更加特殊的组织方式，结对意味着最大化每个测试人员的贡献。在某个主管和其下属的结对情况下，通过结对的提问和测试的演示可以让主管更加信任测试的质量。
与测程相结合
我们在结对测试的过程中，可以在早期选择好需要结对测试的测程，测程的概念在我之前blog中已经做了详细描述。在一个测程中，结对的测试人员有一个清晰的目标和测试策略。当然，由于结对测试充满着乐趣，则结对测试的时间段可以是测试人员的测程的间隙。
通过结对测试，对初级测试人员来说，特别是和资深的测试工程师结对的时候，是一个非常好的学习机会，学习测试思路的转变、业务需求的分析、测试时的策略等。结对的人员是搭档，而初级测试人员一般是在计算机上操作相关功能，他/她应该得到充分的尊重，是可以根据自己的想法去测试。
原则上，结对测试时的两个测试人员需要对被测需求负有共同的责任，但是某些人员存在自己的一些个性和处事方式，可能会影响结对测试的效率。此时应和资深测试人员或测试领导一起来沟通解决此问题，让大家对结对测试有一个明确的认识，一起提高合作效率。
总体上来说，有经验的测试人员和新测试人员一起结对测试会带来双赢的收益，这里我鼓励大家多去参与其他测试人员的测试过程中去。我需要提醒大家的是，结对的测试人员需要把握一个度，那就是测试人员给出的意见或建议需要有一定的价值（这样才能让测试执行人员更换测试步骤关注其他的测试点，若更换步骤后发现了bug就更有说服力），而不能频繁抛出自己的想法或思路（让测试执行人员产生不耐烦的心态）。
