对于大部分的初级测试人员来说，有时放弃怀疑可能在工作中陷入一些被动，甚至让自己的生活有时也会搞得一团乱. 下面我从一个加班事件说起，看看我们如果应对一些突发的情况.
事情的由来是这样的,由于某种原因，一个功能只能在生产环境测试，于是测试同学自己觉得这个功能简单，就预估半天时间就可以测试完成。结果呢？由于各种配置问题，上了生产主流程都不通，然后一通检查，最后从上午一直到到晚上 10 点的时候发现需要的一个第三方账户权限设置错误，造成功能不同，然后在配置修改完了之后，再进行测试，结果弄到凌晨结束。从这个事情来看，完全从功能角度看，其实可能确实只要半天时间，但是这个功能又有很多依赖关系，而这些依赖关系确花了比实际测试更长的时间，而真正造成这些时间的问题确从来没有去怀疑过。于是班加了，结果其实还不太好，对外看来为什么会到最后才发现这些问题？为什么事前没有计划，为什么到最后主流程还不通？为什么从来没有人提出过这个里面可能的风险？
我事后分析了一下，有一点就是测试同学早早的放弃了怀疑，放弃怀疑了两个地方:
首先我想明确的一点是，怀疑不等于不相信，这个共识是需要团队达成的.
怀疑是想对事情本身的确认，而不是对开发人员的怀疑，有了这个基本共识，我觉得测试人员就应该多提问题，多怀疑，把怀疑的点变成实际放生的事实，把要做确没有做的事情落实，这样才能减少突发情况，才可以少加点班。遗憾的事，即使发生了这样的事情，大多数的测试人员还是会轻而易举的接受这样的事实，听开发人员一解释说是运营人没有告诉他账户设置，造成了此次问题，这样就过去了，我想这样的事情以后还是会发生。因为再一次的放弃了怀疑，根据发生的事情，一定程度上是可以推导将来发生的事情的，比如很明显，这么一件事情看出来:
如果测试不通过事实去怀疑一些，有了怀疑又去确认一些事情，那么处在开发环节的最下游，太多的不确定性都变成自己来承担，种种压力，种种加班就会都来；到最后没有太多人会帮到你，因为到了最后一旦出了点问题，就可能变成了大问题，就可能被老板追责了。
事情既然已经发生了，还好没有出现延期之类的事情，但是如果就这么过了，可能以后还是一样会发生这样的情况。
所以测试人员还应该把你认为出现这次情况的怀疑点提炼出来，比如：
这些问题什么时候解决呢？会解决吗？如果没有解决是不是后面我可以直接想老板反馈呢？这些都是合理的怀疑，不是去怀疑个人，而是有了事实之后，测试要去确认的点，过程是很辛苦，但是如果真能做到，那么这个测试在团队里面不会变得可有可无；你做的事情变成了对完全对发布负责，那么你有理由获得更多的信任。但是如果你就让这样的事情轻易通过，那么后面会有更多离奇事发生。
行千里路，半 900；所以如果没有把很多的事情落实，没有去怀疑去确认实际落实的情况，那么预估的时间往往都过于乐观了。过于乐观的估计，往往造成时间紧张，时间紧张又意味出现容易出错。所以不妨把事情放到台面说