测试关键风险指的是在测试活动中发生的对测试进程和测试结果又重大影响的阻碍性问题和突发事件。
这一轮的转测试版本，有新的测试需求。需要所有的测试员都学会搭建一个比较复杂的测试工具。而且这个步骤是整轮测试的关键点。如果没有正确配置，整个测试进程都会停滞。
在配置方式完全正确的情况下，配置好此工具的时间需要2-3个小时。然而目前要验证工具是否配置正确的唯一方式就是执行基础测试用例，此用例执行完成下来需要花费1-2个小时。也就是说一次的配置不正确，花费的代价就是4到5个小时。一天的工作时间包括加班也就10个小时。如果两次都出现错误，一整天的时间就浪费了。而且此工具的配置还因为测试场景不同配置方式也有部分差异，所以每个测试员所需要面对的问题都会不一样。
目前手头上有的资源就是一份配置说明（不包含每个场景的细节配置），一个有过成功配置经验的老员工。下班后测试经理组织培训，叫一个有此工具配置经验的老员工给大家讲解配置步骤，要求大家必须在2天内都能上手。测试员培训完以后发现这个任务存在很大的风险，并且不可控。整个的转测试时间只有6个工作日，按照正常的版本测试周期，5天再加上每天加班3个小时，基本可以按时完成任务，突然冒出这么个复杂的东西，根本无法完成任务。因为多个场景可以同时配置，有测试员提议：找专人来负责。测试经理答曰：“找你你愿意干嘛？要是找我，我肯定不干，我付不起责任。”
碰见这问题，测试经理关注的是不可控风险对整个测试进度和测试质量的影响，测试员关注的则是对自己任务进度的影响，延时以后可能会有更多的加班，原本有10个功能点要验证，应为赶进度只验证了9个，发生漏测！
测试经理站在全局角度可以要求测试员必须在2天之内学会配置，但是真的在2天之内所有测试员都能学会吗？在转测试之前，测试经理和TSE没有对新的测试需求进行详细分析，没有评估新的测试需求包含的风险，没有详细的了解员工对新测试需求的理解和掌握程度，没有参考测试员对技能的掌握来设定任务时间。
个人认为，在以后的转测试之前，测试经理一定要详细的分析每一项新的测试需求，及时的将新需求达到每个测试员，务必要详尽的罗列此出存在的风险项，结合测试员对新需求的掌握和理解程度来确定风险的大小，再根据风险的可控性来适当的延长测试时间，并且及时的对薄弱环节进行加强培训。当风险发生以后要及时的做出评估和分析，分析风险发生的原因找出解决方案，评估风险对测试进度和质量的影响，结合实际情况确认是否需要调整测试方案。
风险发生后，测试员需要积极的面对，参与分析给出自己的意见，不能推卸责任。测试经理不能盲目的施加压力，测试员压力的大小也会直接影响到测试质量。还有一点，作为一个测试经理，必须要担负起责任，对于风险，测试员有责任，但更大的责任在于测试经理，是你没有事先没有充分分析，才导致风险发生。你付不起责任谁负责任？大家共同的在做同一件事情，测试经理在带头，大家走错路了，最大的责任肯定在测试经理。大家团结一条心才能顺利的度过各种难关，达到零漏测的目标。
本文出自seven的测试人生公众号最新内容请见作者的GitHub页：http://qaseven.github.io/
