当你在测试阶段最后两天，发现测试执行情况不理想，和预估的进度相差较大时，是否会焦虑到不知所措呢。
当你在上线前发现一个严重的问题，修复后需要重新执行一些验证测试及增加回归测试，此时你是否会惊慌呢。
当最后一轮测试/最后一天测试时测试环境突然出现问题，导致测试阻塞，测试进度受到影响，你是否会急躁呢。
即使前期测试准备工作都做的非常充分，测试设计和测试阶段都比较稳，也有可能会出现评估不准确或者中后期才发现重要问题的情况。因为测试执行工作毕竟是在项目的下游阶段，不稳定因素较多，临时状况也是无法避免，并且项目时间都比较匆忙，在这一阶段出现临时状况往往没有太多缓冲时间给我们。
遇到这些情况，需要及时向项目组反馈当前情况及项目风险，而不是拖延到最后一两天再处理。但是当项目不允许延期，组内也无其他测试同学支持时，我们还能怎么做呢。周围有的同学在这个时候就焦虑的不行了，越焦虑效率越低，效率越低就越焦虑，时间一分一秒的过去了，除了增加血压和心率，项目上线风险并没有任何改变。测试同学要做的不仅是提出问题，反馈风险，更重要的是提出解决方案，应对风险。越是这种情况下，越是要沉着冷静，条理清晰，结合我们的经验和业务能力去降低上线风险。
首先要做的是确定当前已知的风险：当前出现的问题是否会带来风险，以及会有什么风险。如果自己无法确定，可以找其他测试、产品或者开发同学一起评估。有的测试同学一看到实际结果和预期不一致就觉得这是风险，但是又说不出会带来的影响，以及这样的业务逻辑是否真的不合理，是否有解决方案。“风险”这个词变成了一个借口，测试同学可以不去评估不去思考这背后的逻辑，也不提出解决方案，上来就甩出一系列“风险”，这是对业务理解不够深入，没有主动思考的体现。
其次，明确功能的优先级和重要性。针对待测需求，心里要有一把称，明确哪些功能优先级高，哪些比较重要，哪些是这次可以忽略的。在时间不充裕的情况下，我们可以从优先级和重要性入手，优先确保重要的功能和场景，再一步步往外蔓延，确保上线风险在可控范围。
最后，列出待测试checklist。因为形势的变化，我们一开始设计的测试用例可能不是这么合适，这时候需要及时调整测试计划和测试用例，在时间不充足的情况下，可以直接列简单的checklist，可以快速确认测试点即可。结合前面分析的风险级别高的问题以及优先级和重要性高的功能，我们将这些梳理成可执行的checklist，然后一个个进行测试和验证。
出现临时情况不可怕，甩锅和抱怨解决不了问题。作为职场人，我们遇事还是要理性一些，不要上来就焦虑发怒，而是要分析当前问题和矛盾，以及思考作为测试我们可以如何应对。
网友评论