去年参与CLP客户核心业务系统测试时,客户的一个特点让我们整个团队倍感压力:无论问题大小、是否偶发,他们都要求我们彻底说清原因,他们丝毫不接受环境波动、概率事件这类模糊解释。起初我们私下觉得客户过于苛刻,对于他们的行为吐槽了一万次,但直到读完《思考,快与慢》关于回归均值与因果错觉的论述,才猛然醒悟,正是这份苛刻帮我们跳出了认知陷阱,挖出了多个深埋在代码逻辑里的隐性bug。
印象最深的是一个APP页面卡死问题。Sherry有一次在操作app终端详情的时候,出现了页面卡死的现象,她将这个问题截图并记录bug并要求开发团队解释原因。因为这个问题机器偶发性比较大,并且完全没有必现的操作过程,我们尝试过多次也未能复现。开发排查后认为是网络问题导致。我们准备闭环问题时,Sherry却提出质疑,她认为APP面对的是大量的C端客户群体,不能简单得将问题定义为网络问题。
在客户的要求下,开发团队只能调取所有测试日志,对比卡死出现时的页面特征,并经过几十次甚至上百次的重复实验,最终发现是有一个透明的页面覆盖了当前页面,导致所有的按钮都无法点击,页面卡死只是表象。
类似的场景在CLP项目中反复上演:客户拒绝让我们用快思考搪塞偶发问题,倒逼团队完成现象记录、全量日志分析、多场景复现、根因验证的完整流程。这让我深刻意识到,测试工作中,快思考的直觉判断虽能提升效率,却也容易被回归均值的偶然和因果错觉的误导带偏;而客户的严谨,本质是在帮我们激活慢思考,用理性分析拆解问题,用数据验证打破偏见。
如今再处理偶发问题,我会主动避开先归因、后验证的惯性,而是先按客户教会的方式,收集完整的场景数据、复现条件,再结合代码逻辑推演。测试工程师的核心竞争力,不仅是发现问题的能力,更是用慢思考穿透认知障碍、找到真实答案的能力。