· 各司其职，对项目共同负责（Establish clear accountability and shared responsibility）
有些成功人士和成功的公司号称没必要有独立的测试角色 (Test), 你怎么看?
我猜想和踢足球类似， 还是那几个原因:
人太牛:
不世出的天才, 例如写书的时候发现排版软件不好用, 就自己写了一个。也没听说他为这个软件项目请了什么独立测试人员。对了, 他不读email 已经很多年，有秘书帮他处理这些事 - 这也是一种分工！
事太小:
“我写了个小类库，全部自己测试” 这当然不错。
我以前的一个优秀实习生后来一个人尝试写一些 UI 的控件, 写得很高兴的时候说了一句 “我现在软件工程的原则都不管了…”为了玩得爽, 不妨打破束缚， 诸法皆空，挺好。
但是顺水推舟, 推广到所有情况, 从而得出 "程序员就应该自己测试，独立测试不必了" 这样的普适结论, 未免有点过。
人不够:
那就自己动手多做一些事情, 也挺好。就像前面提到的, 一个人扮演多个角色，只要能入戏就行。
条件特殊:
近年来, 软件产业百舸争流, 鱼龙混杂, 在海里裸泳的弄潮儿也不少, 出现了种种类型的分工合作和开发模式。不在有些情况下(例如一窝蜂模式, 主治医师模式), 强力的dev 是可以搞定很多事情。运用之妙, 存乎一心.
引起网上讨论的两篇文章在这里:
中文翻译在:
其中打分最高的回答来自前雇员 (Evan Priestley), 他总结了Facebook 这个公司为什么貌似没有全职测试人员:
a. 全公司人员经常使用自己的软件产品! (如果你开发的软件是航天飞行某控制模块, 你怎么能经常使用呢? )
b. 使用 log 来分析问题可能出在哪里。 (我们的一些程序员写程序都没有log, 那大家看什么呢? )
c. 利用用户的反馈和实时状态分析 (比较过去一小时和上周同一时间的数据来判断是否有bug).
d. 应用开发商给Facebook 报bug. (开发商其实比较不爽, 但是 FB 有时就是无预警地修改 API, 你除了赶紧报 bug, 还能怎么着? )