测试项目中，如何进行风险管理

前言

在博主的公司中，测试司理除了要管理产物线的质量保障和一样平常部门事件工作外，另一项比较重要的就是测试项目全流程的管理。
本日不聊整体的测试项目流程如何开展，而是想聊一聊在同行中比较高频出现的一个字眼：风险管理。
什么是风险管理

引用百度上的表明：“风险管理是指如何在项目大概企业一个肯定有风险的情况里把风险大概造成的不良影响减至最低的管理过程。风险管理对当代企业而言十分重要。”
那么从以上的这句话去明确的话，首先风险管理实用与项目大概企业。这里的项目其实范围很广，哪怕只是一个简单的测试活动或回归测试都是可以实用于项目这个字眼的，如果联合自身公司或团队的做事风格与特点整理出一套根本的SOP并且分段规划好的话无论多小规模的测试活动都可以称之为项目。
其次，任何事情都有风险，只不过风险的大小是否在可接受的范围中。那么在一个有风险的情况中如何把风险出现后造成的负面影响减小到最低就是一个大家都需要思考的题目。
相信许多的测试同砚都听过风险管理这个概念，但现实在工作中的话大概会因为自己的职能范围或权限无法很好的掌握项目全局或测试活动的整体面貌。
以是这里才会说风险管理是测试管理层的职责地点，如果一个测试管理连根本的风险管理也没办法做到位的话，其实他的部门工作是失职的，随着时间的推移，此中产生的风险导致的结果往往会让团队承担数倍的结果与负面评价。
如何进行风险管理

首先这里有个很重要的概念，就是风险管理的焦点管理对象是什么？许多现实工作的情况中，在项目的前期操持阶段，履历不多的管理者会把产生风险的缘故原由自己纳入风险管理的范畴。
粗看下来貌似没什么题目，但博主不推荐这么做的缘故原由和项现在要确定测试范围是一个道理，如果过于在意产生的缘故原由会让管理者的关注意心发生偏移。
举个例子：测试同砚经常会碰到项目中给与测试的时长不敷或deadline无法撼动的情况，那么此时如果项目规划与资源分配的时间管理者做了两种不同的风险评估。
A：判定与分析测试时间不敷的每个缘故原由并防备，需求穿插没有收敛、功能模块逻辑复杂，研发时间延期、代码质量不足，反复冒烟、测试本领不足、测试资源不足、信息不同步等。基于以上的这些种种，如果想把缘故原由作为风险管理的对象就会让项目变得难以开展，让管理者疲于奔命不说，还会造成项目成员对于项目的信心不足、长期负面心理暗示等尴尬田地。
B：针对预测到的测试时间不足的现状进行项目风险管理，基于项现在期排期与资源分配，已知测试对于本次迭代版本的测试时间不富足。针对这种即将发生的情况，那么本次开发与测试除了进行必要的时间扩充（加班）之外，严格的提测与准入标准、有重心的确保迭代版本的焦点业务模块、及早的测试左移、以及利用现有测试用例开展不同部门之间的交叉测试都可以有用的解决测试时间不敷的情况。
其实到了这里，还是会有测试同砚不太清楚选A还是选B，我们接下来就一种国内大部门公司都有个情况在做一下阐明。
博主之前碰到过许多测试同砚都吐槽这个岗位在公司中的受到的“不公对待”，线上故障或Bug根本都会算在测试的头上，开发同砚貌似也不用承担什么责任。
其实这样的想法自己就有题目，一般来说测试在整个项目流程中自己处于最鄙俚，线上有故障或Bug的话最先进行的肯定是题目定位与修复工作，确保线上服务正常后再来进行定责与事后完善。有题目是团队的责任，不管是测试与开发的管理者亦或是开发与测试的执行者。
其实这里的处理方式和风险管理是一致的，通过风险产生的不良影响或损失来进行对应的风险管理，防备与淘汰风险出现只是此中的一种，防备的对象不是产生的缘故原由而是产生的现状，更多的是事后处理。
我们都是通过产生某种题目来找到对应的缘故原由，从而总结归纳出下一次不再犯同样类型错误的。
之前定义的“一个肯定有风险的情况里把风险大概造成的不良影响减至最低的管理过程”，就是在一次次的预测——>题目出现 ——> 解决处理 ——> 题目消散的循环中完善起来的。总而言之将大部门的精力扩散至题目发生的全部缘故原由，还是聚焦于题目产生后的现状再加之于解决完善，这里大家应该已经有了自己的答案了吧？
那么风险产生的缘故原由就不重要了吗？当然不是，每一次的项目中产生的题目各不相同，缘故原由也大相径庭。我们无需相识大概产生风险的每一个缘故原由，但当风险产生的时间缘故原由却是解决题目的终极本质。
通过一次次的总结与实践，当项目开展的前期我们可以把产生风险的大概缘故原由列出并标明会出现的阶段或时间点，有了预期和预备之后才能在最短的时间内把风险控制在可控范围内。
别的每个风险大概产生的情况与结果都需要在项现在期做好明确的阐明，哪怕不是很准确也需要做好告警，因为当风险真正出现的时间再来评估风险的影响往往会变得比较的被动，特别是线上回归阶段，测试项目的末期出现风险的成本远远要高于项现在期。
最后测试项目中的每个节点也要明确好对应的负责人、具体时间点与阶段性输出物，当出现题目的时间可以用最小的成本快进行题目快速定位与解决相应，也方便在项目竣事复盘时通过节点与输出物进行项目质量的判定与评估。
实施发起

1.当碰到项现在期一些可预见的风险时，将风险的现状、如果发生后大概产生的连带风险一并提出，方便团队对此做出评估与措施；
2.不要觉得写缘故原由像甩锅，在出现题目时先自省是功德，但如果真的是其他团队导致的风险产生也要实事求是的将题目成因表述出来，以资助整个部门提拔项目的质量与口碑；
3.“测试准入标准”是个好东西，许多公司都提倡测试推动开发，提拔整体研发质量，外貌上看测试有点“吃力不讨好”，但现实上测试团队的地位与话语权也是靠这样慢慢的提拔或巩固的，如果不“倒逼”开发提拔自身的质量意识，代码质量不佳的提测版本只会让测试更痛楚，大量的精力浪费在一些低级Bug中，更不要提风险有多大了；
4.提前预测，提前预测，提前预测，重要的事情说三遍，道理说起来都很简单，但是做到准确的提前预测是需要在平时不断的积累，每一次测试项目事后作为管理者是否能将项目的节点与输出物做好总结归纳，提炼出题目成因并通过技术与管理本领完善以防掉在同一个坑里并不是一个特别困难的课题；
5.一口吃不成一个胖子，风险管理也是不是一蹴而就的。无论你是新手还是大佬，每个公司、每个业务线、都会有自己不同的题目存在此中，团队的磨合、技术的磨合、有时甚至是情绪的磨合都是风险出现的因素。我们没有精力对应每一个大概的成因，但是可以通过一次次的有用锻炼来到达相对较好的提拔结果，不要怕出现风险，可怕的不是想不到风险何时会出现，而是风险出现后夷由不决、唯唯诺诺的心态和不思进取、悲观待事的态度。
最后，愿每一个测试管理者都能在自己的管理之路上走的更稳、更远。
最后： 下方这份完整的软件测试视频学习教程已经整理上传完成，朋友们如果需要可以自行免费领取 【包管100%免费】

这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能资助到你！

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。