不同类型的软件企业该如何有效的管理好你的软件测试团队？

最近在网上发现一篇记录了2012年《[视频]作为测试经理如何有效管理好你的软件测试团队》的文字内容，感谢记录的人，我也保存一下。顺便将演讲中的PPT重点截图也放上来，一并保存了！。由于是现场速记，过度的口语化，所以文字有很多错误和不通顺的地方，整理文字就耗费了好几个小时。文字可能还是有不通顺的地方，还请大家见谅！

微信公众号：领测软件测试老贺为测试经理蓄力

关注软件测试体系，软件测试流程的系统构建方法。以软件测试管理者的视角，为软件测试经理，软件测试总监提供可行的建议。

77篇原创内容

演讲主题“如何管理你的软件测试工作”主题活动以软件测试为切入点，分享如何在不同规模，不同诉求的企业情景下，最大限度的利用现有资源，通过测试维护软件质量。

以下是领测老贺的演讲实录：

今天我们谈点什么呢?在座的人数不少，相信都希望从软件测试得到些许机会。我先猜猜你们针对软件测试会有哪些问题?我猜的不准可以直接向我反馈，我希望有一些互动。

可能有人会说：

我的质量确实有一些问题，如果使用自动化软件测试就能解决所有问题了。长远来看，自动化软件测试一定会帮你解决些许的问题。但是，ROI(投资回报率)非常滞后。

可能还有朋友有以下问题：

我觉得某某公司的方法不错，我估计我们也行。在座的来之前我相信你们看了很多测试方法和理论，或者针对自己的现状觉得，他的方法行或者不行。你们需要不需要站在你们公司角度，引入一个方法论帮助你们解决现在的问题?我今天就是想找到一种方法彻底改变我的现状。

但是很遗憾，放之四海而皆准的方法是没有的，如果你抱着这样的希望来，对不起，这一个小时也办不到。

也许你说的很对，可能我们现在想法不太现实。但是，我想来想去觉得所有的原因都是由于我们缺少一个人，同意吗?在座的你们可能管质量、管技术，但是对测试这块不放心。你们很可能只是缺少一个很牛的人存在。

如果大家都缺少一个很牛的人，这个牛人在哪儿呢?你可能知道这个牛人在哪儿?微博、猎头，或者你敞开所有的渠道去找，你认为某某某就是一个牛人，如果他能加入到了我们的团队，我们就成为了这样的一个组合。放之四海我们的核心团队就可以组成了，我们就可以上市了，我们就前途远大了，因为质量问题可以完全交给他。

我想说的是，大家既然来到了这个场所，那你开发的产品应该是没有太大问题的，至少能用。否则用不了两个月，你们就各自找工作去了。

我的结论是开发和测试工程师的技能是配套。

举一个软件测试工程师的例子，质量非常好的产品见过吗?质量非常差的产品见过吗?当一个测试工程师进入到你的团队，开始对你的产品进行测试的时候，随手点就会出现bug，不用用任何的技巧和方法就找了一堆Bug出来，像这样的开发团队，你请一个软件测试牛人来有用吗?他能待得住吗?即使你虽然花了30万的年薪把他雇来，但是你只能得到5万年薪的工程师的效果。所以，不如花5万块钱请一个测试工程师给你干活就行了，因为开发和测试是配套的。如果一个产品质量很好，你请个3、5千的测试工程师来，他发现不了Bug，由于软件质量很好，怎么都测不出bug，但他的同事已经发现bug了，他也没法继续待下去。所以开发的质量决定测试的质量。

你作为开发工程师千万不要抱怨跟你合作的测试工程师水平低，因为你抱怨他的同时就是在抱怨你的开发质量很差，因为你跟他是配套的。你作为测试工程师也不要抱怨这个产品质量很不好，你跟他也是配套的。

你门的目标是什么?共同提高、共同成长!当你到了一定水平，你请相同水平的人来组成团队才有用。

如果大家没有以上不切实际的想法了，我们可以开始了。

《孙子兵法》的开篇，你如何管理你的测试工作呢?很遗憾，我的高度非常有限，所以我们只能谈最末流的“法”。但是如果你前四个没搞定，法一点用都没有。但我们看事情的时候，只能谈“法”中间的一点。

当我们想谈软件测试的时候，第一件事情你需要先认清你是谁。

我给大家规划出来三个场景：

第一个场景我叫它“小型创业团队”，两三个或者三五个人的开发团队;

第二个几十号人的中型团队;

第三个是资源相对丰富的大型团队。

三个团队的目标和方法是完全不一样的，千万别相互照抄。小型团队用大型、中型团队的方法做事儿，会死的很难看。大型团队照小型团队的方法和思路做，很多事情会变得不可控。所以先需要先认清自己是谁，再按部就班地做事。

首先，小型团队

当我们谈到小型团队的时候，我问大家第一个问题就是：你的团队为什么还没有死?

小型团队容易死吗?中关村统计，创业团队里99%会死掉。剩下来的1%是偶然吗?绝对不是偶然!你为什么能生存下来?如果你没有办法很好的回答这个问题，代表你可能马上就会进入到那99%里。

我给你几个理由，你看是不是?

第一个理由：人无我有。

你们是不是现在在做一件事情，这件事情是别人都没做，只有我做了?前面五条——道、天、地、法、将才能解释你为什么会活下来。如果你现在活下来的理由是人无我有，你有什么?如何保持?如何发扬光大?如何做差异化的竞争?这是你后面的开发、测试工作的所有要点。不要跟别人争你没有的东西，没有任何意义，而且会加速你的死亡，这是第一个你活下来的理由是因为人无我有。

第二个：人有我精。

你在市场不是唯一的，但是你做的比较好。如果你的理由是“人有我精”的话，你活下来的理由是什么?是这个“精”字!你的开发质量、团队管理的重点都要集中在这点。你跟它的质量一样吗?能照方抓药吗?认清你自己。如果人家比你“精”，你怎么办?

第三个：人精我贱

什么叫贱?便宜、免费、倒找钱。倒找钱可能比较难，免费可能是你活下来的理由。但是，你想把免费往下继续推的话，怎么办?是因为人家收费我免费就一定有市场吗?前提是什么?免费的质量和收费的质量相当，这个才是你能存活下来的理由。当人精我贱的时候，贱和精要相当，而且你要加上免费才能活下来。

老实说，后面两种情况不适合小团队创业。

首先要认识自己在哪个范畴?在这样的前提下，你再来考虑你的测试怎么做?

小团队应该怎么做软件测试？

小团队的要求是什么呢?一定是少花钱，多办事。一分钱要分成两半花，不能大手大脚。

如果你是小型创业团队，你要关注什么?一定要关注主要业务功能!时刻记住什么是你赖以生存的原因，一定把这个原因抓住，也就是从测试重点说，必须关注主要业务功能，也就是你的杀手锏、核心竞争力、客户为什么选择你的原因。抓大放小，把卖点做足，这是所有质量保证的核心原因。

3、5个人的团队最好采用自测、互测的方式，我不建议你雇一个优秀的全职工程师，因为在这个阶段是不值得的，保证业务功能最重要。

作为老板要抓你的客户。做足用户测试，用户测试是免费的，可以让用户跟着你一块儿玩。如果你想把你的公司做大、做强，就要抓一下质量，好好做功能点测试和自动化测试。记住，这是在满足前两项的情况下做的。

小型团队要完全遵循要事第一，也就是刚才一直在强调的，主要业务功能。你的卖点是什么?用户为什么会买单?你要把精力投在最优价值上。

可能在这个阶段对你来说，一个完备的测试并不是最有价值的。人无我有的情况下你的质量不能太差。当人有我精的时候，你是什么状态?人精我贱的时候你是什么状态?你现在做的事情是最有价值的吗?现有的流程框架基础设施中，哪些部分不是必须的、能用更轻量级的方法替代?这都是你做的时候时刻要考虑的事情。

我们看看中型团队

如果有了几十号人，有了全职的测试工程师，你应该怎么办?

第一个问题，明确你团队的KPI

什么代表着你做好了?找出跟质量相关的要素。一样的道理，先分清你的目标。创业团队的目标很明确，就是为什么存在?大一点的团队很明确，就是分给你的KPI是什么?

第二，这时你应该配独立的软件测试工程师了。

当你所有的东西比较规范的时候，我建议你按功能将这些角色进行划分，可能分为软件测试环境搭建、自动测试组、手工测试组、性能测试组和安全评估等。对于不同的产品不需要全配，但是我建议你按角色进行划分，不要让所有的测试工程师干一样的事情。

第三，你需要梳理一下你的软件测试流程，控制工作方式。

在这样的情况下我建议你规划整个的测试过程、测试方式。我会把整个的测试过程分为：单元、集成、系统，三个阶段。

一要有专项的测试方案，比如功能、性能、安全、安装。

二要做测试过程的记录，缺陷报告也要独立管理，要使用专门的缺陷管理工具进行管理，要对测试工程师进行训练。

三要有测试综合报告作为测试的最终交付物，这些是你在中型的团队要做的事情，把流程建立起来，大家按部就班、分角色进行。

然后，针对中型团队，我的建议，你要花足够的时间研究你的被测应用，研究你产品的特点。

当你仔细研究你的被测应用的时候，你会出现很多自动化的解决方案，这会直线的提升你的效率和优化你的测试工作量。在这个情况下，立足点是不要期望于所谓的像我这样的人告诉你一个完美的自动化测试框架，这不现实，因为我不了解你的业务，不了解你的产品特点，这件事儿只有你自己能做。

中型团队也可以敏捷一下

但是，开始之前你必须要问自己几个问题，这几个问题直接导致你行还是不行。

你的项目能接受失败吗?你的团队有希望实现自组织的跨功能团队吗?人员组成是什么样的?你招到的人是什么样的?他们的学习能力是什么样的?你们是一个精英团队，还是一个能干的人带着若干个不能干的人在一起干活?这些直接导致你能用敏捷还是不能用敏捷。

在这样的情况下我建议你规划整个的测试过程、测试方式。

我会把整个的测试过程分为单元、集成、系统，三个阶段。

一定要有专项的测试方案，比如功能、性能、安全、安装等。

二要做测试过程的记录，缺陷报告也写出来，用专门的缺陷管理工具进行管理，要对测试工程师进行训练。

最后要有测试综合报告，这些是你在中型的团队要做的事情，把流程建立起来，大家按部就班、分角色进行。

如果你想管理起一个好的测试团队，首要的事情是什么?先认识清楚你自己是谁!就是你的开发和测试是配套的，如果你根本没有清楚的认识到你是谁的话，所有方法、体系、人员管理全都是失效的。

你是猫还是狮子，自己照可能看不清楚，还需要第三方评价。

现在我们看看你到底如何认识你自己?

这个人是孙子。前两天我在地铁上没事儿，看了一段《孙子兵法》，借这个机会我们来一起读读。和我们的工作链接一下

第一篇：原文孙子曰：“兵者，国之大事，存亡之道，不可不察也”。

你们如何看待你们的产品?如何看待你的团队?如何管理这些人?

一曰道

《孙子兵法》中对道的解释是这样：道者可令民与上同意，故可以与之死，而不畏危也。

放到你的企业就是：愿景、目标，是后面讨论的所有的前提，你们公司的理想是什么?怎么激励大家干活?在现有比较危急，或者挣不到钱的情况下，如何激励大家一起往前走? 你作为一个部门的领导，你如何激发大家的士气？也就你的视野，你的愿景。如果你关注的都是一个一个具体的细节，你的团队慢慢的会离心离德，为什么?大家看不到目标。先考虑清楚你的道是什么?。

二曰天

天者，阴阳、寒暑、时制也。

天对于企业来说就是你的生存环境。什么行业发展快速?未来的场景是什么样的? 如果你的天：星空万里，毫无污染，那么恭喜! 但实际情况也有可能是一片狼藉。你清楚你的行业发展吗?你清楚市场的变化吗?记住，当你确定了理想和愿景的时候一定要看周遭的环境。

三曰地

地者，远近、险易、死生也。

这些是非常重要的，你思考要长远，你是谁?你能战胜你的竞争对手吗?你该攻击它哪儿?

四曰将

将者：智、信、仁、勇、严也。

当你有了这几个特点的时候，你就成为了一个能领军的大将。在你的公司里有没有这样的大将? 有和没有都是问题。如果有幸你的公司里有这样的上将，事业何愁不能兴旺! 你的周围有没有这样的大将，你作为一个主管，有没有辅助你的人，所有事都需要自己做。这种情况，你如何处理?

法

法者曲制、官道、主用也

也就是规矩。当前四点看清楚了，才谈到你应该如何做。做事儿的先后顺序是什么?

道、天、地、将、法

当我们讨论后面所有工作的时候，先要结合这五各方面来谈。

如果你想实施敏捷，你能依靠谁?

听说过这个故事吗? 鸡和猪的故事！

敏捷里一直在讲。有一天鸡和猪说，咱们一块儿创业去吧，猪说，好啊。那我们做什么生意呢?鸡想了想，我们做火腿鸡蛋三明治吧。猪想了想，不对啊。你只用献出不重要的一部分，而我却要搭上自己的性命跟你玩!

敏捷里有一个观点：记住，你可以听听鸡的建议，但是一定要跟猪合作。

如果这些你都搞定了，你明白了谁对你重要，你可以开始尝试一下敏捷了。

现在最流行的是Scrum（自组织团队），测试过程中，先让你的PO(Product Owner)把需要做的，也就是产品需求全部罗列出来，通过估算计划确定你每个迭代周期的工作量，这些都确定了，通过站立例会跟踪相关计划，4-6周为一个迭代周期，每一个迭代周期都要发布可见的产品。

但是，敏捷到现在还是争争吵吵，为什么?对人的要求，对目标的要求，对客户的要求，你的自组织团队对你的要求等等都比较高。

为什么西方做得好? 在西方参与敏捷项的人都是30岁，35岁以上的人，这些人可以对自己负责。所以，由于我能对自己负责，所以我能对项目负责，我知道什么该干，什么不该干，我知道承诺以后的后果，我非常关注我个人的荣誉。会谨慎承诺。按照承诺完成任务。

比如说我，如果很担心这次演讲发挥不好，讲不好，我就会好好准备PPT，类似这样的。国内呢? 可能22岁，23岁，25岁，大学刚毕业不久的人。领导一鼓励他，说：你行的。就会上头，什么都敢承诺！当承诺和结果不匹配的时候，长时间不匹配的时候，你的敏捷就有可能失败了。

所以，自组织非常重要。你适合不适合自己要做判断?如果你适合，可以开始敏捷了。

刚才给大家介绍的就是中型团队。

最后，如果你是一个资源相对充足的大型团队

恭喜你，你可以做很多的事情。

第一：要明确你企业的文化、目标。

企业文化很重要：

迪斯尼给人们提供最好的娱乐方式，我们想要一个有意义的环境，一个使家庭团聚的地方。

通用，永远推崇三个传统，即坚持诚信、注重业绩、渴望变革。

摩根大通银行的企业文化是危机之中自有良机，你应该能感觉到这个公司不会排斥风险。

微软的薪资标准也排在全美前10，因为微软坚持只要最顶级的人。

谷歌非常重要的一个信条就是网络也讲民主，所以它退出了中国。

你的企业文化是什么? 首先你要分析你的企业文化，让它和你的质量相关并且匹配。团队的做事理念是第一个要明确的地方，只有当你有了目标才可以做后面的事情。

你的产品是业务型的还是互联网型的，跟质量关联相差非常大。

比如谷歌这种互联网公司它的特点是什么? 从质量角度来说，升级更新是无成本的。我可以依赖大量的用户测试，也可以进行快速迭代、快速反馈，我可以进行少量的AB测试达到全覆盖。比如说谷歌有一个功能想上线，但是我没有经过大量的覆盖我怎么做? 可以做一个开关，只允许万分之一，或者百分之一，千万分之一的人使用，只开10分钟做测试。这是互联网产品的特点。

但微软产品型产品的特点是什么? 对发布质量非常看重。因为软件到用户手里后维护升级成本很高，所以它对初次发布质量很关注。

所以你首先要明确你的产品、你的公司是什么特点? 这是两种方法，两种理念，搞错了就全完了。

大型团队必须关注测试体系建设

针对大公司，你要关注一点，是否有标准的软件测试培训体系支撑？人太多了，如果使用的方法不一样，没有经过一个统一的训练，做出来的东西一定是千差万别的。

在这一块，我会给大家介绍一个ISTOB，全称是国际软件测试资质认证委员会，这个是它的认证体系，分为三个级别：基础级、高级、专家级。

ISTQB等级图

大量的测试技能在基础级都讲了。基础级如果认真学完，应该可以胜任测试工程师了！

它的优势是什么? 它的优势在标准，全球一。例如我给北京研发中心做一场培训，给杭州研发中心做一场培训，给上海中心做一场培训，如果你的讲师不一样，可能使用的方法和体系是完全不同的。我用我的理念讲，他用他的理念讲，但是如果存在一个标准的话，这个问题就不存在了。

ISTQB的高级分为三个模块，专家级分为四个模块。还有统一的、专业的术语表。

如果你是一个大型团队，我建议你可以推进持续集成。

Martin Fowler认为持续集成是软件开发的一个最佳实践，每天至少集成一次，这也就意味着每天可能发生多次集成，每次集成都是自动化的，当你每Build一次，就自动进行了代码检查，还会运行一系列的单元测试用例，然后集成到整个系统中，整个系统进行编译，编译完了做自动部署，部署完了以后做整个的自动化回归，这些工作可能在代码提交的时候进行，也可能在晚上集中进行。

总之，每天都在做测试、做集成。再往前推一步是什么?持续交付，交付是什么意思?所有真实的产品已经上传到生产服务器，只是客户看不到，有一个开关，这个开关一开，大家就能用了，开关关了，大家就用不到。

换句话说，你每次生产的东西，编译好的代码，都会实时的上传到生产服务器，面对客户只是他们看不到，这就是持续交付。

具体交还是不交，是运维人员说了算，跟你开发没有关系，我愿意交就交了，点几个勾，点击确定，产品就上线了，你要保证你的产品都是可以使用的。

如果你是大型的团队，你可能有一个选择，就是CMMI，或者敏捷。

现在大多数人都选敏捷了，CMMI我们这里就不讲了。

最后，我送大家一句话《孙子兵法》中的一句话，叫：“将能而君不御者胜”。

那将不能怎么办? 将不能，君要御才能胜?

君也不能呢? 如果你的团队里没有那么多的能人，没有那么多自觉的人，达不到自组织，停留到这儿应该是一个安全地带，过了可能就是一个高风险区域。

大型团队，质量是有成本的，我建议大家是做一个实用主义者，谋定而后动。

目标决定过程，过程决定质量。