本节书摘来自异步社区《软件测试技术大全：测试基础 流行工具 项目实战(第3版)》一书中的第2章，第2.2节融入测试组织，作者陈能技 , 黄志国，更多章节内容可以访问云栖社区“异步社区”公众号查看。
2.2 融入测试组织
不同的软件企业由于种种原因会设置不同的软件测试组织形式和结构，没有哪两家公司的软件测试组织是一模一样的。即使是结构一样，由于职责范围和沟通方式不一样，也会导致测试组织的表现形式不一样。
对于一个需要加入到新的测试组织中去，尤其是一些新入行的测试人员来说，要特别注意如何让自己快速地融入项目团队的测试工作中。
**注意
如何让自己快速融入项目团队是实现成功的软件测试的第一步。**
2.2.1 根据开发的模式判断自己的测试角色定位
每一个公司都会根据自己的研发模式和对质量的认识来界定测试组织的用途以及测试人员的角色定位。
（1）在不同的软件开发模式中，测试的角色定位是不一样的。
传统的软件开发模式中，软件测试人员可能仅仅需要完成系统测试的任务就行了。而在敏捷开发模式中，则可能需要进行更多的单元测试，与开发人员紧密配合，寻找Bug出现的根源。
不同的软件组织对于同一种开发模式存在不同的理解和应用，也会导致测试人员在其中的角色定位出现差异。例如，同样是实现微软的MSF开发模型，有些公司比较喜欢让测试经理担当软件发布决策人的角色，而有些公司则喜欢让测试经理作为程序经理的辅助角色，另外一些公司则更倾向于MSF的几个项目角色共同做出项目的决策，或者由更高层的项目经理来决定。
因此，测试人员在加入一个项目团队中时，要找准自己的角色定位，否则可能导致自己的工作职责范围不清晰，或者工作体现不出来，甚至感到现实与理想存在差距。
（2）微软MSF模型中的测试角色。
图2.4所示的是微软的MSF组队模型。从中可以看出测试是其中重要的角色之一。
软件测试人员与其他项目角色之间的关系是平等的，没有上下级关系。每个角色负责自己职责范围内的工作，每个角色之间通过沟通来协调工作。MSF组队模型的核心和基础是沟通和协作。
（3）敏捷测试角色。
在敏捷项目中，测试人员的角色可以进一步地细分，如图2.5所示。
在这个矩阵中，可分成4个角色。
面向业务的批判产品角色。
面向技术的批判产品角色。
面向业务的支持编码角色。
面向技术的支持编码角色。
在解释这4个角色之前，先要解释一下两条轴线的意义。在横轴上，左边是偏向“支持编码”的测试，右边则是偏向于“批判产品”的测试。但是两种测试的意义和内涵存在很大的不同。
2.2.2 “支持编码”的测试与“批判产品”的测试
对于支持编码，测试主要作为准备和保证。通过写测试代码来阐明关于问题的思考。把它作为说明性的例子来描述代码应该怎样做。另一方面，测试是关于暴露主要错误和遗露，也就是对产品进行“批判”。这里，测试的原义就是关于Bug。也有其他的意义，但是首要的意义是最主要的。（很多测试员，尤其是最好的测试员，在其身上已经融入了那些词语的内涵。）
2.2.3 “面向业务”的测试与“面向技术”的测试
在纵轴上，下边是“面向技术”的方面，上边是“面向业务”的方面。两者缺一不可。
“面向技术”是指测试人员在测试过程中更关注技术实现的正确性，并且需要应用到很多专门的技术来进行测试。而“面向业务”是指测试人员在测试过程中更加关注的是产品对业务实现的正确性，需要根据需求和用户的实际业务场景来进行测试。
面向业务的批判产品角色是指测试人员从用户的角度对产品进行测试，这种测试更关注产品对需求的满足程度，探索性测试是这种测试的常用方法。
面向技术的批判产品角色是指测试人员应用专门的测试技术对产品进行测试，例如性能测试、安全性测试、可用性测试等。
面向业务的支持编码角色是指测试人员编写代码来激发出正确的代码，测试人员首先编写测试代码来举例说明某个即将添加的新功能特性要怎样工作。然后程序员编写代码来匹配这些例子。FIT框架（Framework for Integrated）是这种测试方式经常用到的工具，利用FIT测试人员或者用户可以在Word文档中通过举例子、列表格的方式来说明某个功能需要满足的输入输出，FIT自动比较期待输出与实际输出之间的差异来判断测试是否通过。图2.6所示为Word文档截图是FIT的测试结果。
面向技术的支持编码角色是指测试人员使用单元测试代码来检查开发人员的编码，并且编写一些“保护性”的代码，来确保每次运行开发人员写的代码都能确保正确的仍然正确，如果开发人员针对代码进行了改动，测试人员编写的测试代码应该可以检测得出来。
关于敏捷测试角色的划分，Lisa Grispin在《敏捷软件测试》一书中有详细的描述。
2.2.4 测试的划分对敏捷项目开发的重要性
这种测试的划分对敏捷项目而言是重要的，因为不同方面的测试工作，可以由不同的项目组成员来进行。例如下面的几种。
面向业务的批判产品角色可以由用户来充当（在敏捷开发模式中，把用户作为项目角色之一）。
面向技术的批判产品角色由拥有专门测试技术的测试人员担任。
面向业务的支持编码角色由测试人员或用户充当。
面向技术的支持编码角色可由开发人员或熟悉单元测试方法的测试人员担当。
**注意
在实际中，这4个角色的工作都由同一个人来承担也是很有可能的。**
2.2.5 如何融入一个项目团队
对于一个新人，项目组可能表现出两种截然不同的态度，一种是非常热情地欢迎，并且主动提供了很多协助，让其可以更快地熟悉环境并且参与到实际的工作中。而同时可能存在的另外一种态度则让人有点恐惧。项目组采取了一种冷漠的态度，甚至是敌视的态度。在这种团队中工作，可能是测试人员一个非常大的挑战。
**注意
要想赢得大家的尊重是件不容易的事情。**
一个非常重要的前提条件是要做好本分工作，并且把工作的成果表现出来。如果项目组中已经有一位值得学习的测试前辈，那么很幸运，因为如无意外，这位测试前辈会给大家最大的支持。如果没有，那么就需要自己努力寻找各种项目相关的信息来帮助自己尽快熟悉项目。
测试新手如何融入一个项目团队中去？需要注意的因素如图2.7所示。
2.2.6 快速融入项目团队的技巧
与开发人员好好地相处，有效地工作在一起。测试人员需要掌握一些技巧。以下是想更快融入项目团队的测试人员可以参考的方面。
找到一些共同语言非常重要。例如找到跟自己一样喜欢某项运动的开发人员，经常邀请他一起运动。
尽量拉近距离，了解每位开发人员的性格特点。
开发人员会对正在开发的产品表现出浓厚的兴趣，与他们一起探讨软件的方方面面。
把缺陷跟踪库中所有以前的Bug都看一遍，尤其是目前处于激活状态的Bug，避免录入一些重复的Bug。
虚心的学习态度永远会受到大家的认可，但是要注意把握问问题的时机。
2.2.7 尽快投入测试工作的技巧
能否快速地掌握项目相关的知识，快速地投入工作，并表现出工作成果，是融入项目团队的关键因素，也是新加入的测试人员是否能尽快得到大家认可的前提条件。
下面是测试人员在接手一个新项目时需要注意的方面。
阅读需求文档、设计文档、用户手册是关键的第一步。如果项目已经启动并且进入了测试阶段，则一般会有需求规格说明书和相关设计文档可供参考，应该尽快熟悉和消化这些材料，获取测试需要的信息。如果用户手册已经编写出来，则对照用户手册操作软件系统，可以快速地熟悉系统各项功能，顺便也可以对用户手册进行检查。
如果处于前期的启动阶段，则应该多参与项目各种会议，尽量多了解项目的需求和各方面的知识（包括业务知识和测试技术）。
阅读已有的测试用例或根据需求和设计文档编写测试用例。如果项目已经启动并且进入测试阶段，则一般会有测试用例文档，这些测试用例也是后来加入项目组的测试人员快速上手的参考材料。如果没有测试用例，则可以根据需求和设计文档编写测试用例，这也是熟悉需求和软件系统的一个好办法。
阅读缺陷库中旧有的Bug，尝试按录入的Bug描述的步骤重现问题或测试软件系统。这种方法能借鉴别人的经验，使自己一步一步深入熟悉软件系统的功能细节。
