在谈论Bug Bash之前需要先介绍下Bug Bash的来源和意义以及ZBB（零错误反弹）

　　1、Bug Bash的来源和意义：据网传说Bug bash（Bug大扫除）来源于微软，通常发生在项目开发各阶段的末期，比如Beta版发布前，划出一个专门的时间段（通常1-3天），在这期间所有参与到Bug Bash的项目人员，集中全部精力，运用各方面的知识，尽全部智慧来搜寻项目的Bug。

　　2、ZBB（零错误反弹）：

　　Zero Bug Build：这一版本的构建把所有已知的bug都解决掉了、或者是目前活跃的BUG趋近于0、或者指在项目中的某一个点上，开发活动最终赶上了测试的步伐，当前已经不存在活跃错误。

　　Zero Bug Bounce：通常在一个Zero Bug Build之后，bug数目会以惊人的速度反弹，故称Bounce。系统要经历几次bounce，像阻尼震荡一样，bug的数目在弹了几次之后，最后固定在（或者无限逼近于）0。

　　Bug Bash注意事项：

　　Bug Bash是一个非常有意思、有挑战性的活动、但要组织好这样的活动并非易事。一般有以下要点：

　　（1）尽管这是一个测试活动，但参与者不能仅限于测试人员、建议是整个项目组成员都参加、包括项目经理，产品经理、开发人员。如果高层管理人员能参加就更好了，如同全民动员。目的是要集思广益。

　　（2）要鼓励各部门，领域交叉搜索，因为新的思路和视角通常有助于发现更多的Bug；

　　（3）为调动积极性，增强趣味性，可以适当引入竞争机制，比如当活动结束时，评出发现Bug最多，发现最严重Bug的个人，给以物质和精神奖励。

　　进过上面的一番介绍对Bug Bash有了一定的了解、那么我们可以考虑下

　　起因：

　　1、产品准备要实测了、

　　2、或者是测试活动中已经2周没有BUG产出

　　3、再或者是BUG已经趋近于0了、也就是达到了ZBB（零错误反弹）的临界点了。

　　目的：

　　1、调动全组积极性，换一种思维和方式执行测试

　　2、市场和需求人员从用户的角度分析，会发现一些测试人员想不到的问题；

　　3、开发人员知道从代码、白盒的角度分析问题会发现测试人员想不到的问题；

　　4、提早发现bug，降低软件风险

　　5、长期的测试容易使得测试人员形成思维定式或疲惫，通过这个小活动增加软件测试的趣味性和新鲜感

　　风险：

　　1、大家的积极性都是被调动、奖励机制一定需要、而且也要强调这个活动的必要性和重要性

　　2、所有参与Bug Bash的人员的时间需要保证

　　3、产品版本的稳定性必须要保证

　　4、各个部门领导对Bug Bash的支持程度

精辟名言

　　当你读一本书，读到某句话或某场景，是否有这种感觉，有很多想说的话，竟然作者 替你说了；有很多场景，似曾相识，貌似曾经经历过，一切都是那么的熟悉。心中自然激起一层层共鸣的涟漪，或掩卷而思，或“拍案叫绝”，或许这也就是所谓 “书中自有黄金屋，书中自有言如玉”的读书之妙处吧。这样的书，谓之好书。由于每个人的背景都不同，你认为的好书，他人并不一定能找到同感。由于工作原因，读测试专业相关的书籍不少，但让我记忆深刻，并会常常拿出来翻来翻去的好像并不多，不过JW（James A.Whittaker）的<<探索式软件测试>>是例外，主要原因并不因为它是目前市上讨论的焦点之一，而是书中的一些精辟名言让我觉得很受用。

　　例如：最近发生在身边的一些事情，让我一直在反思“测试的价值到底是什么？”，围绕这一主题思考，便又想到JW在书中提到的这句精辟名言：

　　“软件测试的真正价值并不体现在代码中找出了多少缺陷，而是发现设计和编程人员解决问题方法上的局限，思路中的狭隘和技能方面的不足“（托尼.霍尔，1996）“

　　当第一次看到这句话时，正如前面提到的，激起了我思想的层层涟漪，似曾相识，道理亦明，似是心中埋藏很久的一句话，终于有人替自己说出来了。怎么好的至理名言，不敢独享，于是把这句话放在新浪微博上，与圈中朋友分享，见如下截图，自是引来不少同仁的反馈。

　　为什么会激起我思想的层层涟漪，品着这句话，回顾过去。如果说过去我是无意识地去影响开发，那是因为有足够经验的驱使，为了把产品做好，不仅是软件开发人员，还是需求设计人员，甚至是产品开发链的其他成员，我都会主动出击去影响他们（或许这也是一个加勒比海盗学者的特点之一，读<<学习要像加勤比海盗>>后的自我发现）。常常，在面试时我会问应聘者：“做测试工作，让你感到自豪的事是什么？”，大部分人回答的是:“发现Bug，特别是一些让开发难于解决的严重bug，是最开心，最有成就感的事了“。而相反，测试大师们恰恰建议我们要丢弃软件缺陷数量、缺陷严重性、测试用例的 多少、自动化代码量等可量化的衡量指标，转而通过观察测试人员提高了多少开发人员的工作绩效来评估。面对这些差距，笔者倒也觉得正常，如同做任何一件事都 有一个循序渐进的过程，毕竟软件测试在国内的起步较晚，据去年我做的一些数据调查，基本上晚了约20年。但，这并不意味着我们只能望洋兴叹，站在巨人的肩 膀上，我们可以看得更高更远。

　　前行中的反思

　　就测试而言，质量如生命，效率如健康。软件测试人员是质量的最后把关者，守护神，这个我们都谈得很多了。谈到质量，我们会提及很多方法，如黑盒，白盒，灰盒，最近比较流行的敏捷测试，探索性测试等。谈到效率，我们会不由自主提及自动化测试， 自动化工具等。测试的使命就是围绕产品的质量、效率转。我们的出发点都很好，但在解决问题的方法上，往往是集中在结果上，即出现了什么结果，再去想办法解 决它。对于测试来说，可以理解这个“结果”就是软件的缺陷。我们经常也谈，测试要尽早介入，尽早发现问题，尽早把bug消灭在摇蓝中等。这些说的都是事， 而我们恰恰忽视了一个很最重要的东西，就是在整个产品开发链中，产生这些事的人的问题。（注：这里不是谈人的管理问题）。如果我们能盯住人（角色），因为 这些问题实际都是由前面的人产生的，我们是否可更加轻松。

　　把我们的眼光放得更宽远一些，锁定可能会出现问题的设计人员或编程人员身上，用心去发现他们解决问题时的方法局限，思路狭隘或技能不足的体现，便能尽早发现问题。下面是案例分享。

　　【案例】用户场景联调

　　说明：故事是真实的，但为便于阐述及机密原因，案例中的人物及相关信息，采用化名

　　人物：

　　D0：软件项目经理

　　D1：Team 1的软件开发工程师

　　D2：Team2的软件开发工程师

　　D3：Team3的软件开发工程师

　　T0：测试负责人

　　背景：

　　P-001是一款基于Linux平台开发的医用设备软件，属于嵌入式软件系统，按计划明天早上需发布带打印功能的软件版本。

　　发现问题：

　　为顺利开展明天要测试的软件打印功能，测试负责人T0已把相关测试人员的工作安排就绪。按惯例，开发人员提交代码正式发布版本前，应该确认自己 所提交的功能是否符合需求，不存在低级问题。例如：打印功能，在UI层用户通过点击“打印“按钮即可得到一张数据报表，这也是团队对开发人员的基本要求。 但是，此打印功能涉及多个子模块，这些子模块分别由不同的开发团队完成，各子模块的逻辑关系如下图所示。

　　T0很清楚一些开发人员的想法、特点，也即是他们的思路狭隘点。尽管有流程或规范要求要如何做如何做，据过去一些项目的经验，总会有一些开发人员爱犯错，事后找一堆这样那样的理由，言之什么是意外，什么什么又是意外等（其实是没有克服一些困难）。

　　负责P-001项目软件开发团队的办公位置离测试人员并不远，抱着几分担心与怀疑，T0在发版本的前天下午便主动过 去“打听军情”。得知负责打印模块的开发工程师D1并无用真实打印机确认他的程序是否能在用户场景下跑。他给的解释是这样的：“我调试过程序，是没问题 的。为什么呢？我负责打印的应用层部分，责职是收集用户的数据，并按要求准备好指定格式的数据，然后把这些数据发出去，只要能发出去，就说明我的程序是没 问题的。目前我是采用虚拟打印机，即采用打印到文件中的方法进行调试的，我认为这样做是能达到预期的”。同时，T0也清楚地知道，负责打印模块中间层的开 发人员D2属于另一开发团队，目前正在为其他项目服务，同样负责底层打印驱动的工程师D3也不在项目中。

　　解决问题：

　　T0明白D1的调试思路，但如果打印数据子模块与打印平台（逻辑处理）子模块接口间存在问题，对于用户来说不是一样 吗，即打印失败。于是向他分析这样做可能存在的问题，如果问题一旦发生，测试人员必将会提交bug，并要求重发版本。与其这样，不如开发人员做一些必要的 用户场景使用的联调。D1表示也理解，好像该这样做，但表示他的时间有限，且他不知道哪里有打印机等等。T0于是又把P-001的软件负责人D0找来，说 明清楚问题发生的可能性，影响情况，并表示愿意提供打印机等资源协助相关开发人员进行用户场景的联调。

　　第二天早上一上班，T0发现并没有收到自动构建版本发布的邮件与QQ消息，问及软件开发负责人D0，回答：“打印平 台与打印数据的接口地方存在问题，昨晚已安排两人进行问题的排查，正在更改打印平台的相关代码，版本稍后发布”。事情正如T0所料，不过，问题能在版本发 布之前发现，要比留到测试端发现，提交bug后再解决成本低很多，这也正是T0想要的结果。

　　小结：

　　测试朋友，很熟悉的开发与测试工作场景吧。T0的行动，推动了把问题暴露在版本提交测试前，这对产品质量的稳定，开 发过程的成本降低无疑是有贡献的。或许，你会说测试人员提交的bug能说服开发人员去解决，已不是一件容易的事，更何况推动开发人员按你的思路去做某件事 呢？而这正是真正体现测试人员价值的地方。这不仅涉及技术、流程，还有沟通协调等。需要有足够的经验或知识去影响开发，帮助开发，让开发人员信服，充满挑 战。

　　细心的读者，也许你已从案例中发现了挑战的起点、方法。这里再补充两点可操作的思路，第一：从开发的差异性角度入手 分析，例如通常情况下，对产品的业务知识熟悉程度，测试人员比较优势，可帮助开发人员掌握更多的用户场景，及分析存在风险的地方；第二：对发现的bug进 行归类，分析，通过提供这些数据，帮助开发解决问题时能更充分与更完备，尽量减少重打开的bug数。

　　末了，送大家一句话，也是笔者常激励自己的一句话“测试之路，路漫漫其修远兮，吾将上下而求索”。

1.领悟能力
做任何一件事以前，一定要先弄清楚上司希望你怎么做，然后以此为目标来把握做事的方向，这一点很重要，千万不要一知半解就开始埋头苦干，到头来力没少出、活没少干，但结果是事倍功半，甚至前功尽弃。要清楚悟透一件事，胜过草率做十件事，并且会事半功倍。

2.计划能力
执行任何任务都要制定计划，把各项任务按照轻、重、缓、急列出计划表，一一分配部属来承担，自己看头看尾即可。把眼光放在部门未来的发展上，不断理清明天、后天、下周、下月，甚至明年的计划上。在计划的实施及检讨时，要预先掌握关键性问题，不能因琐碎的工作，而影响了应该做的重要工作。要清楚做好20%的重要工作，等于创造80%的业绩。

3.指挥能力
无论计划如何周到，如果不能有效地加以执行，仍然无法产生预期的效果，为了使部属有共同的方向可以执行制定的计划，适当的指挥是有必要的。
指挥部属，首先要考量工作分配，要检测部属与工作的对应关系，也要考虑指挥的方式，语气不好或是目标不明确，都是不好的指挥。而好的指挥可以激发部属的意愿，而且能够提升其责任感与使命感。要清楚指挥的最高艺术，是部属能够自我指挥。

4.控制能力
控制就是追踪考核，确保目标达到、计划落实。虽然谈到控制会令人产生不舒服的感觉，然而企业的经营有其十分现实的一面，有些事情不及时加以控制，就会给企业造成直接与间接的损失。但是，控制若是操之过急或是控制力度不足，同样会产生反作用：控制过严使部属口服心不服，控制不力则可能现场的工作纪律也难以维持。要清楚最理想的控制，就是让部属通过目标管理方式实现自我控制。

5.协调能力
任何工作，如能照上述所说的要求，制定完善的计划、再下达适当的命令、采取必要的控制，工作理应顺利完成，但事实上，主管的大部分时间都必须花在协调工作上。协调不仅包括内部上下级、部门与部门之间的共识协调，也包括与外部客户、关系单位、竞争对手之间的利益协调，任何一方协调不好都会影响执行计划的完成。要清楚最好的协调关系就是实现共赢。

6.授权能力
任何人的能力都是有限的，作为高级经理人不能象业务员那样事事亲历亲为，而要明确自己的职责就是培养下属共同成长，给自己机会，更要为下属的成长创造机会。孤家寡人是成就不了事业的。部属是自己的一面镜子，也是延伸自己智力和能力的载体，要赋予下属责、权、利，下属才会有做事的责任感和成就感，要清楚一个部门的人琢磨事，肯定胜过自己一个脑袋琢磨事，这样下属得到了激励，你自己又可以放开手脚做重要的事，何乐而不为。切记成就下属，就是成就自己。

7.判断能力
判断对于一个经理人来说非常重要，企业经营错综复杂，常常需要主管去了解事情的来龙去脉因果关系，从而找到问题的真正症结所在，并提出解决方案。这就要求洞察先机，未雨绸缪。要清楚这样才能化危机为转机，最后变成良机。

8.创新能力
创新是衡量一个人、一个企业是否有核心竞争能力的重要标志，要提高执行力，除了要具备以上这些能力外，更重要的还要时时、事事都有强烈的创新意识，这就需要不断地学习，而这种学习与大学里那种单纯以掌握知识为主的学习是很不一祥的，它要求大家把工作的过程本身当作一个系统的学习过程，不断地从工作中发现问题、研究问题、解决问题。解决问题的过程，也就是向创新迈进的过程。因此，我们做任何一件事都可以认真想一想，有没有创新的方法使执行的力度更大、速度更快、效果更好。要清楚创新无极限，唯有创新，才能生存。

领导力更需提升

一个部门经理提高完成任务执行力的过程，其实也就是提高自身对部门员工领导力的过程。因为要提高执行部门的执行力，不是光靠经理一人所能完成的，而是要靠带领部门所有员工的共同努力才能完成的。
说到底，对上提高执行力、对下就要提升领导力。
那么，怎样才能提升领导力呢？除了提高以上八项能力之外，还有最重要的两点：
1.学会用老板眼光看企业。
在老板看来，管理很简单，就是两件事：一是扩大业务范围，增加业务收人；另一件事就是降低管理成本，控制运作费用。其实这两件事，最终是一件事，收入减去成本，减去费用，就是利润。所以归根到底老板是看利润的，利润要从管理中来。
2.从被领导中学习领导。
在领导人看来，领导也很简单，就是两件事：一是用人，内圈用德、外圈用才，用人所长、容人所短；二是激励，解人之难、记人之功，通过正面激励，引导下属往前跑，通过负面激励，推着下属往前走。要知道，任何领导都是从做下属开始的，谁都不可能一步登天当领导。在每个人的成长过程中，你会经历大大小小许多领导，只要你用心学习，不管是好领导、还是坏领导，你都可以从正反两方面学到经验和教训，这对你将来当好领导是十分珍贵的。
除了以上各种能力外，测试技能不能丢，通过技术服众可以保证管理的有效执行。