日前，由CSDN旗下高级技术管理者大本营CTO俱乐部举办的“如何管理你的软件测试工作”线下主题活动在SOHO西区某咖啡厅举行。本次活动邀请到了CTO俱乐部软件测评技术专委会会长、资深软件测试专家贺炘。贺炘以软件测试为切入点，分享如何在不同规模，不同诉求的企业情景下，最大限度的利用现有资源，通过测试维护软件质量。
据悉，这是CTO俱乐部软件测评技术专业委员会成立以来的第二场线下活动，来自于拉手网首席科学家、中移动通信研究院、卓望集团、世纪佳缘、央视国际网络等公司技术负责人现场参加了本次活动。
软件测评技术专委会会长贺炘
以下是贺炘的演讲实录：
今天我们谈点什么呢？在座的人数不少，相信都希望从软件测试得到些许机会。我先猜猜你们针对软件测试会有哪些问题？我猜的不准可以直接向我反馈，我希望有一些互动。我的质量确实有一些问题，如果有一个软件测试就好了。长远来看，自动化软件测试一定会帮你解决些许的问题。但是，ROI（投资回报率）非常滞后。如果你现在就人手不足，现在就大力投入自动化测试，带给你的是什么？如果你抱着这样的想法，我现在告诉你们，可能不现实。
我觉得某某方法不错，我估计我也行。在座的来之前我相信你们看了很多测试方法理论，或者针对自己的现状觉得他行或者不行，你们需要不需要从你们的公司角度来说引入一个方法论帮助你们解决现在的问题？我今天就是想找到一种方法彻底改变我的现状。很遗憾，放之四海而皆准的方法是没有的，如果你抱着这样的希望来，对不起，这一个小时也办不到。也许你说的很对，可能我们现在想法不太现实。但是，我想来想去觉得所有的原因都是由于我们缺少一个人，同意吗？在座的你们可能管质量、管技术，但是对测试这块不放心。你们很可能只是缺少一个很牛的人存在。如果大家都缺少一个很牛的人，这个牛人在哪儿呢？你可能知道这个牛人在哪儿？微博、猎头，或者你敞开所有的渠道去找，你认为某某某某就是一个牛人，如果加入到了我们的团队，我们就成为了这样的一个组合。放之四海我们的核心团队就可以组成了，我们就可以上市了，我们就前途远大了，因为质量问题可以完全交给他。
我想说的是，大家既然来到了这个场所，那你开发的产品应该是没有太大问题的，至少能用。否则用不了两个月，你们就各自找工作去了。我的结论是开发和测试工程师的技能是配套。举一个软件测试工程师的例子，质量非常好的产品见过吗？质量非常差的产品见过吗？当一个测试工程师进入到你的团队，开始对你的产品进行测试的时候，随手点就会出现bug，不用用任何的技巧和方法就找了一串出来，像这样的开发团队，你请一个牛人来有用吗？他能待得住吗？他来了有用吗？即使你虽然花了30万的年薪把他雇来，但是你只能得到5万年薪的工作。所以，不如花5万块钱请一个工程师给你干活就行了，因为开发和测试是配套的。一个产品质量都很好，你请个2、3千的测试工程师来，他发现不了Bug，质量很好，怎么都测不出bug，但他的同事已经发现bug了，他也没法继续待下去。开发的质量决定测试的质量。
所以，你作为开发人员千万不要抱怨你的测试工程师水平很低，因为你抱怨他的同时就是在抱怨你的开发质量很差，因为你跟他是配套的。你作为测试工程师也不要抱怨这个产品质量很不好，你跟他也是配套的。你的目标是什么？共同提高、共同成长！当你到了一定水平，你请相同水平的人来才有用。如果你们没有以上不切实际的想法了，我们可以开始了。
如果你想管理起一个好的测试团队，首要的事情是什么？先认识清楚你自己是谁！就是你的开发和测试是配套的，如果你根本没有清楚的认识到你是谁的话，所有方法、体系、人员管理全都是失效的，你是猫还是狮子，自己照不行，周围照。现在我们看看你到底如何认识你自己？这个人是孙子。前两天我在地铁上没事儿，看了一段《孙子兵法》，突然觉得这一段做这样的一个沟通非常好的一件事情。第一篇原文孙子曰：“兵者，国之大事，存亡之道，不可不察也”。你们如何看待你们的产品？如何看待你的团队？如何管理这些人？道，《孙子兵法》中对道的解释是这样，道者可令民与上同意，故可以与之死，而不畏危也。放到你的企业就是愿景、目标，是后面讨论的所有的前提，你们公司的理想是什么？怎么激励大家干活？在现有比较危急，或者挣不到钱的情况下，如何激励大家走？你作为一个部门的领导，你如何鼓动大家的士气，你要想想到，也就你的视野，你的愿景。如果你关注的都是一个一个具体的细节，你的团队慢慢的会离心离德，为什么？大家看不到目标。先考虑清楚你的道是什么？一曰道。
二曰天。天者，阴阳、寒暑、时制也。天对于企业来说就是你的生存环境。什么行业发展快速？未来的场景是什么样的？如果你的天星空万里，毫无污染，那么恭喜！实际情况也有可能是一片狼藉。你清楚你的行业发展吗？你清楚市场的变化吗？记住，当你确定了理想和愿景的时候一定要看环境。
三曰地。兵法指地者，远近、险易、死生也。这些是非常重要的，你要思考地长远，你是谁？你能应该你的竞争对手吗？你该攻击它哪儿？
四曰将。将者智、信、仁、勇、严也。当你有了这几个特点的时候，你就成为了一个能领军的大将。在你的公司里有没有这样的大将？有和没有都是问题。如果有幸你的公司里有这样的上将，何愁不能兴旺！你的周围有没有这样的大将，你作为一个主管，有没有辅助你的人，所有事都需要自己做。这种情况，你如何处理？
当你看到这四点的时候，实际上陆陆续续看清一条。然后你才知道什么呢？法。法者曲制、官道、主用也，也就是规矩。当前四点看清楚了，才谈到你应该如何做。做事儿的先后顺序是什么？道、天、地、将、法。当我们讨论后面所有工作的时候，先要结合这五各方面来谈。
说了《孙子兵法》的开篇，你如何管理你的测试工作呢？很遗憾，我的高度非常有限，所以我们只能谈最末流的“法”。但是如果你前四个没搞定，法一点用都没有。但我们看事情的时候，只能谈法中间的一点，软件测试。当我们想谈软件测试的时候，第一件事情你需要先认清你是谁。我给大家规划出来三个场景：第一个场景我叫它“小型创业团队”，两三个或者三五个人的开发团队；第二个几十号人的中型团队；第三个是资源相对丰富的大型团队。三个团队的目标和方法是完全不一样的，千万别相互照抄。小型团队用大型、中型团队的方法做事儿死的会很难看。大型团队照小型团队的方法和思路做候，很多事情会变得不可控。先需要先认清自己是谁，再按部就班地做事。
首先，小型团队，当我们谈到小型团队的时候，我问大家第一个问题就是你的团队为什么还没有死？小型团队容易死吗？中关村统计，创业团队里99%会死掉。剩下来的1%是偶然吗？绝对不是偶然！你为什么能生存下来？如果你没有办法很好的回答这个问题，代表你马上可能就进入到那99%里。我给你几个理由，你看是不是？
第一个理由：人无我有。你们是不是现在在做一件事情，这件事情是别人都没做，只有我做了？前面五条——道、天、地、法、将才能解释你为什么会活下来。如果你现在活下来的理由是人无我有，你有什么？如何保持？如何发扬光大？如何做差异化的竞争？这是你后面的开发、测试工作的所有要点。不要跟别人争你没有的东西，没有任何意义，而且会加速你的死亡，这是第一个你活下来的理由是因为人无我有。
第二个：人有我精。你在市场不是唯一的，但是你做的比较好。如果你的理由是人有我精的话，你活下来的理由是什么？是这个“精”字！你的开发质量、团队管理的重点都要集中在这点。你跟它的质量一样吗？能照方抓药吗？认清你自己。人精，你怎么办？人精我贱！什么叫贱？便宜、免费、倒找钱。倒找钱可能比较难，免费可能是你活下来的理由。但是，你想想把免费往下继续推的话，怎么办？是因为人家收费我免费就一定有市场吗？前提是什么？免费的质量和收费的质量相当，这个才是你能存活下来的理由。当人精我贱的时候，贱和精要相当，而且你要加上免费才能活下来。老实说，后面两种情况不适合小团队创业。首先要认识自己在哪个范畴？在这样的前提下，你再来考虑你的测试怎么做？
小团队的要求是什么呢？一定是少花钱，多办事。一分钱要分成两半花，不能大手大脚。如果你是小型创业团队，你一定要关注什么？关注主要业务功能！时刻记住什么是你赖以生存的原因，把这个原因一定要抓住，也就是在测试角度上来说，我们会说关注主要业务功能，也就是你的杀手锏、核心竞争力、客户为什么选择你的原因。抓大放小，把卖点做足，这是所有质量保证的核心原因。3、5个人的团队最好采用自测互测的方式，我不建议你雇一个优秀的全职工程师，因为在这个阶段是不值得的，保证业务功能最重要。作为老板要抓你的客户。对内用户测试，用户测试是免费的，可以让用户跟着你一块儿玩。如果你想把你的公司做大、做强，抓一下质量，好好做但点测试和自动化测试。记住，这是在满足前两项的情况下做的。
小型团队要完全遵循要事第一，也就是刚才一直在强调的，主要业务功能。你的卖点是什么？用户为什么会买单？你要把精力投在最优价值上。可能在这个阶段对你来说，一个完备的测试并不是最有价值的。人无我有的情况下你的质量不能太差。当人有我精的时候，你是什么状态？人精我贱的时候你是什么状态？你现在做的事情是最有价值的吗？现有的流程框架基础设施中，哪些部分不是必须的、能用更轻量级的方法替代？这都是你做的时候时刻要考虑的事情。
然后，我们看看中型团队，如果有了几十号人，有了全职的测试工程师，你应该怎么办？第一个问题，明确你团队的KPI，什么代表着你做好了？找出跟质量相关的要素。一样的道理，先分清你的目标。创业团队的目标很明确，就是为什么存在？大一点的团队很明确，就是分给你的KPI是什么？第二，这时你应该配独立的软件测试工程师了。当你所有东西比较规范的时候，我建议你按功能将这些角色进行划分，可能分为软件测试搭建、自动测试组、手工测试组、性能测试组和安全评估等。对于不同的产品不需要全配，但是我建议你按角色进行划分，不要让所有的测试工程师干一样的事情。这时你需要梳理一下你的软件测试流程，控制工作方式。
在这样的情况下我建议你规划整个的测试过程、测试方式。我会把整个的测试过程分为单元测试系统，分为三个阶段，一要有专项的测试方案，比如手工、技能、安全、安装。二要做测试过程的记录，缺陷报告也写出来，用专门的缺陷管理工具进行管理，要对测试工程师进行训练。最后要有测试综合报告，这些是你在中型的团队要做的事情，把流程建立起来，大家按部就班、分角色进行。
然后，针对中型团队，我的建议，你要花足够的时间研究你的备测应用，也就是你产品的特点。
当你仔细研究你的备测应用的时候，你会出现很多自动化的解决方案会直线的提升你的效率和测试的工作量。在这个情况下，立足点是不要期望于所谓的像我这样的人告诉你一个自动化测试框架，不现实，因为我不了解你的业务，不了解你的特点，这件事儿只有你自己能做。
中型团队也可以敏捷一下，但是，开始之前你必须要问自己几个问题，这几个问题直接导致你行还是不行。第一个问题，你的项目能接受失败吗？你的团队有希望实现自组织的跨功能团队吗？人员组成是什么样的？你招到的人是什么样的？他们的学习能力是什么样的？你们是一个精英团队，还是一个能干的人带着若干个不能干的人在一起干活？这些直接导致你能用敏捷还是不能用敏捷。
如果你想实施敏捷，你能依靠谁？听说过这个故事吗？鸡和猪的故事，敏捷里一直在讲。有一天鸡和猪说，咱们一块儿创业去吧，猪说，好啊。那我们做什么生意呢？鸡想了想，我们做火腿鸡蛋三明治吧。猪想了想，不对啊。你只用献出不重要的一部分，而我却要打上自己的性命！敏捷里有一个观点，记住可以听听鸡的建议，但是一定要跟猪合作。如果这些你都搞定了，你明白了谁对你重要，你可以开始尝试一下敏捷了。
现在最流行的是Scrum，测试过程中，先让你的PO把需要做的，也就是产品需求全部罗列出来，通过估算计划确定你每个迭代周期的量，这些都确定了，通过战略例会跟踪你的相关计划，4-6周为一个迭代周期，每一个迭代周期都要发布可见的产品。但是，敏捷到现在还是争争吵吵，为什么？对人的要求，对目标的要求，对客户的要求，你的自组织团队对你的要求等等一系列。为什么西方做得好？在西方参与敏捷项的人都是30岁，35岁以上的人，这些人可以对自己负责。所以，由于我能对自己负责，所以我能对项目负责，我知道什么该干，什么不该干，我知道承诺以后的后果，我非常关注我个人的荣誉。比如说我很担心我这次发挥不好，讲不好，所以会好好准备PPT，类似这样的。国内呢？可能22岁，23岁，25岁，大学刚毕业不久的人。领导一鼓励他，你行的，我行，为什么完不成？一系列就开始运作起来了。当承诺和结果不匹配的时候，始终不匹配的时候，你的敏捷就有可能失败。所以，自组织非常重要。你适合不适合自己判断？如果你适合，可以开始敏捷了，解决其他的问题。刚才给大家介绍的就是中型团队。
最后，如果你是一个资源相对充足的大型团队，恭喜你，你可以做很多的事情。你第一个要明确你企业的文化、目标。迪斯尼给人们提供最好的娱乐方式，我们想要一个有意义的环境，一个使家庭团聚的地方。通用，永远推崇三个传统，即坚持诚信、注重业绩、渴望变革。摩根大通银行的企业文化是危机之中自有良机，你应该能感觉到这个公司不会排斥风险。微软的薪资标准也排在全美前10，因为微软坚持只要最顶级的人。谷歌非常重要的一个信条就是网络也讲民主，所以它退出了中国。你的企业文化是什么？首先你要分析你的企业文化，让它和你的质量相关。团队的做事理念是第一个要明确的，只有当你有了目标才可以做后面的事情。
你的产品是业务型的还是互联网型的，跟质量关联相差非常大。比如谷歌这种互联网公司它的特点是什么？从质量角度来说，升级更新是无成本的。我可以依赖大量的用户测试，也可以进行快速迭代、快速反馈，我可以进行少量的AB测试达到全覆盖。比如说谷歌有一个功能想上线，但是我没有经过大量的覆盖我怎么做？可以做一个开关，只允许万分之一，或者百分之一，或者千万分之一的人使用，开10分钟做测试。这是互联网产品的特点。微软产品型产品的特点是什么？对发布质量非常关注。因为软件到用户手里后维护升级成本很高，所以它对初次发布质量很关注。所以你首先要明确你的产品、你的公司是什么特点？两种方法，两种理念，搞错了就全完了。
大型团队还要思考一件事情。针对大公司，你要关注一点，是否有标准的软件测试培训体系支撑，人太多了，方法不一样，如果没有经过一个统一的训练，做出来的东西是千差万别的。在这一块，我会给大家介绍一个ISTOB，全程是国际软件测试资质委员会，这个是它的资质体系，分为三个级别：基础级、高级、专家级。大量的测试技能在基础级都讲了。基础级如果认真学完，你可以做不同的测试工程师，它的优势在什么？它的优势在标准，全球一致，这样我给北京中心做一场培训，给航空中心做一场培训，给上海中心做一场培训，如果你的讲师不一样，讲的都不一样。我用我的理念讲，他用他的理念讲，但是如果存在一个标准的话，这个就不存在了。高级分为三个模块，专家级分为四个模块。为了维护这个，它有专业的术语表，就是每个名词怎么解释，这个是ISQB。
当你是一个大型团队，我建议你可以推进持续集成。Martin Fowler认为持续集成是软件开发实践，每天至少集成一次，也就意味着每天可能发生多次集成，每次集成都是自动化的，当你Buld一次，就自动进行了安全检查等，这些都检查完了，运行一系列的单元测试率，然后集成到整个系统，整个系统编译，编译完了做部署，部署完了以后整个的自动化回归，这些可能在当时进行，也可能在晚上进行。总之，每天都在做测试、做集成。再往前推一步是什么？持续交付，交付是什么意思？我所有真实的产品已经上传到服务器，只是客户看不到，我只有一个开关，这个开关一开，大家就能用了，我开关关了，大家就用不到，换句话说，你每次生产的东西，编译好的代码，实时的上传到生产服务器，面对客户只是他们看不到，持续交付。具体交还是不交，是运维人员说了算，跟你开发没有关系，我愿意交就交了，点几个勾，确定，产品就上架，你要保证你的产品都是可以使用的。
如果你是大型的团队，你可能有一个选择，就是CMMI，或者敏捷。比如大多数人都选敏捷了，CMMI不讲了。我不给大家讲CMMI和敏捷，我送大家一句话《孙子兵法》中有一句话，叫：“将能而君不御者胜”。那将不能怎么办？将不能，君要御才能胜？君也不能呢？如果你的团队里没有那么多的能人，没有那么多自觉的人，达不到自组织，停留到这儿应该是一个安全地带，这儿可能就是一个高风险区域。大型团队，质量是有成本的，我建议大家是做一个实用主义者，谋定而后盾，目标决定过程，过程决定质量。
我的发言就到这儿。