尽管组建一支高效的测试团队是一项复杂、艰巨的任务，需要软件企业投入足够的关注和一批高素质的技术、管理人才，但是，这项工作带来的长期效益却是巨大的。
    在目前的软件行业氛围下，一提到软件质量，肯定有不少业内人士的第一反应是ISO、CMM、6σ之类的标准，进而反映出的词汇就是SQA (软件质量保证)。因此，不少软件企业和机构都纷纷组建了SQA部门，把提高质量的希望全部都寄托于此。这当然是好事，至少说明了质量意识的普遍觉醒，但高层管理者却往往认识不到“质量工作是由多个部门各司其职共同完成的”。
    这样的大环境造成不少企业和机构的软件质量保证部门与软件测试部门关系尴尬：究竟是让测试部门下属于质量保证部门，还是应该单列测试部门使其以独立、中立的姿态出现？另外，测试部门与质量保证部门的权力和职责分配如何把握，谁更有权在必要的时候对某个开发项目、某个开发人员出示“红牌”、“黄牌”，谁更应该对用户投诉的产品技术问题负责？
    分清SQA、SQC和SQM
    目前广泛认可的衡量软件质量的标准是“软件产品能否较好地满足用户相关的各类需求”。然而，用户对软件的需求往往包罗万象，如功能需求、性能需求、约束性需求、潜在需求，甚至包括相互冲突的需求以及技术上不可实现的需求等，这就导致等软件产品生产出来再验证“产品是否满足用户需求”容易成为一件引发供需双方争执的麻烦事，而且对于软件企业而言这种质量工作未免代价过高、风险太大，一旦查出严重问题，毫无补救措施。鉴于此，目前业内解决这个问题的核心策略是控制软件工程的品质以及软件产品（包括阶段性产品）本身的品质。前者主要涉及企业在工程过程中选用什么样的质量体系以及如何监督标准的执行，称为SQA，后者主要涉及验证产品在各个阶段具体品质如何、有无偏离用户需求等，称为SQC（软件质量控制）。
    那么，软件测试在软件质量工作中应处于一个什么样的位置呢？笔者认为软件测试应是SQC的核心内容和重要组成部分。由此看来，目前沸沸扬扬、闪亮登场的CMM、6σ等标准和体系，虽然被部分管理者顶礼膜拜，但充其量也只是SQA的一个组成部分，它们不能囊括质量工作的全部。相反，软件测试是SQC的核心，它更贴近质量工作本来的要义，理应受到更多关注。
    SQA和SQC各司其职，相辅相成，统一于软件质量管理（SQM）。拿一部汽车来做比喻吧，质量控制（QC）就是所有那些告诉你汽车当前运动状态的仪器仪表;质量保证（QA）包括各类标准，是告诉你所有部件操作方法的用户手册; 而质量管理（QM）则是你要追求的目标，比如希望能平安、高速地驾驶汽车。可以看出，为了实现质量管理的目标，质量保证和质量控制都是不可或缺的部分。
    建设高效测试团队的方法
    俗话说“工欲善其事，必先利其器”，要做好测试工作，首先需要建立并维护一个高效的测试团队。然而，许多小型软件企业却将测试作为产品面临发布时的一个小“插曲”，往往临时抽调几名程序员对产品的功能粗略测试一下即交付客户（甚至在进度和成本不足时首先砍掉这一块）。这种仓促完成的产品通常质量问题很多，所以我们首先应抛弃小企业惯常的思维模式，不计较一时一地之利益，立足长远，着手组建高效测试团队。
    第一步：招募测试人员
    在国内的软件企业中有一种普遍做法，那就是把那些刚涉足软件行业的技术新手或业绩不突出的开发人员安排去做测试工作。笔者认为这绝对是一种欠妥当的行为。事实上，对一个系统进行有效测试所需要的技能绝对不比进行软件开发所需要的技能少，测试从业者甚至可能面对许多开发人员都不会遇到的技术难题。那么，测试团队需要招募什么样的成员呢？这里，笔者总结了以下两点：
    首先，测试人员要具备良好的沟通能力、自信心、外交能力、迁移能力以及怀疑精神。其中，沟通能力是指测试者必须能够同测试涉及到的所有人进行沟通，具有与技术人员（开发者）和非技术人员（客户、管理人员）进行交流的能力。自信心是指测试者必须对测试工作的价值具有足够信心，不会因开发者指责测试结果没有意义甚至反唇相讥而影响工作情绪。外交能力是指测试人员在与其他人员交流的时候，要注意自己的辞令和行为方式，不要刻意夸大错误的严重性，也不要碍于面子替开发人员掩饰重大程序错误。迁移能力是指测试人员应能将以前曾经遇到过的类似错误从记忆中挖掘出来，并迁移到当前测试活动中。怀疑精神是指测试人员对任何可能出错的地方都亲自测试一番，不听信开发人员毫无意义的保证，坚持以事实说话的工作作风。
    其次，测试组成员应具备良好的专业技能或者技术学习能力。由于测试组各个岗位需要的技能各有差异，所要掌握的测试技术也千差万别。比如测试管理人员需要对测试管理工作的内容及相关辅助工具的使用胸有成竹;自动化测试人员需要对相关自动化测试工具炉火纯青; 测试脚本撰写人员需要对脚本语言的领悟了然于胸;手工测试人员应对相关测试中最易发现问题的地方如数家珍;而测试团队负责人则必须既熟悉被测软件系统的概念模型、设计模型，又要掌握开发过程中涉及到的相关开发工具。除此之外，测试经理还必须深刻掌握测试流程的裁剪、测试环境的搭建、测试计划的撰写、测试活动的组织与开展以及测试效果的评价等必备技能。
    当然，新招募的测试人员不可能像上面说的那么理想。关键是他们是否热爱测试这项工作，对相关的工作内容是否感兴趣以及他们的学习能力如何。
    第二步：测试团队制度建设
    良好的制度可以规范测试团队的工作开展，同时也便于对团队成员进行业绩考评。相反,则很有可能导致人心涣散，滋长负面风气。建设良好的测试团队制度，可以考虑以下几个方面：
    汇报制度 团队成员汇报本周工作情况及下周工作计划、遇到的问题以及需要提供的帮助，培养团队成员的汇报及计划习惯。
    工作总结制度 成员每个阶段汇报上阶段工作经验和教训，并在部门例会上交流、分享经验及教训，避免同样的问题重复出现。
    奖惩制度 对于贡献突出的成员予以奖励，对于业绩差的提出批评，有效地保持测试团队的工作热情。
    测试件审核制度 对测试件进行审核，去粗存精，鼓励测试人员使用和提出改进，保证提交到测试团队知识库的测试件的质量。
    会议制度 定期召开部门例会，讨论、解决工作中的问题，并提供部门内的学习平台。
    目前，已有不少软件企业推行给测试人员区分级别的制度，奖优罚劣。这无疑是一个好的做法，但成员业绩的具体考评办法，目前尚无可供参考的标准文件，所以笔者建议应尽量做到公正客观，以免挫伤团队成员的工作积极性。
    第三步：测试团队内部的职责分工
    明确测试团队内部各类测试人员的职责分工可以使测试团队内部各类测试人员能集中精力在较短的时间内完成特定岗位必需的知识储备和经验积累，同时也使得测试团队的管理更科学，真正做到“用其所长，避其所短”。这里列出一种可行的测试团队内部职责分工方案，如表所示。

  第四步：测试流程建设
    测试流程，通俗地讲是指测试团队按照什么样的流程和顺序组织开展软件测试活动。通常来说，测试流程如图所示。

  其中，计划测试阶段是根据对测试需求的分析制定测试大纲、测试计划，并对具体要采用的测试技术做大致剪裁; 设计测试阶段是对测试大纲、测试计划作进一步细化，从而形成更为细致全面的测试用例集、具体测试活动安排以及相应的测试进度; 执行测试阶段是执行相关测试用例（包括自由测试），具体落实各项测试活动; 分析测试阶段是对计划测试、设计测试、执行测试阶段的工作做出评价，评估测试的有效性。以上是测试流程的大致组成，不同测试团队采用的测试流程在细节上可能会有出入。我们可以通过以下步骤来建立适合本单位的测试流程：
    1. 测试团队负责人员根据对公司现有测试状况的了解，及个人的测试经验，起草测试流程及相关的模板;
    2. 通过一到两个项目的实践，记录测试流程草稿中的问题及不足之处;
    3. 根据实施经验，完善测试流程，得到测试流程初稿，并起草相关实施指南;
    4. 选择一个到多个项目，实践上述测试流程初稿及实施指南，记录实践过程中出现的问题;
    5. 根据上述实践工作的反馈，组织修改测试流程初稿及实施指南，并把修改后的测试流程继续应用到项目实践中去，根据反馈进一步完善成熟;
    6. 测试流程及其相关文件基本趋于稳定状态时，可以考虑发布测试流程（含测试流程、模板、表格、指南），并在以后的实践中不断改进和完善。
    第五步：团队成员能力的逐步提高
    有了明确、合理的职责分工后，需要针对这些分工对团队成员进行有意识的引导，稳步提升团队成员的技能。测试团队负责人需要负起监督和促进员工能力提升的任务。监督和促进测试团队成员能力提高，主要做好如下三个方面的工作:     一是，提倡资深测试人员在测试团队内部进行经常性的培训和测试经验交流，通过该渠道帮助资历浅的测试人员大幅提升业务技能，做到新老员工之间的知识传播和继承。二是，测试团队应充分利用好测试件知识库，对于纳入到测试团队知识库的测试件应充分消化和学习，在此基础上进一步鼓励测试团队成员对这些测试件提出改进性意见。三是，测试人员除了需要注重自身的测试技能提升，在条件许可的情况还应适度开发部门的基本知识，这样能减少与开发团队协同工作时的领域障碍。