金融企业软件测试中心筹备书-组织架构篇

听海——sky

四、组织架构设置

      组织架构的设置是一切工作活动的基础，也是最重要的组成部分，组织架构要与工作环节以及工作模
式密切相关，不能想当然和拍脑袋，为了保证测试中心的长远发展，以及立足解决现状的测试任务问题，
可以考虑按照两种模式来设计测试中心：

1、测试管理团队、测试环境团队

2、测试管理团队、测试环境团队、功能测试团队、非功能测试团队

      这个主要是根据技术团队的规模，以及系统发展的不同阶段来定，各有忧虑，以下章节按照第二种模
式，表述各个团队的主要职责以及关键岗位。对于即将要成立测试中心的公司来说，其CTO完全可以直接
参考团队岗位设置，直接招聘该岗位经验丰富的人员，这样后续的工作开展方式，及工作流程、规范、模
板、制度、考核等一系列细节工作，则均可交由对应的负责人来进行细化和落实，CTO只要把握整体方向，
以及关注最终工作成果即可。

4.1、团队及岗位设置

4.1.1、测试管理团队

      该团队要负责整体公司的测试组织协调工作，制定重大项目上线版本点的整体测试计划、组织编制整
体测试方案，统一制定环境使用策略，跑批日期等公共事项，并要进行整体的数据准备工作，总之，各
项目需要整体协调的，均有该团队负责。

4.1.1.1 职责

该团队鉴于整体测试组织、协调的定位，具体职责如下：

l  负责全公司测试重大版本线测试计划编制与发布

l  负责全公司重大版本的测试方案编制

l  负责跟踪全公司重大版本线测试执行情况

l  负责重大项目版本的跨项目组组织、协调工作

l  负责组织整体测试规范编制与下发

l  负责组织全公司测试考核工作

4.1.1.2 关键岗位：

(1)、测试计划管理岗

      负责企业级测试计划的整体组织编制、修订、发布、跟踪。该岗位看似容易，但当系统繁多，上线点
及开发周期错中复杂时，排定计划将异常困难，同时也要协调各个项目组利益博弈的问题。

(2)、测试方案管理岗

      负责企业级测试方案的整体组织编制与发布。对于整个跨项目、跨中心的大型复杂测试项目来说，前
期的准备工作的重要程度甚至比实施阶段更为重要，而所有关键的测试信息和策略，都需要在方案中给予
明确，以保证整体测试活动的顺利开展。

(3)、测试执行管理岗

      负责企业级测试日报数据发布、风险组织报送、问题组织协调解决；负责组织全行测试考核工作。测
试为了保证质量可靠，必须要在事前、事中、事后三个阶段都做好充足的工作，而准备阶段，多依靠测试
方案来进行指导，到项目执行阶段开始后，情况往往千变万化，而有效的数据发布，则有助于管理层进行
合理的决策。而数据本身是说明问题的有效依据，对执行过程中的数据揭露发布，是指导执行质量的重要
手段。

      同时，跨系统重大项目，最棘手的是跨组织的沟通协调问题，平级的沟通往往无法突破坚厚的部门壁
垒，这时中立第三方的介入，则往往可以起到好的解决效果，这也是测试中心成立的意义所在，亦是这个
岗位本身的灵魂职责。

(4)、测试数据岗

      负责整体测试环境生产数据备份，各个项目组基础数据准备工作。这个岗位多余很多有多年测试工作
经验的行内人员也都很陌生，有些人即使知道有数据准备工作的，但也会纳闷为何要将这个岗位独立出来，
从笔者多年银行测试工作经验来说，深刻领悟到了该岗位至关重要。组织的发展壮大的过程，就是不断的
抽取公共的事项，然后专人做专事，以加快整体的工作效率，在银行等金融软件测试来说，数据准备工作
是一项十分耗时同时也十分专业的事项。

      银行软件测试中所使用的测试数据一般分为两种：现有数据、新建数据。对于因为银行业务异常复杂，
需要的数据种类也十分的庞杂，拿电票系统为例，票据有一百多种票据状态，而每种状态都会有不同的业
务逻辑处理，也即是每个票据状态都需要进行测试，有些状态是初始状态，有些是初始态通过大量的交易
后，演变成的状态，为了开展大规模测试，则使用生产上的数据最为这种复杂数据的输入源头是比较好的
选择，但银行业对于用户的隐私保护要求异常苛刻，所以如果使用生产数据，则必须要对生产上客户的姓
名、身份证、密码等信息进行严格的数据脱敏，而脱敏工作本身也需要多个组件进行协同配合进行，那该
项工作由谁进行组织落实比较合适呢？答案是测试数据岗。

      同样针对新建数据，很多项目组对于基础数据的需求存在很大的共性，例如客户信息、基础账号等，
这样作为测试中心，则需要在各个项目测试准备阶段，收集测试基础数据需求，统一批量进行数据新建准
备，并按需进行分配，由各项目组负责这些基础数据的生命周期，而各项目特色数据，则需要由各项目自
行准备。

    该岗位的独立，可以大幅提升测试准备阶段的效率，保证了测试的顺利进行。

4.1.2、测试环境团队

      测试环境团队是测试中心中必不可少的一员，要负责整体测试环境的搭建、与分配，测试版本的安装
与安装测试等等。

4.1.1.1 职责

环境团队的职责包括：

l  全行测试环境的建立、集中统一分配、调整、管理（包括建立几套全流程测试环境）

l  统一测试终端、外设、特殊设备的维护及参与采购

l  开发测试云平台的开发与维护

l  测试版本安装部署与上线推送

l  负责外系统独立配套支持环境的搭建与维护

l  负责全行测试环境版本稳定性考核标准制定与考核执行

4.1.1.2 关键岗位：

(1)、环境分析与设计岗

      基础开发测试环境的整体设计，包括全流程测试环境、专项测试环境和孤岛环境、网络设计、测试机
器虚拟方案、云平台建设等。

(2)、环境维护与支持岗

      基础开发测试环境的维护、版本的更新、测试设备的管理、测试环境的考核。

4.1.3、功能测试团队

      该团队主要负责重大系统的测试实施工作，全公司功能测试规范的制定工作，以及重要系统的测试管
理工作。该团队的设置要根据公司的实际情况酌情考虑，如果运行不好或时机不对，则往往会成为众矢之
的，也会成为专业的背锅侠。

4.1.1.1 职责

该团队职责如下：

l  下发全行测试规范、工具、方法、指南

l  负责全行功能测试的质量考核标准制定与考核执行

l  负责重点项目的测试实施执行工作

l  负责重点版本线的专项测试

l  负责功能测试方法（自动化测试）、工具研究

4.1.1.2 关键岗位：

(1)、测试管理岗

      承担项目级别的测试任务管理工作，主要负责测试项目的进度、风险，对整个测试质量负责。

(2)、测试分析设计岗

      承担项目级别的测试方案编制、其他项目方案评审、测试案例设计方法培训。

(3)、自动化测试岗

      负责自动化测试方法研究与落实推进，组织自动化脚本编制与维护更新。

(4)、测试实施岗

      负责测试案例执行工作，测试缺陷提出与跟踪复测，测试自动化脚本编制与维护，个性化测试数据
准备。

4.1.1.3 功能测试之殇：

(1)、核心价值体现

      在软件行业，很多从业者都将软件技术作为衡量一个软件人自身价值的标准，所用技术越难越新潮，
则往往会被认为价值越大，在这种价值评价体系下，功能测试人员往往被认为是只会在界面上点来点去，
然后跟开发人员找茬的弱鸡，十分的不受待见，久而久之也会影响功能测试从业人员自身的价值观，认
为自身没有核心竞争力，可有可无。

      这种唯技术论的观念一般都是不通的技术人员，沉浸在自己的技术海洋里，一般都没有走向管理岗位，
当你干过多个岗位，亲自管理百人团队的时候，就会发现，一切工作的核心价值都是人，一切问题的核
心要素都是人，另外，地球离谁都转，没有任何人是不可替代的，如果出现了这样的人，只能说这个组织
出现了问题。

(2)、权责与能力悖论

      权责不相等的情况在大部分企业中都会出现，而功能测试往往执行测试案例量十分庞大，执行过程中
出现的相关方也会特别多，在测试进度比较紧张状况下，各种层面的领导都会不断的督促测试尽快开展，
殊不知开发尚未开发完成，就直接推到测试，这种情况测试进度想要保证是不可能的，但是领导尝尝不了
解底层的情况，也有可能底层故意忽悠，结果往往导致大领导要求功能测试领导牵头搞定所有问题，包括
需求问题、开发问题等等，然而测试又有什么权利和责任能去管理需求和开发呢？一个闪亮的背锅侠形象
冉冉升起。

听海——sky

(3)、生产事故责任划分

      生产安全事故的来源多种多样，有的是因为测试没有充分，有的是第三方软件故障，有的是设备硬件
故障，有的是需求提的不合理导致，但不论出了任何种类的生产问题后，人们往往都会想到的一个原因，
就是测试不充分，没有进行完全的测试，而测试理论中已经提过，想要完全遍历的测试是不可能做到的，
当做到极大规模的覆盖时，也需要极大规模的成本支撑，这里面的成本包括时间成本和经费成本。在出现
生产事故后，要进行责任划分，这时不管是否是测试的问题，测试都会被划入其中，借此“勉励”测试人员
下次测试要充分一些。

(4)、低门槛准入

      功能测试从技术角度来看，准入门槛确实要比开发岗位要低，而日常的工作主要与业务需求有关，技术
能力体现不突出，这也导致了功能测试人员来源五花八门，导致整体从业人员技术门槛变低，笔者认为功
能测试从业人员至少应该在开发工作三年以上，要具备一定的技术思维，这样在进行测试时，能更加得心
应手。

4.1.3、非功能测试团队

      该团队主要承担了重要系统的性能任务实施工作，并通过测试的方式管理提升各项目的性能指标。

4.1.1.1 职责

该团队的职责如下：

l  下发全行测试规范、工具、方法、指南

l  负责全行功能测试的质量考核标准制定与考核执行

l  负责重点项目的测试实施执行工作

l  企业级非功能测试体系建设

4.1.1.2 关键岗位：

(1)、非功能测试管理岗

      承担项目级别的测试任务管理工作，主要负责测试项目的进度、风险，对整个测试质量负责

(2)、非功能测试分析设计岗

      承担项目级别的测试方案编制、其他项目方案评审、测试指标分析与把控

(3)、非功能测试实施岗

      负责测试案例执行工作，测试缺陷提出与跟踪复测，测试脚本编制与维护

4.2、员工素质培养

      在软件行业，曾经一直流行着鄙视链有说，按照不同纬度也划分出了编程语言鄙视链，操作系统鄙视
链等等，随时戏言，却也反映出了软件行业从事人员在各自心理对于不同工作内容的排行，而这个排行主
要是按照技术难度为依据。同样的原因，测试岗人员也经常被开发岗人员所鄙视，经常认为啥都不懂，只
会挑刺，而目前各公司测试人员的薪酬普遍要低于开发人员的薪酬也恰恰能说明这种情况。

      这种鄙视的情况十分有意思的是，也存在于其他很多行业中。例如在七十年代末、八十年代初，大陆
刚刚出现流行歌曲唱法的概念，当时这种唱法普遍被民族唱法所鄙视，原因很简单，高音低音部分不足，
技巧性不强，被戏称为“靡靡之音”，但是后来随着流行唱法技术性、技巧性越来越强，人们的观念也逐渐
改变，现在基本没有人去鄙视流行唱法了。

      对于软件行业也一样，如果我们将眼光放得长远一些，也回顾一下历史，会发现一个明显趋势，软件行
业整体的入门门槛越来越低，在最早期，一个计算机的变成人员还使用纸带打孔的方式编程，那时候使用计
算机的主要目的还都是批处理，最大限度利用计算机的计算资源，防止出现资源浪费，后来发展出汇编语言
，当时的从业者前辈们觉得那是划时代的革命，后来随着软硬件、及网络的不断发展，计算机变得越来越小
，编程语言也飞速的演化，软件行业整体的岗位分工越来越细化，如果单独从掌握计算机技术的角度来说，
现在的开发人员基本无法与我们的前辈们比，这代表时代是退步了吗？错，这恰恰说明时代在飞速的进步。
想看过美剧《西部世界》的人们，或多或少都会有个疑问，人工智能发展到那个时代真的离我们很远吗？人
类的发展目前正在成指数型发展，也许再过20年后，连软件开发工作都可以由计算机自己完成，那时候的从
业者可能做的只是如何把自然语言描述的业务，变成软件可输入的模型，或更进一步，直接对着机器描述就
好了，几分钟之后，一个软件就可以编写完成，到那个时候，开发人员还有存在的必要吗？开发岗还会鄙视
测试吗？不见得，五十步笑百步，可能真发展到那个阶段，这个行业需要的可能恰恰是测试人员了，毕竟需
要人去验收。

      对组织内部员工进行详细的职业规划与能力素质培养是组织长远发展的核心动力，对于测试团队，外界普
遍认为技术素质偏低，其中功能测试，更被很多偏见的人认为毫无技术可言，只是点点界面就完了，可能一个
中学生都会，这种外部舆论的压力，会严重打击测试人员的信心，影响组织的稳定性。故管理层应该足够的重
视。培养素质能力可以从培训、交流、轮岗等几个方面进行。

      对于培训，如果做的不够恰当，很容易流于形式，摆摆样子，要做到切合实际，不同岗位要安排匹配该
岗位的培训内容，对于性能测试，可着重安排操作系统、数据库、架构能方面的培训，已达到学以致用的目
的。对于功能测试，则可以偏重于业务一些，往业务专家方面培养，另外也要加强对于功能测试方法、功能
测试管理方面的培训，进而有的放矢的增强不同岗位的员工能力。培训事项不能一时兴起，要形成制度化，
可以提前半年排定测试计划，并充分听取员工意见，可以让员工自己提出想要培训的内容，以激发员工自身
参加培训的积极性。

      交流的内容比较广泛，包括同业交流和公司内部交流，因为员工一般情况下多数时间针对同一项目组或
相同类型项目进行测试服务，对其他领域了解不多，这种情况下公司可以组织员工进行内部跨组交流，而交
流的主题内容可以交由员工自己选择，这样给了员工以主动性，往往会起到不错的效果。而同业交流，则由
公司组织进行，主要目的是进行相互学习和借鉴。交流的形式有助于扩宽员工的视野，帮助提升能力。

      至于轮岗，则是培养员工素质的重要手段，下面独立章节进行讲解。

4.3、轮岗机制

      任何一个人在一个领域干久了，都会受到思维的约束，考虑问题的全面性多少会有偏差，另外往往“围城效
应”存在于各个行业，也存在于同一行业中的不同岗位上。而轮岗制度可以让员工尝试不同岗位的工作内容，在
轮岗结束后，可一定程度上由其自由选择岗位，这样在日常工作中则会少了很多抱怨，自身的能力也会得到显
著提高。

      轮岗人员的实际情况可以选择两种：

      (1)、新员工

        新员工刚入职时，可以公司内部组织开发、测试、运维之间进行相互轮岗，轮岗的时间以半年到一年为益，
原始处室则不允许干预轮岗员工的工作，考核权也跟随轮岗员工到所在轮岗处室，这样可以让新员工充分接触各
个岗位，对别的岗位人员所思所想也有所了解，在后续的工作中沟通可以更加顺畅。轮岗的更大好处是让员工亲
自接触各岗位后，可以感知到自己的兴趣所在，在轮岗结束后，自己选择职业发展路线，这样也会更加稳定，工
作的热情也会更高。

      (2)、团队领导

        部门利益壁垒在任何组织架构下，都会成为令管理层头疼的一个大问题，部门之间相互挖坑，相互倾轧
的情况时有发生。这种情况固然出于自身利益角度考虑，但很多时候，是由于不同部门的领导对于其他部门
的业务不熟悉所造成的，往往A部门要求B部门配合的工作，A认为十分简单，但B部门则干起来十分困难，A
理所应当的认为B是故意为之，专业挖坑。让上下游上的相关部门领导，在条件允许的情况下进行调动轮岗，
有助于其进行理解各自部门的工作内容与难处，在后续的工作中可以更好的配合，而这一层级的轮岗时间可
以控制在三个月到半年左右，不用时间太长，效果就会显现。

      在很多公司，轮岗制度根本没有，或者形同虚设，有两个原因作祟：1、部门壁垒过于强大，不想放走自
己的任何人，及时去轮岗，也会与对方部门打好招呼，换个工位不换工作内容；2、公司大领导没有足够的眼
光，在管理公司上存在得过且过的意识，每天都在救火，哪能看得那么远！

      如果要将组织做大做强，让员工有归属感，脚踏实地的轮岗制度势在必行。

4.4、工作氛围培养

      中国有句古话，叫上梁不正下梁歪，一个领导对于整个团队氛围的培养至关重要，而团队氛围则影响整个
团队的战斗力以及人员的稳定，下属员工往往会上行下效，如果团队领导不干正事儿，整天溜须拍马，运行一
段时间之后发现这个团队基本上都是这种人，如果领导本身比较务实，不喜欢虚头巴脑，则下属也都会比较务
实。物以类聚，人以群分，只有管理层维护一个基本公平、公正的工作氛围，员工才能踏实工作，奋进拼搏。

      而实际情况中，很多领导喜欢溜须拍马之徒，这也是人性的一个弱点，在年终考核上也往往给这类人很高
的评价，并就此树立典型。殊不知榜样的力量是无穷的，坏榜样的力量也同样如此，典型树立之后，基本上就
是告诉大家向榜样学习，这时还踏实干活的人，将会被视为异类，受到排挤，长此以往，没有人会把工作放在
心上，主要工作就是拍马屁了。

      另外，在互联网这行，加班其实很难避免，这个干时间久了大家也就慢慢接受了，但为数不少的领导偏偏喜
欢搞加班形式化，每天下班后，要么带头加班，要么临时过来抽查看谁没加班，没有以结果为导向，下属员工也
一到晚上就在朋友圈里炫耀加班，各种“多么充实的一天”，“公司的月亮好圆”等虚伪的文字粉墨登场，殊不知加
班的时候可能每个人都在玩手机，相互抱怨，进行骂领导的比赛。但是客观的说，虚伪加班之所以猖獗，背后有
一定的市场，如上级交代了一个不可能的任务，部门领导明知无法完成，却又不敢说半个“不”字，那么只能带头
搞虚伪加班，在任务无法完成后，跟领导诉苦，已经非常努力了等等。

      积极向上的工作环境聚拢积极向上的员工，龌龊虚伪的环境则赶走优秀的员工，如何培养良好的工作氛围，
是摆在每一个管理者面前需要仔细思考的问题。

春天的积雪

很好