软件测试 QA 的角色和分工(3)

　　理论上这都是非常有道理, 但是如果这些人如果没有亲力亲为地在这个项目中做一些具体事, 他们怎么能 “设计” 出高质量, 有实际意义的测试用例呢?

　　有时分工导致链条过长, 信息丢失。 一个开发者对自己写的程序有什么潜在问题还是很有感觉的, 有些问题可以用文字表述出来 (如果开发人员有耐心把文字写出来的话), 有些问题是一些预感… 现在都交给别人测试了, 那好, 让他们测吧, 我也懒得说了。

　　分工还可能会导致一个软件的灵魂被切碎分给各个 "角色"， 每个功能都做得很卖力, 但是整体就是不太行, 明显看出来是费了老大的劲给强行“集成”起来的。

　　问题: 无明确责任的分工

　　在我写第一本书的时候, 编辑部告诉我他们会对书稿进行初读, 二读, 三读 等流程, 每个环节要花几天时间。 作为出版界的外行, 我理解这些都是QA 的阶段, 等过了二读的时间, 我就发信去问， 负责二读的专业人士找到了什么问题了? 得到了语焉不详的回答… 一个问题都没找到? 但是从编辑部的回答来看, 二读不二读, 似乎没什么影响。 其实这本书的小问题还很多， 在出版之后, 都陆陆续续被读者报告了。

　　有时候出于种种考虑, 人们会把一些善良但是能力有限的同事安排在一些位置上, 扮演一些角色, 例如“二读”什么的。或者有些角色就是由一些人占据着, 但是大家对这个角色也没有什么明确的要求。这是许多问题的根源。

　　我们对这个角色有什么可以量化, 可以核查的责任要求?

　　我们对“一本书的质量是X”的信心是 Y, 刚开始组稿的时候, X 的取值范围非常大 (烂书… 一般 … 好书… 年度大卖 … 永恒经典)， 信心也比较低。 经过每个一个QA 环节， 我们都应该把X 的范围缩小, 把信心值 Y 提高。

　　例如: 二读之后, 找到了20 个严重问题, 100个小问题, 因此我们有更大的信心认为这本书是一本烂书 (如果不做改进的话)。

　　再入: 二读之后, 找到了 10 个小问题, 确信没有更严重的问题了。 因此我们有更大的信心认为这本书是一本好书。

　　。。。

　　把 “书” 换成 “软件”, “二读”换成 “测试”, 同样道理。

　　从上面举的例子可以看到, 分工之后, 的确会产生很多问题。 但是解决的方案是什么呢? 是取消分工, 让开发人员顺手做测试人员的事情, 顺便把项目管理, 美工, 市场推广, 客服都干了? 显然不是。

　　注意我们提到了 “角色”, 角色是有人来扮演的，如果一人扮演了“开发”的角色, 又能够来扮演“测试”的独立角色, 当然很好 。 但是条件是她要以“独立”的心态测试， 而不是想: “这代码就是我写的, 哪会有什么错…” 而草草了事。

　　那么独立的测试角色怎么才能发挥最大作用? 从上面的坏现象中, 我们不难总结出来。 其实 MSF 原则都讲到了。

　　· 充分授权和信任(Empower team members)

　　· 各司其职，对项目共同负责(Establish clear accountability and shared responsibility)

　　有些成功人士和成功的公司号称没必要有独立的测试角色 (Test), 你怎么看?

　　我猜想和踢足球类似， 还是那几个原因:

　　人太牛:

　　不世出的天才, 例如高德纳写书的时候发现排版软件不好用, 就自己写了一个。 也没听说他为这个软件项目请了什么独立测试人员。对了, 他不读email 已经很多年，有秘书帮他处理这些事 - 这也是一种分工!

　　事太小:

　　“我写了个小类库， 全部自己测试” 这当然不错。

　　我以前的一个优秀实习生后来一个人尝试写一些 UI 的控件, 写得很高兴的时候说了一句 “我现在软件工程的原则都不管了…”为了玩得爽, 不妨打破束缚， 诸法皆空，挺好。

　　但是顺水推舟, 推广到所有情况, 从而得出 "程序员就应该自己测试，独立测试不必了" 这样的普适结论, 未免有点过。

　　人不够:

　　那就自己动手多做一些事情, 也挺好。就像前面提到的, 一个人扮演多个角色，只要能入戏就行。

　　条件特殊:

　　近年来, 软件产业百舸争流, 鱼龙混杂, 在海里裸泳的弄潮儿也不少, 出现了种种类型的分工合作和开发模式。不在有些情况下(例如一窝蜂模式, 主治医师模式), 强力的dev 是可以搞定很多事情。运用之妙, 存乎一心.

　　引起网上讨论的两篇文章在这里:

　　http://sriramk.com/blog/2012/01/testing.html

　　中文翻译在: http://www.aqee.net/on-testers-and-testing/

　　http://www.quora.com/Is-it-true-that-Facebook-has-no-testers

　　其中打分最高的回答来自前雇员 (Evan Priestley), 他总结了Facebook 这个公司为什么貌似没有全职测试人员:

　　a. 全公司人员经常使用自己的软件产品! (如果你开发的软件是航天飞行某控制模块, 你怎么能经常使用呢? )

　　b. 使用 log 来分析问题可能出在哪里。 (我们的一些程序员写程序都没有log, 那大家看什么呢? )

　　c. 利用用户的反馈和实时状态分析 (比较过去一小时和上周同一时间的数据来判断是否有bug).

　　d. 应用开发商给Facebook 报bug. (开发商其实比较不爽, 但是 FB 有时就是无预警地修改 API, 你除了赶紧报 bug, 还能怎么着? )

　　e. 很多人自愿给Facebook 报bug, 这位贴主自称每月给他的前雇主报 13,000 个问题. (没错, 是每月一万三千个! )

　　f. 最后这位前雇员还加了一句: 还有一个原因是, Facebook 大体上也不需要搞出太高水平的软件。

　　当你的公司也能有 a) 到 e) 这样的文化, 流程, 开发商和给力的前员工, 而且你的软件“大体上也不要太高质量”你的确不需要什么全职测试人员!

　　微软是怎么做的呢?

　　就像 MSF 原则 讲的那样, 有分工，有合作。

原文转自：http://www.ltesting.net