对于大部分的初级测试人员来说，有时放弃怀疑可能在工作中陷入一些被动，甚至让自己的生活有时也会搞得一团乱. 下面我从一个加班事件说起，看看我们如果应对一些突发的情况.

从一个加班事件说起

事情的由来是这样的,由于某种原因，一个功能只能在生产环境测试，于是测试同学自己觉得这个功能简单，就预估半天时间就可以测试完成。结果呢？由于各种配置问题，上了生产主流程都不通，然后一通检查，最后从上午一直到到晚上 10 点的时候发现需要的一个第三方账户权限设置错误，造成功能不同，然后在配置修改完了之后，再进行测试，结果弄到凌晨结束。从这个事情来看，完全从功能角度看，其实可能确实只要半天时间，但是这个功能又有很多依赖关系，而这些依赖关系确花了比实际测试更长的时间，而真正造成这些时间的问题确从来没有去怀疑过。于是班加了，结果其实还不太好，对外看来为什么会到最后才发现这些问题？为什么事前没有计划，为什么到最后主流程还不通？为什么从来没有人提出过这个里面可能的风险？

怀疑不等于不相信，怀疑是想确认

我事后分析了一下，有一点就是测试同学早早的放弃了怀疑，放弃怀疑了两个地方:

• 这些配置问题在开发过程中就会被发现？ 因为开发承诺会测试
• 这些功能很简单，就没有去深究这里面的依赖关系，这些总会有人去搞定的

首先我想明确的一点是，怀疑不等于不相信，这个共识是需要团队达成的.
怀疑是想对事情本身的确认，而不是对开发人员的怀疑，有了这个基本共识，我觉得测试人员就应该多提问题，多怀疑，把怀疑的点变成实际放生的事实，把要做确没有做的事情落实，这样才能减少突发情况，才可以少加点班。遗憾的事，即使发生了这样的事情，大多数的测试人员还是会轻而易举的接受这样的事实，听开发人员一解释说是运营人没有告诉他账户设置，造成了此次问题，这样就过去了，我想这样的事情以后还是会发生。因为再一次的放弃了怀疑，根据发生的事情，一定程度上是可以推导将来发生的事情的，比如很明显，这么一件事情看出来:

• 开发没有做任何自测，因为如果自测，那么一定可以老早就发现这个问题了
• 开发喜欢推卸了一定的责任，这个事情的关键点不是谁没有把账号告诉别人，而是为什么这样的事情到最后才发现
• 事实上做这个功能基本上没有做任何的调研，如果做了调研就一定会知道需要什么账户的，不是吗？那以后怎么做调研？
• 真的只能生产了才可以测试吗？实际情况不是多申请一个第三方账户就可以在测试环境测试了吗？如果测试了不是应该老早就发现账户配置的问题了吗？就算只有一个账户，产生的测试数据可以删除吗？

如果测试不通过事实去怀疑一些，有了怀疑又去确认一些事情，那么处在开发环节的最下游，太多的不确定性都变成自己来承担，种种压力，种种加班就会都来；到最后没有太多人会帮到你，因为到了最后一旦出了点问题，就可能变成了大问题，就可能被老板追责了。

事后还是要把怀疑的点落实

事情既然已经发生了，还好没有出现延期之类的事情，但是如果就这么过了，可能以后还是一样会发生这样的情况。
所以测试人员还应该把你认为出现这次情况的怀疑点提炼出来，比如：

• 开发你自测了？是一个人没有自测还是所有人没有自测？
• 为什么只能在生产环境测试？这个调研工作真的做的彻底了吗？
• 为什么一开始不知道会是账号的问题？为什么定位这个问题要这么就？调研工作做的彻底了吗？
• 下次调研要这么做呢？调研了什么东西，什么结论要让相关人员知道吗？
• 测试估算时间的时候，真的了解了这些功能的依赖了吗？真的知道如果才能在生产环境把功能全部跑通的所有条件了吗？

这些问题什么时候解决呢？会解决吗？如果没有解决是不是后面我可以直接想老板反馈呢？这些都是合理的怀疑，不是去怀疑个人，而是有了事实之后，测试要去确认的点，过程是很辛苦，但是如果真能做到，那么这个测试在团队里面不会变得可有可无；你做的事情变成了对完全对发布负责，那么你有理由获得更多的信任。但是如果你就让这样的事情轻易通过，那么后面会有更多离奇事发生。

行千里路，半 900

行千里路，半 900；所以如果没有把很多的事情落实，没有去怀疑去确认实际落实的情况，那么预估的时间往往都过于乐观了。过于乐观的估计，往往造成时间紧张，时间紧张又意味出现容易出错。所以不妨把事情放到台面说