如何搭建一个高效测试团队.docx

测试工作在软件开发中是一个重要的工作组成部门，确切的是：没有测试部门，研发工作是可以进行的，但没有一个好的测试部门确能研发出优秀的软件产品是不太可能的。所以说，建设一个好的测试部门，对软件研发是一个非常重要的事情。但如何建设一个测试部门，什么样的测试部门才算一个好的测试部门？对这些问题人们往往考虑的比较少，说一说我自己在这个问题的看法，以及在提升测试部门能力的时候经常遇到的一些问题。 在测试部门建设中经验遇到的问题 1测试人员的素质可以比开发人员低，因为他们承担的工作比较容易。 2测试的工作量比较容易和简单，人员可以少一点 3测试工作量很大，因为单位不重视所以人员一直配置不够，因此测试部门的工作效果不好 4使用自动化测试工具，可以很大的提高测试效率，所以让我们用测试工具吧 5测试人员不用了解系统，没有必要给他们需求报告、概要设计、详细设计等文档 6开发人员总是很忙，让测试人员来编写用户使用说明书吧， 7测试人员不用编写代码。他们只负责测试。 8测试人员不了解系统，他们总提一些莫名其妙的bug. 9研发人员就改了系统的某一个部分的代码，测试有必要全部测试吗？只测试修改过的地方不就行了吗？ 10那么多问题，实际都是一个问题造成的，你们测试人员干什么提那么多bug。 不用多想就可以有一大堆的问题，开发人员烦恼，觉得测试人员技术水平低，在开发过程中尽给自己找麻烦，测试人员苦恼，觉得自己的工作不被认可，还总受开发人员的“欺负”，而且你找上级去反映问题，最后吃憋的总是测试人员，似乎用无出头之日。为什么会这样，如果简单来说，测试人员和开发人员在开发过程中的确是一对矛盾体。但他们的目的又是相同的-开发符合用户需要的软件产品，但在实际的软件开发工程中，测试人员和开发人员所站的角度和立场不同，所以造成矛盾是必然的。如何化解这些矛盾。达到良好的共同开发的效果，一个关键的问题就是明确开发过程中各种角色的责任、权利。做的各付其责，但实际上很多公司并没有一个良好的开发流程，人员的职责划分也不是很明确，在这种条件下，如何通过改进测试部门的工作质量来提高研发工作质量就是每一个测试部门负责人需要面对的问题了。 我想通过说明我们公司测试部门的改进，说一下我对改进测试部门工作质量的看法，按阶段进行描述吧：A第一阶段，痛苦期 之所以叫它是痛苦期，的确因为这个阶段很痛苦，人员不够，素质不够，和开发人员需要不断交流，人忙死了， 在我进入测试部门的时候，测试部门的状况的确很不乐观，经过测试部门测试的软件，到现场的时候问题不断，没有测试和有测试的软件基本没有差别，一旦软件出现问题，责任就会退到测试部门，测试部门人也少，大家的情绪也不高，做一天和尚撞一天钟已经是不错的了，经过一段时间观察，基本确定了测试部门在这个阶段的主要表现和问题所在。主要表现 1测试人员工作缺乏独立性，由于公司的测试人员处于弱势地位，测试人员的测试需求和测试用例实际是受开发人员控制的，有时候测试需求和测试方法都是有开发人员来确定，所以测试 2测试个工作不规范，虽然在单位的质量管理文件中明确规范了测试流程，但并没有人去遵守它3测试质量无法保证。领导和开发人员对测试结果并不相信，原因很简单，测试过的系统在上线的时候总是出现问题，而且很多问题很低级， 4测试人员是所有问题的承担者，一旦出现问题那么测试人员就要承担出现问题的责任，而实际上很多问题并不是测试人员造成的，于是造成我说是bug，开发人员不承认，上线出问题了又怪我们测试人员，我们怎么这么倒霉，干脆就这样吧 5测试强度低，全部是手工测试，测试需求点只有300-500个，测试强度低直接的结果就是发现的问题少，于是开发人员会不断提交测试版本，而回归测试由于采用手工测试简直就是测试人员的噩梦。改进目标： 在这一阶段的测试部门管理人员是很难受的，人员数量、人员素质、工作方法的低下给测试部门经理造成极大的困难，而繁重的测试任务又是必须要完成的，说一下我当时的工作方法，和这阶段的改进目标 1人员的选择 2引入项目管理思想 3规范测试流程 4初步引入自动化测试工作 5引入工作绩效考核B第二阶段 发展时期（矛盾发生期） 在度过了最初3个月的痛苦期，你已经有了一个基本的成型的测试队伍，工作成果也不断显示出来，但后边的3个月，是你的测试团队成长的一个关键时间，如果这个阶段可以顺利通过，那你的测试团队可以在公司站稳脚跟，否则，你前期的一切工作都将白费，而这一时期你所遇到的困难不但有和测试团队内部的问题，更加突出的是和开发人员甚至是开发管理人员之间的矛盾，如何协调测试部门和开发部门之间的矛盾成为这一个时期的主要问题，善于保护自己，善于保护测试人员的积极性，协调开发人员，共同促进研发工作的质量的提高成为这一时期的主要工作内容这一时期的主要问题表现 1和开发人员的矛盾急剧增多，而且和开发管理人员的矛盾也在不断增多 2软件版本不断更新，造成测试时间无法保证， 3开发人员要求用集成测试替代系统测试 4测试要求的提升，测试人员水平的提升成为一个新的要求 5测试工作和软件质量工作的冲突 6测试工作本身的过度测试以及如何剪裁改进目标 1提升开发人员对测试工作的理解，召开测试结果评审会议 2明确项目研发工作中测试人员的作用、地位和职权 3划分测试人员，形成测试管理队伍和测试技术队伍， 4引入新的测试手段，逐步引入性能测试手段 5给测试部门引入项目管理概念和质量保证概念C第三阶段 持续改进 测试部门在有一个不错的测试队伍，如何稳定这个队伍，增加团队的凝聚能力，和开发团对更好的配合，就成持续改进的一个重要目标，在改进测试团队的开始阶段由于很多问题是比较表面化的，经常是就事论事。但到了持续改进阶段很多深层次的问题会暴露出来，而如何看待和解决这些需要测试部门管理有更好的经验和意识，用自己的智慧去解决这些问题这阶段的主要问题 1测试人员的未来的发展（技术生涯的规划） 2人员的分流问题（内部分流/外部分流） 3技术水平的提高（测试技术水平和开发水平） 4项目管理能力的提高 5人际关系的处理 6工作态度俗话说“工欲善其事，必先利其器”，要做好测试工作，首先需要建立并维护一个高效的测试团队。然而，许多小型软件企业却将测试作为产品面临发布时的一个小“插曲”，往往临时抽调几名程序员对产品的功能粗略测试一下即交付客户（甚至在进度和成本不足时首先砍掉这一块）。这种仓促完成的产品通常质量问题很多，所以我们首先应抛弃小企业惯常的思维模式，不计较一时一地之利益，立足长远，着手组建高效测试团队。第一步：招募测试人员在国内的软件企业中有一种普遍做法，那就是把那些刚涉足软件行业的技术新手或业绩不突出的开发人员安排去做测试工作。笔者认为这绝对是一种欠妥当的行为。事实上，对一个系统进行有效测试所需要的技能绝对不比进行软件开发所需要的技能少，测试从业者甚至可能面对许多开发人员都不会遇到的技术难题。那么，测试团队需要招募什么样的成员呢？这里，笔者总结了以下两点：首先，测试人员要具备良好的沟通能力、自信心、外交能力、迁移能力以及怀疑精神。其次，测试组成员应具备良好的专业技能或者技术学习能力。当然，新招募的测试人员不可能像上面说的那么理想。关键是他们是否热爱测试这项工作，对相关的工作内容是否感兴趣以及他们的学习能力如何。第二步：测试团队制度建设良好的制度可以规范测试团队的工作开展，同时也便于对团队成员进行业绩考评。相反,则很有可能导致人心涣散，滋长负面风气。建设良好的测试团队制度，可以考虑以下几个方面： 汇报制度 团队成员汇报本周工作情况及下周工作计划、遇到的问题以及需要提供的帮助，培养团队成员的汇报及计划习惯。 工作总结制度 成员每个阶段汇报上阶段工作经验和教训，并在部门例会上交流、分享经验及教训，避免同样的问题重复出现。 奖惩制度 对于贡献突出的成员予以奖励，对于业绩差的提出批评，有效地保持测试团队的工作热情。 测试件审核制度 对测试件进行审核，去粗存精，鼓励测试人员使用和提出改进，保证提交到测试团队知识库的测试件的质量。 会议制度 定期召开部门例会，讨论、解决工作中的问题，并提供部门内的学习平台。目前，已有不少软件企业推行给测试人员区分级别的制度，奖优罚劣。这无疑是一个好的做法，但成员业绩的具体考评办法，目前尚无可供参考的标准文件，所以笔者建议应尽量做到公正客观，以免挫伤团队成员的工作积极性。第三步：测试团队内部的职责分工明确测试团队内部各类测试人员的职责分工可以使测试团队内部各类测试人员能集中精力在较短的时间内完成特定岗位必需的知识储备和经验积累，同时也使得测试团队的管理更科学，真正做到“用其所长，避其所短”。第四步：测试流程建设我们可以通过以下步骤来建立适合本单位的测试流程：1. 测试团队负责人员根据对公司现有测试状况的了解，及个人的测试经验，起草测试流程及相关的模板；2. 通过一到两个项目的实践，记录测试流程草稿中的问题及不足之处；3. 根据实施经验，完善测试流程，得到测试流程初稿，并起草相关实施指南；4. 选择一个到多个项目，实践上述测试流程初稿及实施指南，记录实践过程中出现的问题；5. 根据上述实践工作的反馈，组织修改测试流程初稿及实施指南，并把修改后的测试流程继续应用到项目实践中去，根据反馈进一步完善成熟；6. 测试流程及其相关文件基本趋于稳定状态时，可以考虑发布测试流程（含测试流程、模板、表格、指南），并在以后的实践中不断改进和完善。内容导航第五步：团队成员能力的逐步提高有了明确、合理的职责分工后，需要针对这些分工对团队成员进行有意识的引导，稳步提升团队成员的技能。测试团队负责人需要负起监督和促进员工能力提升的任务。监督和促进测试团队成员能力提高，主要做好如下三个方面的工作:一是，提倡资深测试人员在测试团队内部进行经常性的培训和测试经验交流，通过该渠道帮助资历浅的测试人员大幅提升业务技能，做到新老员工之间的知识传播和继承。二是，测试团队应充分利用好测试件知识库，对于纳入到测试团队知识库的测试件应充分消化和学习，在此基础上进一步鼓励测试团队成员对这些测试件提出改进性意见。三是，测试人员除了需要注重自身的测试技能提升，在条件许可的情况还应适度开发部门的基本知识，这样能减少与开发团队协同工作时的领域障碍。许多测试经理在编制测试用例时往往没有把测试用例和测试数据进行区分，因此，造成的问题是当需求变化时辛辛苦苦设计的数据就作废了。在这时，假使面临一个需求动态的项目，必须在计划中对需求变更造成的测试（设计）方式变化进行说明，例如采用用例和数据分离、流程和界面分离、字典项和数据元素分离的设计方式，然后等到最终需求确定后细化测试设计；另一个方面是最好制定一个变更周期的约定尤其在执行测试阶段发现需求的变更定义变更的最大频度和重新测试的界限，计划从一定程度上能够降低不可预期需求变化造成的投入损失。值得注意的是：需求发生变更时测试经理额外的工作是记住要在需求跟踪矩阵上做记录。对于测试产品版本的变更，除了部分是由于需求变更造成之外，很有可能是由于修改缺陷引发的问题或配置管理不严格造成。众所周知，测试必须是基于一个稳定的“基线”进行，否则，因反复修改造成测试资源和开发资源的浪费是可观的。合理的测试计划在章节中应增加一个测试更新管理的章节，在此章节明确更新周期和暂停测试的原则。例如，小版本的产品更新不能大于每天三次，一个相对大的版本不能每周大于1次，规定紧急发布产品仅限于何种类型的修改或变更，由谁负责统一维护和同步更新测试环境。测试计划通常制定了准入和准出准则，这是不够的，要考虑测试暂停的时候，产品错误发布或者服务器数据更新就是一个例子，暂停的时候如果测试经理不进行跟踪，可能发生测试组等待测试而没人通知继续测试的情况，所以，增加更新周期和暂停测试原则是很有必要的。最后，测试资源的变更是源自测试组内部的风险而非开发组风险，当测试资源不足或者冲突，测试部门不可能安排如此多的人手和足够时间参与测试时，在测试计划中的控制方法与测试时间不足相类