银行测试转型 - 延伸测试边界，银行测试团队转型建议

分享到社交媒体：

ps：圆明园万花阵（图片来自网络）

银行的传统测试团队很容易陷入一种困境，就像困在迷宫中的游人，走得筋疲力尽却陷在死胡同里，迷路出不来。

本文就此话题进行简单的分析，并给出我对银行测试团队的建议。

01 银行软件及其质量保障的特点

银行软件的质量要求很高。一方面，银行软件绝大部分都跟钱有关，但凡出现一个非常小的计算错误，都可能带来巨额损失，对bug的容忍度非常低，这就要求对软件功能的验证做得细致而认真。同时，银行软件要满足监管要求，合规性得有保障；此外，对于安全性、可靠性等多项非功能需求都有很高的要求。

银行软件业务规则复杂，且随着时间推移，不断有新的业务规则加入进来。要确保软件实现的业务规则的正确性，需要有足够的测试进行保障。

传统的银行基本都有独立的测试部门来承担软件质量保障的工作，测试人员的构成呈现以下两个特点：

随着科技和业务的发展，数字化时代的银行软件质量保障面临新的挑战。

银行核心系统由胖核心、瘦核心到云原生，软件质量要求不变的情况下，其质量保障工作更加复杂，涉及到的内容更加宽泛，对测试部门原来资深测试人员的技能提出了更高的要求。

业技融合已经是各大银行的变革方向，质量不再是靠测试部门来把关，而是需要在全生命周期各个角色共同承担质量保障的职责。这种质量分工、协作方式的转变，对原本主要由测试部门保障质量的方式是一种冲击。一方面，厚重的部门墙难以跨越，合作困难；另外，传统团队对质量保障形成了思维定势，测试把关质量的观念难以转变。

业技融合带来的挑战不仅是对测试技能的要求，更多的是对质量保障相关的认知和理念的冲击。

迎接新时代的挑战，银行测试人员应该延伸测试边界，利用已有优势和话语权，赋能团队的质量保障工作，协助构建银行新型质量体系。

认知决定行为，最关键，也是最难以改变的。测试人员需要突破已有认知，积极面对变革，适应新的环境，迎接新的挑战。原来以测试视角去看待软件质量保障是相对片面的，需要跳出测试，从组织级、系统性的角度去开展质量保障工作。

我之前分享过「构建测试的体系化思维」系列文章和直播，就是从认知、理念层面进行讲述，同时也结合有相应实践的介绍。

不要再坚守独立测试把关质量的原则，要明确测试部门的职责定位，测试人员要积极融入开发团队，与业务和开发进行深度沟通和协作，发挥自身优势，实现对团队的质量保障赋能。

由供应商为主体组成的测试团队，的确是能力建设的难点，但也可以从以下方面去努力：

构建能力模型和人员发展路线图。能力模型不仅适用于技能的培养，也适用于供应商人才的选拔。而发展路线图，对于相对稳定的人员提供发展方向的参考，更加有利于人员稳定性的形成。
建立知识传递文档。业务的复杂性导致业务理解需要时间，而人员的流动性与之矛盾。为了缓解这个矛盾，建立适量的文档，以帮助知识的传递，是非常有必要的。

“人们会基于其掌握的信息制定理性的决策，但由于掌握的信息有限、不完整，尤其对于系统中相隔较远或不熟悉的部分，由此导致他们的决策往往并非整体最优。”

—— 诺贝尔经济学奖获得者赫伯特.西蒙的「有限理性」

测试团队切忌被「有限理性」所迷惑，困在自己的世界里觉得质量保障工作已经做的非常好。跳出来，延伸测试边界，从全局系统性的去思考和制定质量保障的最优决策非常关键。