最近项目发展给我最大的感觉是,大家对 bug 抱有偏见。

出于项目管理与前期代码经营不足等原因,在版本发布临近之时,bug 猛增。其实 bug 多起来不是什么大问题,而且修复起来也挺快的,问题是为什么不能及早发现?直觉认为是测试在后期进行。但,提前让测试人员参与进来就能够解决问题吗?

在 bug 管理当中,是有分类的,人们对于不同种类的 bug 反应也是不一样的。例如对于一些 regression (倒退)表现得很严重。看似很合理的反应。

在某种程度上,开发的情绪是被测试牵引波动的。就像训练老鼠跑迷宫一样,电击多了就记得什么(错)路不能再走。但我怀疑这会不会导致开发会 LOST (迷失),忽略了代码中隐藏的各种信号,而依赖于测试反馈的信号。而据我观察,这种担忧不是多余,从开发修 bug 所改动的代码就可以看出。真是头痛医头,脚痛医脚,不报 bug,不修改。这里假设开发都不是应付式工作。这种对 bug 抱有偏见的状态所造成的问题,只要眼球足够多,迟早会以代码质量问题显现出来。那就是前一个现象发生的原因。

bug 不可怕,代码混乱才是问题,开发应该保持客观。显示 bug 是测试要做到事情,也是重要指标,但对于开发的,它也有指示作用,但肯定不是领头羊级的指标。开发要做的是书写良好的代码,让 bug 及早显现。不过也有一些外部因素,比如项目换血频繁,代码交接断裂,人员良莠不齐,普遍缺乏信托意识等等,都会造成累积的仅仅,仅仅是代码。

有良好的土壤,才能培育出丰厚的果实。