测试团队建设方案

1 / 21 测试团队建设方案 研发测试团队建设管理 团队建设是个很大的话题，也是组织管理工作中的重点和难点。本人曾在某大型 IT 公司从事过测试团队 管理多年，就管理实践中的一些心得和体会与大家分享。 相对于开发工作来说，测试一直被认为技术含量低且枯燥无味，从事测试工作的人员对测试工作也普遍 没有职业认同感，在我所在的测试团队中就经常可以听到“测试工作没前途”、“测试就是打杂的”、“真 后悔当初没有找个开发工作”等等抱怨，整个团队受这种气氛的影响也是一直 士气低下直接导致项目的测试 工作进展受阻、测试质量下降、客户投诉上升。相信这种状况也在其他公司的测试团队出现过，仔细观察和 思考，其实不难发现测试团队普遍存在以下的几个问题： 第一，测试人员职业认同感低。硬件开发工作可以把设计出来的电路板做为输出成果，软件开发可以把 具体程序的实现作为输出，而测试只有结果报告和BUG 数量，测试工作的成果不好体现。并且，国内很多公 司往往不重视测试，每当项目结束论功行赏时，测试团队总是被忽视。另外，测试工作既辛苦又无 聊，往往 2 / 21 没什么人愿意做测试，而暂时做着测试工作的人员也是隔山望水，盼着早日脱离测试苦海。 第二，测试人员对测试技术的认识存在误区。测试团队一般会安排刚进入公司的新人进行测试工作以了 解产品。这就给大家带来了一个错觉：测试都是没啥技术含量的活，是人都会干的事。设想一下，一个人每 天干着自认为没意义的事，他会有提高、会有进步的动力吗 ? 第三，测试团队成员不知道如何学习，找不到正确的学习方法。测试人员一般都比较敏感，具有很强的 发现缺陷的能 力，他们能找出应用系统缺陷的能力，也能找出自身在工作中的不足。这些不足包括基础知识 的不全面，也有测试技术的欠缺。面对这么多需要学习的方面，感到困惑，不知道先从哪里入手，也分不清 学习的重点和难点。遇到问题，可能就直接找其他人员求助，失去了锻炼自己思考学习能力的机会。 从以上几个问题，我们可以看到测试团队管理的核心其实是人，只要抓住了这个关键点，就能很顺利的 将整个团队调动起来。抛开团队建设中同样重要的制度和流程建设不提，下面将结合本人多年的实践做法谈 谈如何建设一支高效的测试团队。 首先，要确立测试团队成员在这个组织中的职业规3 / 21 划图，也是就是个人 Roadmap。基于这个 Roadmap 再 确立各个角色的职责以及各角色之间的相互联系和发展顺序。这样各测试团队成员的发展目标也随之确立。 下图的 Roadmap 就是我所在测试团队实际使用的团队成员 Roadmap 方案。 我们把整个测试团队分为五个等级，每个等级都对应测试团队中的相关角色，每个等级都有详细定义的 能力要求。整个团队职位的发展顺序同时随着能力的要求逐步理清。通过这个图，基本可以避免优秀测试人 员在某个职位停滞不前的问题，目的就是实现团队成员达到哪个能力等级就做哪个能力要求职位的事。比如，第二等级的能力要求定义是完全知道怎样测试并能够根据测试用例独立执行测试工作，第三等级的能力要求 定义是能分析问题的原因所在、能监控和管理其他测试工程师的工作。因此，当某成员的技术和经验达到第 三等级的能力要求时，就可以安排他作为测试项目的核心组成员或测试负责人。 在这个职业路标规划的指导下，我们可以要求每个团队成员 制定自己的短期和长期目标，目标的制定可 以是以一个项目时间为周期，也可以季度或年为周期。每个目标的实现就是团队的一个进步。目标就是团队 成长的根本。 4 / 21 其次，构造团队的学习和交流的氛围。有目标也就有了压力，压力就会产生学习的动力，团队成员针对 自己的规划，也会希望自己能够在团队中学习到更多的知识和技能。另外，高效的团队也要求每个团队成员 的良好技能来达到高效的目的。因此，学习的氛围是高效的测试团队必不可少的。如何建立这种氛围可以尝 试以下 几个方法： 1. 组织资深测试人员定期在测试团队内部进行经常性的培训和测试经验交流，通过该渠道帮助资历浅的 测试人员大幅提升业务技能，做到新老员工之间的知识传播和继承。可以建立部门的讲师制度，鼓励资深测 试人员担任讲师，定期安排培训，并奖励优秀的讲师。 2. 在项目的间歇空闲期，安排测试团队成员进行技术专题研究，这个研究可以是某方面相关的新技术，新测试方法，也可以是其他技术基础知识的收集和积累。每个人都把收集或研究的结果做成演示文稿，在整 个团队的 培训中介绍自己的研究成功，一方面巩固了学习知识，更重要的是让整个团队成员拓展了知识面， 达到了知识团队分享的目的。 3. 适度培训开发部门的基本知识，这样能减少与开发团队协同工作时的领域障碍。这里就需要团队负责 5 / 21 人和开发部门建立交流机制，邀请其他部门经验丰富人员对测试人员进行知识的拓展。 再次，培养测试团队成员养成总结的习惯。弄清楚产生问题的原因，以便下次避免发生类似的问题，这 不仅是一次学习，同时，及时对自己的工作进行总结是也一个非常良好的提升个 人和组织能力的机会。在团 队中建立 “总结”的氛围非常重要，测试发现的很多问题都是不经意间产生的，很多独特的测试方法也是在 测试深入过程中灵感突发的产物，而记录并传承这些好的方法就需要有总结意识。总结也需要团队的分享， 这样成员的经验才能提升为组织的经验。 管理是一门艺术，团队建设则是这门艺术的难点。有关测试团队的建设仍然还有诸如测试人员的考核等 等诸多课题值得我们探讨和改进，但只要我们在团队建设中真正做到“以人为本”，再建立适合自己的流程 和制度，相信您的团队一定离成功高效的团队不远了。 说说您的职业发展历程吧 丁志义：早在上世纪末即 1998 年左右国内兴起了企业信息化改造浪潮，我有幸在一家国有企业下一合资子公司，作为外协主管和仓库管理员的指导者，参与公司信息系统的 开发。开始接触 ERP 理念，为公司信息化建设小组成6 / 21 员，主要负责采购、库存方案制定，功能要求和界面描述、调试应用系统并向其他同事转移知识、完善计划管理系统，并于 2001 年 5 月完成信息系统集成。 2002 年 3 月股份公司总部引入 Oracle-ERP，我作为ERP 项目实施组核心成员，参与项目实施，全程参与 ERP 理念培训参与分公司业务流程描述，分销、制造模块实施核心成员，承 担最终用户培训、户手册编写、岗位职责制定、上线方案讨论确定、数据导入、系统优化等。 XX 年 3 月加盟用友软件生产制造开发部，从最基本的软件测试做起，从 XX 年 12 月起担任测试经理工作，先后负责 U860/U861/870/871/871/890/等各大版本生产制造功能测试和产品发布，参与制造测试，其间总结和发表过多篇软件测试论文。 职业发展过程中让您印象深刻的困难或 者事情？ 丁志义：是从一个普通的测试人员，转变成一个测试经理。在此之前一切事情都由上级安排和计划，自己大多数情况下只是参与者和执行者。而作为测试经理，除了日常测试之 外，还要承担管理者的责任，即要计划，组织，指挥协调，沟通和计划，组织协调变的更重要了。以前留下可复用的资料很少，要自己逐一建立起来，例如：测试用例编写规则、工具使用方法、测试计划模版、各种专项测试方案等、交叉测试设计、测试总结等。在经历 1 个版本周期后所7 / 21 有资料都建立起来，写了 1 篇指导测试的总结之后，才觉得难关终于度过。在以后的测试过程 中所有资料和方法都可复用，工作起来轻松许多。 如何组建测试团队 如何找到合适测试团队的人员？一个测试团队需要什么样类型的成员？ 丁志义：软件测试是个烦琐重复的测试过程，对测试人员的素质要求具有特殊性，那就是要耐的住性子，经得起折腾，抗的住压力，还要敏感细致，要有激情和学习能力，性格开放，较好的沟通能力，因此需要测试人员的符合这样的性格，另外最好要具有适合测试项目背景知识的人，然而要找到这样的人才不容易，无法通过短短的面试获取这样的人才，一般要靠试用期甚至工作中逐渐培养，培 养出团队精神和默契。也可以从开发团队内部挖掘 ，例如技术开发人员转型为测试人员，他们对产品比较熟悉，有一定的配合经历也目睹过测试过程等，而且在技术上的优势可以进行灰盒测试，开发些小工具辅助测试等。 测试团队中除了测试经理外，要有几个核心人物，他们在产品某些领域有丰富的实践经验，可以指导 1 到 2 名新人，这些是测试团队的中坚力量。另外要不断吸收 新人，随着产品的发展，技术的革新和人才的流动，要不断招募和培养新人，形成人才梯队，中间要有层次感，这样的团队才8 / 21 有激情才能稳定发展。团队中既要有功 能测试能力 强的，也要有自动化能力强的，但不一定需要各种技能集于一身。 如何组建一个高效的测试团队？需要考虑哪些问题？几人的组合是最合适的？ 丁志义：和尚喝水的故事告诉我们，人多了效率急剧下降。人是最主观和能动的，团队人员越多会形成更多隐性的 团体，各种“矛盾”也会随之产生，每个组员会随团队人数的增加而跟其他人产生干系因素增加，这不仅是测试团队的问题，其他团队也同样。软件测试过程中受到 开发过程中不可知问题影响，往往也很难按测试计划进行正常测试，因此会出现工作量的不均匀分布，如果不同人员分管不同测 试内容，进度的不协调就会出现混乱 局面，增加人和人之间沟通协调成本，即投入在工作上的时间和注意力将下降，从而效率低下。在测试团队中，同样会出现这种情况，管理和协调作用变的突出，需 要更多的团队精神。应根据产品测试的需要，选择符合项目需要的队员，组员能力互补，尽量安排不同人做不同的事情，这样工作中不会出现推委，避免资源重复投 入和内耗，样团队工作起来效率才会高。即要考虑，合适的人测试合适的内容，例如重点功能交给老员工测试，非重点内容交给新人测试，如果测试周期长的话要安 排交叉测试，测试后期采取自动化化回归测试 等。 一个小组 3 人效率可能会是最高，一个组长带 2 个9 / 21 组员，组员工作有分工，组长承担重要事项并查缺补漏，如果 1 个组员有紧急情况另 1 个组员也可补充。当然要根据项目的复杂程度，匹配一定的测试人员。 您觉得什么样的测试团队才是最理想的？ 丁志义：我认为测试团队中从能力看要符合正态分布，老中轻分布，中间人多些，新人要有但比例不能超过 20%，这样的梯队容易形成学习型组织，同时团队中有熟悉自动化的，有会编程的，也有文档能力教好的。性别上要有男有女，男女搭配干活不累，能主动帮助他 人，遇到重大情况能 互通信息，他们配合默契，团队意识好，荣辱与共。 如何管理测试团队 您的测试团队的发展模式是什么？在发展过程中遇到了哪些困难？ 丁志义：随着产品的变化，测试人员有增有减。主要是通过招聘新人补充新鲜血液，要保证中坚层人员数量相对稳定，不能太大变化。随着测试年限的变化，普通测试队员从测试工程师成长为高级工程师或测试组长，再成长为测试专家或测试主管，也有部分转变为产品需求人员。 发展中老的测试人员会越来越多，测试变的很枯燥烦琐，这部分人员的发展空间受到限制，工作变的无 激情，效能在下降。另外：会有多年培养的下属或者配合默契的队员离职，感到失落。 10 / 21 您认为测试团队建设应该包括哪些方面的内容？ 丁志义：我认为要包括： 1 业务能力建设，即对测试的产品知识逐渐提升，熟练掌握； 2，测试技能建设，即测试 方法和技巧的提升，如何快速有效的发现缺陷， 3 项目管理建设，培养下属项目管理方法，如何编制测试计划，并随项目进度适时调整，识别并规避风险 4，知识共 享，沉淀经验形成知识文档并分享 5，创新思维，识别需要改进测试方法，不断提升测试效率，减少人的重复劳动，减少加班 6，文化 建设， 要有时间进行学习培训 和文娱活动，培养团队文化，增强团队向心力。 如何做好测试团队的培训工作？您是如何提升测试团队的能力的？有一些什么具体的手段么？ 丁志义：培训不能流于形式，要制定培训计划，针对不同层次安排不同的培训内容。培训中要签到，记录每人接受培训的内容和时长，培训过程中采取头脑风暴法，培训后最好在短时间内结合项目消化，如能通过考试形式的最好有考试，并设置通过标准。在团队中通报考试分数，互相激励比较。 团队能力主要靠内部培训以及传帮带，我们对新人设 计培训课程大纲，组织不同角色的老师培训不同内容，培训结束后要经过考试，检验培训效果；另外 就是在实际工11 / 21 作中学习和能力提升。闲暇时我们分工，每人对他擅长的一块拿出来讲解分享，互相学习。会布置写作业让组员去总结，在总结过程中是一个知识梳理 过程，自己写清楚了也就掌握了。对于新的工具我们集体学习后，由一个人专门去跟踪和研究，透彻了再转移给大家。每一版本发布后我们集体学习和总结，输理工 作思路，为下个循环做准备。 如何考核测试团队？做好测试团队的激励制度？ 丁志义：可以采取定性和定量相结合的方式，根据里程碑时间点完成测试内容并确保产品质量，这是定性，对拖期 的要给出原因，扣除 KPI 得分；在正常的测试过程中参考每日缺陷数量，或者一定时间内缺陷的总数作为数量考核参考，我们应该尽量扩大测试人员量化考核指标，减少定性指标。 人都有惰性，采取适当的激励措施充分发挥积极性和主动性是必要的。除了有物质奖励反映在奖金上，和精神奖励反映在奖状或证书上外，应该还要有个 人实现的一种满足，例如对协调能力和业务能力强的要让其担当测试组长，鼓励创新和知识共享评比选优并颁发 专项奖。工作中采取看板管理发布发现缺陷排名，鼓 励大家高效率工作少加班，不定期的小聚一下放松身心等。对团队中表现差的甚至效率极其低下的要适时关怀帮助，如能提升和改进最好，如是态度问题则尽早辞 去。 12 / 21 作为管理者，怎样才能发挥测试团队的最大效率？ 丁志义：通过激发测试队员的积极性充分发挥各自潜能，并培养团队协作氛围增加团队精神，工作上步调一致，来 最大程度的发挥团队效能。不同测试阶段采取不同测试策略，例如测试过程中出现定位效应、审丑疲劳和同化现象可采取交叉测试来规避；鼓励创新，不断变化测 试 方法来提升测试效率；尽量让每个人做不同的事情减少重叠和内耗，在专长上面要有互补性，充分发挥各自特长。 给测试人员的意见和建议 丁志义：在测试中成长并寻找快乐，虚心学习不放弃兴趣，对未知的和未测试的领域主动测试，勤于总结并乐于分享，多涉猎些项目管理和测试的产品背景知识，开拓视野丰富自己，这样才能不断进步。 给测试团队成员的意见和建议：每个人有自己的专长，要把专长保持好并不断创新，要互相取长补短， 多向资历老的同事学习，多问多记多总结。业精于勤，测试虽然辛苦但也 是有趣的。 给测试经理 /主管的意见和建议：识人善用，充分发挥队员各自优势，并为队员提供适度的宽松环境和自主的时间支配，这样组员积极性会高，团队效率 会高。要做组员的坚强后盾，当工作中遇到问题时，能为他们提供支持和帮助，并把自己的知识尽可能的转移给组员，促进下属成长，13 / 21 自己从中解放出来思考更多问题。 建设高效软件测试团队的方法 软件测试的定义有许多种，其中比较权威的是 IEEE在 1983 年提出的 :“使用人工或自动手段来运行或测定某个系统的过程，其目的在于检验它是否满足规定的需求 或是弄清预期结果与实际结果之间的差别。” Grenford J. Myers在 The Art of Software Testing一书提出 : 软件测试是为了发现错误而执行程序的过程； 测试是为了证明程序有错，而不是证明程序无错误； 一个好的测试用例是在于它能发现至今未发现的错误； 一个成功的测试是发现了至今未发现的错误的测试。 这种观点提醒人们测试要以查找错误为中心，而不是为了演示软件的正确功能。但认为发现错误是软件测试的唯一目，查找不出错误 的测试就是没有价值的，事实并非如此。事实上，对于软件来讲，不论采用新的语言、先进的开发方式、完善的开发过程，可以减少错误的引入，但是不可能完全杜绝软件中的错误，软件中的错误需要测试来找出，软件中的错误密度也需要测试来进行估计。 统计表明，在典型的软件开发项目中，软件测试工作量往往占软件开发总工作量的 40以上。而在软件开发的总成本中，用在测试上14 / 21 的开销要占 30到 50。为了尽可能多地找出程序中的错误，生产出高质量的软件产品，加强对测试工作的组织和管理就显得尤为重要。 “工欲善其事，必先利其器” 。要做好测试工作，首先需要建立并维护一个高效的测试团队。 Barry Boehm 指出，人的特点和与人相关的活动是软件开发改进中最具潜力的部分。换言之，人的因素比任何其他因素对工作效率的影响都大。 Barry Boehm 在他的 cocomo 工作量预估模型中考虑到这一点，允许不同情况下分析师和程序员的工作效率相差到4 倍。测试计划、测试开发甚至测试执行的工作效率也有类似的情况。如果您正寻找一种提高团队快速测试产品能力的单一最佳方法，高素质的人员显然是值得优先考虑的。 一、 成功测试者的特质 人是 测试工作中最有价值也是最重要的资源，没有一个合格的、积极的测试团队，测试就不可能实现。为高质高效地完成测试任务，好的测试者应具有如下能力。这份特质清单是基于经验和观察，而不是基于严格的科学依据。 1. 自信心 开发者指责测试者出了错是常有的事，测试者必须对自己的观点有足够的自信心。如果容许别人对自己指东指西，就不能完成什么更多的事情了。自信心是指测试者必须对测试工作的价值具有足够信心，不会因开发者指责测试结15 / 21 果没有意义甚至反唇相讥而影响工作情绪。 经受得住坏消息而保持目标的能 力。一个测试者必须忠实地汇报产品中的缺陷。这一信息应当被项目组欢迎，因为每一个测试者遇到的问题都意味着减少客户会面临的问题。但不幸的是很多人不想听到有问题，特别是在程序项目的后期。测试者应当能处理因为工作做得太好而引起责备的情况。这对有些人来说是很难做到的，会严重地影响斗志与自尊。 2. 怀疑精神 怀疑精神是指测试人员对任何可能出错的地方都亲自测试一番，不听信开发人员毫无意义的保证，坚持以事实说话的工作作风。 可以预料，开发者会尽他们最大的努力将所有的错误解释过去。测式者 必须听每个人的说明，但他必须保持怀疑直到他自己看过以后。 怀疑的而不是敌意的态度。测试者不能按表面值接受事物，必须执着地对一切提出疑问直到被证实。测试者必须用一种与项目的其他的人合作精神来平衡这种怀疑性与执着性。特别是在大量缺陷被发现后，或者在每个找出的缺陷会潜在地延迟产品的发货时间而延迟了项目时，测试者与其有关部门的关系可能会变得紧张。测试者应当记住要攻击程序的整体性，而不是程序员。 16 / 21 否定性的创造力。一个软件工程师不能怕引起一个产品的瘫痪或烧毁。在软件测试中，边界意味着被超越而不是 被遵从。如果一个程序对某个值的极限为 10，测试者的第一想法应当是“如果我把那个值取 11，或 0，或，甚至不设这个值会如何？” 有能力打破一些东西并且感觉不错。 由于测试的工作是发现缺陷，测试者必须对发现别人的缺陷感到满意。 3. 沟通能力 一名理想的测试者必须能够同测试涉及到的所有人进行沟通，具有与技术开发者和客户、管理人员等非技术人员的交流能力。 与客户沟通，须用客户的眼光进行评价。和用户谈话的重点必须放在系统可以正确地处理什么和不可以处理什么上。测试者必须是客 户的拥护者。被测程序有可能运行可靠满足所有的设计要求，但在客户的软件环境中未必能够用。产品被送到客户之前的测试之一就是要证实产品达到了客户的要求与期望。在这项测试中，测试者必须模拟用户的软件环境，把自己放到他们的位置上。计算机系统功能要“正确”，且满足用户的需求。 而和开发者谈相同的信息时，就必须将这些话重新组织以另一种方式表达出来，能够表达导致问题的事件发生次序和系统配置。这包括能够清晰地编写过程和结果文档，17 / 21 以及能够与开发人员、其他测试人员和管理层进行口头沟通。能够提出批评和接受批评。 具有幽默感，在遇到狡辩的情况下，一个幽默的批评将是很有帮助的。 能够向开发者和管理层报告坏消息。如果到了最后时刻要发布的产品还是有不小的问题，测试者必须自愿站出来，说出这个不好的消息。 4. 技术能力 测试团队需要许多领域的专家，诸如数据库、通信、网络、 GUI 测试、测试工具、自动化测试脚本和相关业务领域的专家。因此，测试者须拥有一项或多项的技术专长。 就总体言，开发人员对那些不懂技术的人持一种轻视的态度。一旦测试团队的某个成员作出了一个错误的断定，那么他们的可信度就 会立刻被传扬了出去。一个测试者必须既明白被测软件系统的概念又要会使用工程中的那些工具。要做到这一点需要有几年以上的编程经验，前期的开发经验可以帮助对软件开发过程有较深入的理解，从开发人员的角度正确的评价测试者。其次，测试组成员应具备良好的专业技能或者技术学习能力。由于测试组各个岗位需要的技能各有差异，所要掌握的测试技术也千差万别。比如测试管理人员需要对测试管理工作的内容及相关辅助工具的使用胸有成竹；自动化测试人员需要对相关自动化测试工具炉火纯青；测试脚本撰写人员需要对脚本语言的领悟了然于18 / 21 胸；手工测试人员应对 相关测试中最易发现问题的地方如数家珍；而测试团队负责人则必须既熟悉被测软件系统的概念模型、设计模型，又要掌握开发过程中涉及到的相关开发工具。除此之外，测试经理还必须深刻掌握测试流程的裁剪、测试环境的搭建、测 试计划的撰写、测试活动的组织与开展以及测试效果的评价等必备技能。 5. 外交能力 外交能力是指测试人员在与其他人员交流的时候，要注意自己的辞令和行为方式，不要刻意夸大错误的严重性，也不要碍于面子替开发人员掩饰重大程序错误。 当测试者告诉某人他出了错时，就必须 使用一些外交方法。机智老练和外交手法有助于维护与开发人员的协作关系，测试者在告诉开发者他的软件有错误时，也同样需要一定的外交手腕。如果采取的方法过于强硬，对测试者来说，在以后和开发部门的合作方面就相当于 赢了战争却输了战役 。 6. 很强的记忆力 一个理想的测试者应该有能力将以前曾经遇到过的类似的错误从记忆深处挖掘出来，这一能力在测试过程中的价值是无法衡量的。因为许多新出现的问题和我们已经发现的问题相差无几。 19 / 21 迁移能力是指测试人员应能将以前曾经遇到过的类似错误从记忆中挖掘 出来，并迁移到当前测试活动中。 7. 自我督促 干测试工作很容易使你变得懒散。只有那些具有自我督促能力的人才能够使自己每天正常地工作。 需要有耐心。能够根据需要反复执行测试，直到问题被解决，然后再反复执行，以验证问题已被修正并且不再出现。 8. 洞察力 一个好的测试者具有“测试是为了破坏”的观点，捕获用户观点的能力，强烈的质量