分享

双路径下的银行测试风险控制策略设计

 古磨盘州人 2020-09-11

内容提要:银行软件测试是近十年兴起的一个新职业,其从业人员要求既要有丰富的软件测试专业知识,又要有精深的银行业务知识。本文首次提出双路径下的银行测试风险控制策略,即一方面要求项目经理通过流程风险控制,另一方面要求产品经理从产品属性策略进行控制,两条路径共同作用,确保银行软件测试质量风险的绝对可控。

关键词:双路径 流程风险,产品属性风险

一、问题的提出

所有从事过银行测试工作的人都知道一个道理,任何一个案例的设计和执行都只是减少生产事件发生的可能性。所有测试人都期待着测试的一个指令或者行为,直接可以对应一个安全稳定的生产结果。

多年前,笔者形容银行测试是“沉在浑水里摸鱼”,这句话包含三层意思:一是浑水的面积有多大?二是水中鱼的数量有多少?三是摸到多少数量的鱼我才能说鱼塘里面的鱼已经被摸干净了。

银行测试的进度和风险控制通常采取覆盖率和通过率两个指标。覆盖率即案例设计覆盖改造内容的面积,通过率指测试通过的案例与占全部设计案例的比例。这两个指标非常有说服力,测试覆盖率和通过率均达到100%,基本能说明测试是充分的。作为一个资深测试人员,没有人会因为指标的“双百”而心安理得,原因来自三个方面:一是因为银行测试是“沉在浑水里摸鱼”,你设计的案例范围占改造内容的比例,设计者是未知的;二是银行产品之间是强关联的,一支产品的改造有可能会触发其他分支的问题,如银行产品修改,但是产品应用的渠道没做适应性调整。再或者是,前台改造,中后台没有配套地进行改造等,都会触发相关的生产问题。三是银行产品的风险来自多个方面,有功能方面的、性能方面的、安全方面的、法律方面的、政策方面的。

测试是否可以像生产企业那样,按照特定的质量标准体系(ISO9001)或者按照某种管理方法论,如测试领域的探讨的TMMi模型,来确保测试像生产一样,测试人员只要按照某个标准执行一系列的测试程序,就能保证结果的可预期?或者说,测试人员通过实施标准的测试行为,就可以达成期望的结果?

本文率先提出,双路径下的银行测试风险控制策略,经过一年多的管理实践,测试质量和风险得到了有效控制。

二、双路径下的银行测试风险控制策略介绍

本文所说的双路径是指,测试项目经理的流程控制路径和银行产品经理的产品属性把控的两条路径。即通过项目经理的流程管理,确保项目流程管理精致细密,不发生流程风险;产品属性控制路径是从产品本身的属性考虑而涉及的风险。

横向上,项目经理要认真把控项目进程中的流程跟踪,以防流程上出现断点,出现因控制不到位而发生管理风险;纵向上,由产品经理根据产品的特殊属性,认真分析产品关联的政策、安全、监管、易用性等风险要素,在产品的改造过程中进行全流程跟踪,确保产品属性相关的风险处于可控状态。

双路径下测试风险控制模型结构。(见图1。)















 

产品属性风险控制

 

图1:双路径下测试风险控制模型结构图

为了进一步解剖问题,先以某银行的项目研发周期示意图进行说明(由于版本计划已经更新,研发周期缩短,现在里程碑变化较大,引用仅为了分析说明)。该示意图展示的是一支银行产品从立项到投产的研发全过程,产品测试工作要沿着研发过程逐步进行设计,从而实现全流程的风险控制。

      图2:某银行研发重点里程碑示意图。

测试过程就是不断发现问题和排查风险的过程,为了控制风险,测试人员会根据产品的研发周期制定不同阶段的风险控制策略。作为项目经理,会把产品的研发周期分成六个阶段:需求阶段、编码阶段、前移阶段、一体化测试阶段、验收适应性测试阶段和投产支持阶段。通常情况下,项目经理会制定阶段目标,并将阶段细分为关键活动,继而将关键活动分解为具体任务(见表1)。通过跟踪具体任务的执行情况,以及任务执行的结果,来判断是否存在风险及风险级别。

表1:测试任务分解表(局部)

项目生命周期

阶段风险

关键活动

时间段(T为交付验收及适应性测试时间点)

具体任务

需求讨论及前移阶段

需求讨论介入不充分风险

是否参与需求讨论

T-14

是否参与业务需求讨论

T-13

是否参与总体方案评审

T-13

是否参与业务需求分析说明书评审

T-12

是否参与软需评审

T-8

是否参与功能测试方案评审

需求讨论是否充分

T-14

是否整理出需求讨论的应用及功能清单,以便需求讨论时进行讨论确认

T-14

是否已对有疑义的需求进行确认,对不完善的需求进行补充                                                                     

T-14

需求讨论会议后续需确认问题是否已解决

是否输出需求讨论评审文档及意见

T-12

是否反馈需求受理意见\需求变更受理意见

T-12

输出业务需求意见建议数量>0

T-13

输出总体方案评审记录及意见建议数量>0

T-13

输出业务需求分析说明书评审记录及意见建议数量>0

T-12

输出软需评审评审记录及意见建议数量>0

T-8

输出功能测试方案评审记录及意见建议数量>0

T-14

是否输出验收标准初稿(tims)

项目经理的横向流程控制就是通过控制具体任务的阶段完成情况,确定测试的风险等级,适时与有关各方进行沟通以消除风险。而测试从方案设计到测试执行,过程仅仅证明结果的可能性,因为仅仅有流程控制是远远不够的。项目经理解决不了依附于产品本身的风险是流程,需要产品经理围绕产品本身的属性及依附于产品的属性进行设计,才能确保测试风险控制是有效的。

项目经理和产品经理分别从项目和产品维度进行风险管理,才能全方位地发现、跟踪、解决和消除风险,这就是本文需要论证的双路径下的风险控制策略。下面分别介绍双路径下的风险控制模型。

三、项目经理的流程风险控制模型

根据多年的实践,笔者将项目经理的流程风险控制归纳为“CCMDA模型”,模型可以分解为五大环节、十个步骤,具体解析如下:

1、“CCMDA模型”的五大环节。

搜集环节(C),项目经理要搜集全流程的风险点——实现风险的全流程识别,搜集各岗位的风险控制项,搜集风险展示需求。分类环节(C),一是将风险点进行归类成风险因子——实现标准化;二是任务与测试日历进行归类,实现待办任务的全流程覆盖。模型环节(M),主要从事四类设计,一是风险大类设计,二是关键行动设计,三是具体任务设计,四是输入输出比较设计。展现环节(D),风险报表按角色展现——实现可视化。资产环节(A),将过程的资料与测试日历匹配,形成过程资产。

2、项目经理风险控制的十大步骤。

根据五大环节的设计要求,风险控制在流程上对应十大步骤:一是收集各角色从T-18周开始涉及的全部风险点;二是对风险点进行类别划分,三是编制全流程的测试日历,四是编制风险识别模型,五是按照测试日历填写测试进展情况,六是系统识别风险并提示风险规避措施,七是收集各层级对风险的应对措施及结果,八是按角色展示风险信息,以便于落实不同的跟踪责任,九是设计数据之间的勾稽关系,优化数据生成策略,十是收集风险发现、跟踪、解决的策略,持续优化实现资产沉淀。

四、产品属性风险控制模型

测试风险和质量控制仅仅有流程管理是远远不够的,如某项目涉及多个产品的改造。根据流程管理,项目经理能掌控的内容是,改造点是否有对应产品线的人,各产品线参与测试人员的资质是否符合项目改造的需要,测试案例的设计范围是否满足风险要求,不同产品线涉及的政策、法律、法规及安全上的要求有哪些,这都需要产品经理参与其中。作为有经验的项目经理,他会根据项目的改造内容,要求产品经理做好属性风险的评估并配备相应资质的人员参与到风险控制活动中。

通过归纳,产品属性风险F=f(x1,x2,x3,x4,x5,......),x1,x2,x3,x4,x5分别代表以下要素:架构要素、法律要素、监管要素、安全要素、用户习惯要素等。

1、架构要素。架构要素包括技术架构(图3)和业务架构(图4),架构决定了技术策略的设计和业务流程的规划,这是功能测试、性能测试、适应性测试、验收测试的重点。

图3:某银行某应用的系统架构示意图。

图4:某银行某业务架构示意图。

项目改造涉及架构的内容,以及因为架构属性带来的对案例设计的广度和深度,需要产品经理从产品属性维度进行把握。技术架构需要考虑技术的可用性、合理性、实用性、业务对性能的影响、技术的容错能力等。业务可以按照产品的PCF架构的层级关系,分析功能改造涉及的阶段、活动、任务、步骤或者规则,以此来决定版本改造对生产的实际影响。

2、法律要素。

新产品的推出或者流程的优化,必须符合国家的法律、行业的规章及单位内部的管理制度。所谓法律要素,就是产品的设计要按照法律、法规、规章的要求,为此要求案例业务规则要符合法律、法规和规章制度的具体要求。也就是说,产品本身必须是合法合规的,不能推出违反国家法律法规的产品,如银行不能经营博弈类产品,或者不在经营范围内的产品;银行产品的业务规则必须符合国家法律的规定,如个人结售汇业务,国家外汇管理局规定,成年公民一个自然年度中,结售汇的总金额不能超过5万美元或者等值的外币额度。银行程序设计时,必须要有这样的边界值控制。

3、监管要素。

银行在某种程度上代表着国家的经济命脉,国家有关的管理部门就要根据业务范围对银行的经营活动进行监控和管理,监管部门通过系统,主要实现以下目的:一是银行经营活动的合规合法性;二是监管数据报送的全面性、及时性和准确性,三是监管数据的合理性及监管活动的相关性等等。

4、安全要素。

道高一尺,魔高一丈。银行系统自诞生之日起,一直存在着各种各有的安全的问题,从用户管理、互联网访问管理、防病毒管理,到黑客网络攻击、漏洞侵入等,时刻进行着正与邪的较量,安全测试已经成为非常重要的活动,每次版本改造和升级,犯罪分子利用自己掌握的信息从事各种各样的犯罪活动,如何设计安全案例杜绝安全问题、堵塞安全漏洞,是各大银行测试人员首要任务。

此外,还有用户习惯要素等,在互联网金融快速发展的今天,银行产品的场景化设计首要考虑的问题就是用户体验,这不仅涉及业界规范性的界面友好性和极致体验的客户化设计,因不符合用户习惯,或者不符合客户体验的设计,都有可能导致差错和安全事件发生。这都是产品经理要从产品属性维度考虑问题的根本要求。

五、结语

软件测试几乎是伴随着软件开发而诞生的一个职业,而银行软件测试不过是近十几年的事。与传统的测试行业的测试从属于开发的地位不同,银行软件测试是一个全新的专业,从事银行测试软件的人员需要的专业知识是综合的。再加上银行是特殊行业,对安全性要求极高,对事件的容错性极低,为此,银行软件测试就要求集软件测试专业知识和银行业务知识的复合型人才方可胜任。为了确保产品质量,既要有精通项目管理的人员从项目管理的维度控制流程风险,同时要有精通银行业务的产品经理从产品属性进行分析,从流程和产品属性双路径下控制风险,才能真正保障银行产品投产和运营的安全。

(该文发表于《中国金融电脑》2019年第2期)

(本期热点文章啊。)

朱晔(古磨盘州人)

安徽望江人,中国作家协会会员,中国金融作家协会理事;2008年开始文学创作,已出版专著6部,累计出版200万字

已出版作品

历史散文(3部):《理说明朝》、《理说宋朝(北宋篇)》、《理说宋朝(南宋篇)》

旅行随笔(1部):《一车一世界》

长篇小说(2部)《最后一个磨盘州人》、《银圈子》

期刊发表作品若干:涉及《文艺报》、《厦门文学》、《中外文摘》、《金融时报》等。

    转藏 分享 献花(0

    0条评论

    发表

    请遵守用户 评论公约

    类似文章 更多