前言
在博主的公司中，测试经理除了要管理产品线的质量保障和日常部门事务工作外，另一项比较重要的就是测试项目全流程的管理。
今天不聊整体的测试项目流程如何开展，而是想聊一聊在同行中比较高频出现的一个字眼：风险管理。
什么是风险管理
引用百度上的解释：“风险管理是指如何在项目或者企业一个肯定有风险的环境里把风险可能造成的不良影响减至最低的管理过程。风险管理对现代企业而言十分重要。”
那么从以上的这句话去理解的话，首先风险管理适用与项目或者企业。这里的项目其实范围很广，哪怕只是一个简单的测试活动或回归测试都是可以适用于项目这个字眼的，如果结合自身公司或团队的做事风格与特点整理出一套基础的SOP并且分段规划好的话无论多小规模的测试活动都可以称之为项目。
其次，任何事情都有风险，只不过风险的大小是否在可接受的范围中。那么在一个有风险的环境中如何把风险出现后造成的负面影响减小到最低就是一个大家都需要思考的问题。相信很多的测试同学都听过风险管理这个概念，但实际在工作中的话可能会因为自己的职能范围或权限无法很好的掌握项目全局或测试活动的整体面貌，所以这里才会说风险管理是测试管理层的职责所在，如果一个测试管理连基本的风险管理也没办法做到位的话，其实他的部分工作是失职的，随着时间的推移，其中产生的风险导致的结果往往会让团队承担数倍的后果与负面评价。
如何进行风险管理
首先这里有个很重要的概念就是风险管理的核心管理对象是什么？很多实际工作的情况中，在项目的前期计划阶段，经验不多的管理者会把产生风险的原因本身纳入风险管理的范畴。粗看下来貌似没什么问题，但博主不推荐这么做的原因和项目前要确定测试范围是一个道理，如果过于在意产生的原因会让管理者的关注重心发生偏移。
举个栗子：测试同学经常会碰到项目中给与测试的时长不够或deadline无法撼动的情况，那么此时如果项目规划与资源分配的时候管理者做了两种不同的风险评估。
A：判断与分析测试时间不够的每个原因并预防，需求穿插没有收敛、功能模块逻辑复杂，研发时间延期、代码质量不足，反复冒烟、测试手段不足、测试资源不足、信息不同步等。基于以上的这些种种，如果想把原因作为风险管理的对象就会让项目变得难以开展，让管理者疲于奔命不说，还会造成项目成员对于项目的信心不足、长期负面心理暗示等尴尬境地。
B：针对预测到的测试时间不足的现状进行项目风险管理，基于项目前期排期与资源分配，已知测试对于本次迭代版本的测试时间不充足。针对这种即将发生的情况，那么本次开发与测试除了进行必要的时间扩充（加班）之外，严格的提测与准入标准、有重心的确保迭代版本的核心业务模块、及早的测试左移、以及利用现有测试用例开展不同部门之间的交叉测试都可以有效的解决测试时间不够的情况。
其实到了这里，还是会有测试同学不太清楚选A还是选B，我们接下来就一种国内大部分公司都有个情况在做一下说明。
博主之前遇到过很多测试同学都吐槽这个岗位在公司中的受到的“不公对待”，线上故障或Bug基本都会算在测试的头上，开发同学貌似也不用承担什么责任。其实这样的想法本身就有问题，一般来说测试在整个项目流程中本身处于最下游，线上有故障或Bug的话最先进行的一定是问题定位与修复工作，确保线上服务正常后再来进行定责与事后完善。有问题是团队的责任，不管是测试与开发的管理者亦或是开发与测试的执行者。其实这里的处理方式和风险管理是一致的，通过风险产生的不良影响或损失来进行对应的风险管理，预防与减少风险出现只是其中的一种，预防的对象不是产生的原因而是产生的现状；更多的是事后处理，我们都是通过产生某种问题来找到对应的原因，从而总结归纳出下一次不再犯同样类型错误的。之前定义的“一个肯定有风险的环境里把风险可能造成的不良影响减至最低的管理过程”，就是在一次次的预测——>问题出现 ——> 解决处理 ——> 问题消失的循环中完善起来的。总而言之将大部分的精力扩散至问题发生的所有原因，还是聚焦于问题产生后的现状再加之于解决完善，这里大家应该已经有了自己的答案了吧？
那么风险产生的原因就不重要了吗？当然不是，每一次的项目中产生的问题各不相同，原因也大相径庭。我们无需了解可能产生风险的每一个原因，但当风险产生的时候原因却是解决问题的最终本质。通过一次次的总结与实践，当项目开展的前期我们可以把产生风险的可能原因列出并标明会出现的阶段或时间点，有了预期和准备之后才能在最短的时间内把风险控制在可控范围内；另外每个风险可能产生的情况与后果都需要在项目前期做好明确的说明，哪怕不是很准确也需要做好告警，因为当风险真正出现的时候再来评估风险的影响往往会变得比较的被动，特别是线上回归阶段，测试项目的末期出现风险的成本远远要高于项目前期。最后测试项目中的每个节点也要明确好对应的负责人、具体时间点与阶段性输出物，当出现问题的时候可以用最小的成本快进行问题快速定位与解决响应，也方便在项目结束复盘时通过节点与输出物进行项目质量的判断与评估。
实施建议
1.当遇到项目前期一些可预见的风险时，将风险的现状、如果发生后可能产生的连带风险一并提出，方便团队对此做出评估与措施；
2.不要觉得写原因像甩锅，在出现问题时先自省是好事，但如果真的是其他团队导致的风险产生也要实事求是的将问题成因表述出来，以帮助整个部门提升项目的质量与口碑；
3.“测试准入标准”是个好东西，很多公司都提倡测试推动开发，提升整体研发质量，表面上看测试有点“吃力不讨好”，但实际上测试团队的地位与话语权也是靠这样慢慢的提升或巩固的，如果不“倒逼”开发提升自身的质量意识，代码质量不佳的提测版本只会让测试更痛苦，大量的精力浪费在一些低级Bug中，更不要提风险有多大了；
4.提前预测，提前预测，提前预测，重要的事情说三遍，道理说起来都很简单，但是做到准确的提前预测是需要在平时不断的积累，每一次测试项目过后作为管理者是否能将项目的节点与输出物做好总结归纳，提炼出问题成因并通过技术与管理手段完善以防掉在同一个坑里并不是一个特别困难的课题；
5.一口吃不成一个胖子，风险管理也是不是一蹴而就的。无论你是新手还是大佬，每个公司、每个业务线、都会有自己不同的问题存在其中，团队的磨合、技术的磨合、有时甚至是情绪的磨合都是风险出现的因素。我们没有精力对应每一个可能的成因，但是可以通过一次次的有效锻炼来达到相对较好的提升效果，不要怕出现风险，可怕的不是想不到风险何时会出现，而是风险出现后犹豫不决、唯唯诺诺的心态和不思进取、消极待事的态度。
最后，愿每一个测试管理者都能在自己的管理之路上走的更稳、更远。
