如果你能养成一种习惯，面对精神痛苦时能够自动地反思痛苦而不是躲避痛苦，你将能够快速地学习和进化。（摘自《原则》）
我最近为一件事感到痛苦。痛苦的起源是年末统计bug数。我惊讶地发现2017年我们项目产品环境的问题有400多个。当然，想起内部我们一共报告了2400多个bug，也是觉得太多了。
“bug太多，产品环境bug太多”是我的痛苦。好吧，在写这篇文章之前我就是这么想的。但写着写着，我觉得不准确。如果产品环境bug少，那么即使内部bug多，我不会痛苦。因为这恰恰证明测试有效啊！内部bug多，说明开发内建质量不高，这虽然也是个问题，但不构成痛苦，因为至少用户感受到的团队的质量是不错的。
那么我的痛苦更准确的描述应该是“产品bug太多”。也就是虽然测试团队很努力地报告了很多bug（几乎是我们目前的极限了），但漏到产品环境的问题还是太多。这是测试团队要自己面对的现状。
突然，我意识到自己做得不足的地方了。我还没有仔细看过每个产品环境的缺陷，并将它们分类，以寻找共性和可能的改进方案。
我承认潜意识里有这样两大原因阻止了我。一是其中有大约一半的问题属于后台自动捕获的异常，里面大部分没有场景描述，难以分析。二是去年整个过程中我曾经不时地分析过一些，也作了一些小的改进，但从结果来看，似乎也没有取得很大的效果。
但想到这里，我还是觉得自己应该再仔细看看那400多个问题。然后我就去看了。然后我发现新的信息了。
1.约3/4的bug我能够分析，其中的1/3我认为有改进的可能；
2.问题最多的是多样化的数据和流程。例如，特殊的字符，超长的字符串，对小数和负数的处理。。。就聚集了一些bug。这些bug是我们能够不花什么额外代价就能更早发现的。操作流程相关的bug集中在某几个功能，这些功能的设计和代码很值得再去评审。
至此，痛苦朦胧的面目已清晰，它也不再那么吓人。精神痛苦，可以用思考和行动来治。
