作为一个测试人员，如果只是将自己的责任定位在产品交付测试之后，用户使用之前，那简直就是一个灾难。如果这么思考，那你作为测试的职业规划、个人能力成长等都注定陷在一层阴影里，被项目组其他成员牵着走。
之前也有在写的文章里提到过 -- 测试人员是一定要建立主动防御体系的，这不是一个技术问题，而是几个基于技术和流程管控的工程意识。测试人员一定要能做到对风险有预知能力，有预先防范的能力，不然处在整个项目流程的最后一环，将永远摆脱不了被左右的局面。不要管业内喊什么测试左移、测试前置巴拉巴拉一堆，其实精髓就是作为测试请你尝试管理将要出现的问题和风险。
最近团队接了一个原本不该属于测试团队的任务 UAT 组织，注意是 UAT 组织不是 UAT 支持。关于 UAT，我先强行科普一轮。
UAT（用户验收测试），英文 User Acceptance Test 的简写，也就是用户验收测试，或用户可接受测试，系统开发生命周期方法论的一个阶段，这时相关的用户或独立测试人员根据测试计划和结果对系统进行测试和接收。它让系统用户决定是否接收系统。它是一项确定产品是否能够满足合同或用户所规定需求的测试。这是管理性和防御性控制。
进行 UAT 的产品理论上来说，必须已经全部开发、测试完毕，代码状态处于冻结状态， 所有测试出来的 bug 都已经被妥善处理，重大的 bug 都被解决，并验证通过。 对于一些低级别 bug ，要么决定被写入发布公告中，要么被设置为不需要修改的问题。 在实际项目操作过程中，由于计划进度原因达不到理论状态前提，故此，UAT 的效果也达不到应有的效果。
按照经验，通常 UAT 的组织是由项目经理和产品经理做组织的，至少我在大平安之前的几家公司是这么组织的。项目经理和产品更容易从项目进展和产品交付的角度做好把控，过程中可以请项目专家，测试经理，或专门的测试，开发等顾问对测试步骤进行补充。
当然了当前现实中，抛给了测试团队几个难题：
作为团队的测试总监，确实我开始是不想接手这件事儿的，因为在我看来确实不合常理。不管是出于行业惯例、还是人员能力等方面，我都觉得将这个事情布置给测试团队是不合理的。不过我最终还是考虑之后接手了这个事情，我的出发点是总成本：几个难题里面第一个对我们的影响最大，对方不懂如何做测试（对方甚至根本就不是有业务背景的业务 or 测试人员），我们每次都需要花大量的时间给不同的合作方做测试标准的讲解，做测试范围的沟通，做 UAT 计划的 review，甚至是我们驻场给对方做 UAT 执行（是的你没听过，这典型的就是我是一个球员的同时还得比我去当裁判，我在禁区绊倒别人，裁判还得过来说你是不是把哨子吹一下，看算不算假摔算不算点球）。然后由于过程中项目经理又各种卡时间，导致我们支持 UAT 总是很吃力。所以算一下总成本，既然主要的工作目前都是我们在抗，项目经理和产品经理又做不好把控（这种做不好把控客观上讲是他们并不知道测试实施的难点在哪里，自然也无法站在测试的立场上看问题），那这件事从设计到规划到实施到进展控制都我们来做，反倒可以通过降低沟通成本而让我们的总投入下降。另外除此之外，作为测试成员尝试接入全程，提前规避验收测试风险对团队和单兵能力提升都有很大的帮助。
撇开纠结『是否行业里 UAT 应该己方测试人员来做组织的传统和惯例』-- 这个问题，对提升测试的全流程把控能力，个人认为还是有很大帮助的。所以，如果先不纠结责任归属，不就是组织个 UAT 么，有什么好怕的，撸起袖子干。
再来科普一轮什么是墨菲定律，“墨菲定律” 是一种心理学效应，是由爱德华·墨菲]（Edward A. Murphy）提出的。
主要内容：
在一次记者招待会上，斯塔普将其称为 “墨菲法则”，并以极为简洁的方式作了重新表述：凡事可能出岔子，就一定会出岔子。
墨菲法则在技术界不胫而走，因为它道出了一个铁的事实：技术风险能够由可能性变为突发性的事实。 几个月后这一 “墨菲定理” 被广泛引用在与航天机械相关的领域。经过多年，这一 “定理” 逐渐进入习语范畴，其内涵被赋予无穷的创意，出现了众多的变体，其中最著名的一条也被称为 Finagle's Law（菲纳格定律），具体内容为：If anything can go wrong,it will.（会出错的，终将会出错。）这一定律被认为是对 “墨菲定理” 最好的模仿和阐述。
墨菲定律主要内容是：事情如果有变坏的可能，不管这种可能性有多小，它总会发生。
“墨菲定律”、“帕金森定理” 和 “彼德原理” 并称为二十世纪西方文化三大发现。除了墨菲定律，其他两个也很有意思，有兴趣的可以自己百度下，对你也许也有启发。另外再说下，墨菲这个人是一个军人，是一个工程师，不是专门的心理学家，更不是什么敏捷教练。顺便这么一说，是想和各位工程师共勉下，项目怎么做，项目有什么规律，是你作为工程师最有发言权的，不一定是你的老板或者那些高价请来的敏捷教练。
If anything can go wrong,it will.（会出错的，终将会出错。） 这句话真实又刺耳的摆在我们面前，那这句话是否真的诚如字面疑似，你觉得会发生的不好的问题都一定会发生？
我先说说我的理解，还有一个心理学效应叫罗森塔尔效应。大概意思是说，暗示在本质上，是人的情感和观念，会不同程度地受到别人下意识的影响。人们会不自觉地接受自己喜欢、钦佩、信任和崇拜的人的影响和暗示。而这种暗示，正是让你梦想成真的基石之一。反过来，如果你一直心里暗示自己这个会出问题，那很大概率，这个问题终归会发生。这两个效应的总结有着异曲同工的部分，如果在项目实施中，你自信满满认为问题都可以克服，并为出现的困难做好客服的准备，那最终问题多数是会被解决的；如果你开始就暗示自己这个会有问题，基于心里暗示又忽略了对潜在风险的前置处理，那问题一定会发生。这不只是是在测试领域，任何领域不管理解成是墨菲定律还是罗森塔尔效应，都有一个潜在事实 -- 我们对自认为会发生的风险，缺乏提前预估和处理的动力，我们想当然的基于历史经验认为问题既然一定会发生，我又何必在自认为不可逆的事情前面螳臂挡车。而这正是我们的问题所在。
那我们这次组织 UAT 都遇到了什么问题？下面是组织开会时，我听到的一些问题：
- 和我们合作的行方，他们自己的测试人员能力很差
- 他们连 case 都不会写
- 他们都不了解业务是什么
- 他们都无法做好验收测试的评估
- 对测试数据他们都没有任何概念，想起来了就问我们要，也不考虑我们的时间
- 行方环境总是掉链子，不停的出错
- 总是莫名其妙的要求 SIT 和 UAT 并行
听完大家的吐槽，我先默默的划了一张图，如下：
画完之后问了大家一个问题，『既然大家都知道 UAT 有很多问题，那我们开始从什么阶段防范 UAT 的问题的，或者说我们从那个阶段开始做组织，开始控场的』。我指了指立项阶段，没人举手；我指了指需求阶段，没人举手；我指了指开发阶段，还是没人举手。可以比较确认的多数人还是在 SIT 阶段而且是 SIT 的后半段才开始掌控 UAT 的实施 -- 当然这个时候不做也不行了，因为 UAT 就要开始了。
这里就可以看出这个比较大的问题了，基于经验大家都知道到 UAT 阶段会出很多问题，但是仍旧放弃在从立项到 SIT 之前对 UAT 阶段的风险做掌控，那问题到 UAT 阶段你担心的问题都一定会发生。这也就是这次 UAT 过程中的墨菲定律事件。自然而然，这也可以理解为，是由一个墨菲定律带来的 UAT 测试危机。
当然这个问题是需要举一反三被扩展的，不局限于 UAT 的组织，我们在测试过程中的很多问题都是担心发生然后就必然发生了，比如担心提测延期 -- 比如需求大、架构不问题、人力不足会有延期风险，但是我们基本上不会在前期就做控制，那提测一定是延期的。所以，在我个人看来，更准确的表述是 -- 对你担心的事情，如果你不克服悲观情绪并提前做防范，那你担心的事情都一定会发生。
诚如一些文章提到的观点 -- 墨菲定律只是将生常生活中的一些现象进行归纳的心理学方面的总结。出发点是人，所以能够解决的也是人！人通过调整自己的思想，看清事情的发展方向，便不会受自己心情的影响是终导致事情不可控。所以要先给自己定格调，测试过程中任何担心会发生的问题，都可以通过预判和防范而得以解决。
当然，任何事情总有它的前因后果，最后呈现在你眼前的只是结果的表像，甚至未到结果，只是过程中的一步。简单来说，就是不要让事情发展出乎你的意料，手足无措。对应的方法很间简单：遇到事情先了解它发生的原因，预料它发展的方向，做好当它向不利自己的方面发展时的应对。
同样是以 UAT 为例，旗下其实总结分析会有非常多的问题，归类一下有：合作方的需求同步；合作方的环境不稳定；测试数据准备不充分不完成；交付版本控制混乱；缺乏 UAT 执行的计划，合作方执行几乎乱来；合作方的人不认真撰写用例或者不会撰写用例。
有了上面的归纳总结，你就离看清看似简单的事物不远了，最起码基于对历史问题的归类总结，我们有能力做总结和分析，对之后发生的类似的问题不会手足无措。
很多事情，我们第一次去做的时候，我们要容忍自己对未知事物的认知问题导致的潜在风险，这个不可怕。事后一定多总结，多分析。让那些曾经看似简单的事物，因为总结发现的问题，而逐渐抽丝剥茧将完整的真像摆在我们面前。另外经验某种意义上也是相同的，作为一个测试，我们测试一个新业务、新项目也并非都是 0 准备去拥抱新事物，就比如做测试的分析，怎么分析用户，是否需要做各类型测试，这个是可以从其他经验借鉴的，但是有些内容比如之前一直测试非金融产品，突然测试金融产品发现安全测试成了你一个完全新接触的内容，那这类型的你可能要抱着纯粹学习的心态开始第一次。而在第一次接触之后，通过项目测试总结，问题总结，用户反馈和市场反应做总结，复杂的测试任务也会逐渐清晰，再下次也就不用担心了。
在这里需要强调下，很多做测试的同学，都不喜欢做总结，一方面是懒，一方面是没意识通过总结帮助自己做提升。如果想越来越能对项目有影响力，一定要克服懒惰培养能动意识。
作为测试，时间上有如下几方面的未知性，首先测试的难度超过了自己的预期，研发的修复能力低于预期或者许诺，赶商务活动工期整体压缩。
先说第一个问题，测试还是要讲测试经济学的，所以不可能做无穷尽的测试，在测试遇到意外需要增加工时时，首先要在源头上思考下，如何规避可能出现的意外。在整体执行过程中，是不是优先完成必须的内容，非必须的是否可以降低优先级，并在可承受的范围内适度裁剪。至于突发的测试内容（比如集成的第三方组件做了更新，突然发现需要增加适配测试工作），也是一样的思路先评估风险，看这件事重要不重要，如果重要那是否有操作范围让一些原本耗时但是风险较小的测试让步（比如 APP 前端版本修改不大，考虑直接用 monkey 随机测试代替人工回归做兼容性测试）。
所有的事情，包括测试在发生前都是有信号的。还以 UAT 为例，说我们担心对方的测试执行会有问题，那我们是否可以在 sit 前和对方沟通，让对方告诉我们他们的产品理解和测试理念。部分合作方在 UAT 开始前连人员名单都给不出来，那显然是一个 UAT 执行会出问题的大信号。如果说一开始我们做对接就发现对方没有测试执行人员，技术负责人也说不清，意识到有测试风险，还不做一些控制，那真的会出错的事情总会错。
如上图，我们一个测试项目从开始到结束是经历一连串测试事件的集合，这个过程往往环环相扣。但是在风险发生的之前，或者说和前一个事件阶段并行阶段就一定有信号放出来，放出来的时候，请不要自己这是报个风险 -- 你要知道只报风险是解决不了问题的，而我们的目的是解决问题。那此时基于历史经验，你要在风险信号曝出的时候就启动一些应急方案（如蓝色部分），让你的事件流重新回到合适的轨道上。记住这个逻辑，不是到一个关节点把你担心的事件都看一遍，这样太累，而是有一个完整的应急方案集合，在某些信号抛出的时候，触发你的应急方案。
之前也提过，先撇开技术能力，你是想做一个 executer，还是一个 tester，还是一个 QA，还是一个 QC。
如果你只是按照别人给你的计划，别人给你的方案做测试实施，那你永远都只是一个 executer，等着被机器和 AI 取代的那种
如果你能对项目有自己的分析和见解，知道如何做测试分析测试规划，那你是一个 tester，但你很容易达到职业生涯的天花板。
如果你对项目测试独立的见解，对质量有良好的意识，对质量工作展开有明确计划，那你是一个 QA，但你可能还不足以影响一个领域。
作为测试，请热爱这个行业，所有墨菲定律、罗森塔尔效应都只是我们给自己开脱的接口，尝试做到对全流程质量的把控能力，这才是你应该做的。
