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

　　有了独立的质保角色之后, 是不是万事大吉了? 未必, 分工意味着一件事要分给别人去工作。让别人做事, 并且依赖别人做出的结果, 这会出现一些问题。

　　问题：既然有专人负责, 那我就不用负责了!

　　生活中一个常见的歪理是, 既然有清洁工, 那我乱扔点儿垃圾算什么, 这才是他们工作啊!

　　尽管有专人负责QA 中的测试工作, 但是保证质量仍然是所有成员的职责。软件团队中的一些人往往在有意无意中忘记这一点。最常见的现象是开发人员写好一个功能之后, 迫不及待地宣布成功, 然后希望测试人员去发现所有问题。 如果问题在发布后才被发现, 开发人员会说 – 测试人员怎么搞的， 这种bug 都没找出来!?

　　某项目的某功能有重要的改进, 这个改进经过研究员的研究， 开发人员的设计, 美工的美化, 两个开发人员的配合实现, 项目管理人员的督促, 测试人员的测试, 最后所有人都号称做好了, 上线了! 为此, 我约了某个目标用户给他做实地展示, 几天后, 大家都到齐了, 开始演示。开始进行的不错, 马上最重要的killer feature 就会出来了 … 嗳, 预想的效果怎么还没出现呢? 再试试, 还没有? 各相关人员面面相觑, 大家小声说:

　　“我不是把那个新模块给你了么?”

　　“我就是照着那个接口实现的啊…”

　　“我不是已经交给那啥… ”

　　“所有的bug 不是已经都搞定了么…”,

　　会议在尴尬中胜利结束了。

　　后来查问题的根源, 这个复杂的功能由于两个模块的接口在最后没有同步, 某重要的参数被忽略了, 这个功能中最出彩的部分压根就不可能工作! 那负责测试的角色怎么解释 "所有测试用例通过, 同意发布" 的呢?

　　这还是开发人员引以自豪的 “杀手级功能” (killer feature), 那其它普通的功能是什么命运呢?

　　回过头来, 我们可以问:

　　· 这件事真的要通过这么多环节么?

　　· 测试人员真的知道最最关键的地方如何测试么?

　　· 在系统上线之后, 所有为这个功能感到自豪的人是否去实地测试过呢?

　　一个开发人员应该负责下面“开发功能”右边的几个圆圈呢?

　　问题: 盲目信任 “专业人士”扮演的角色

　　每个角色的水平不一样, 软件的质量往往受最差的角色的影响最大。我们团队要为某软件写一段英语介绍文字, 团队成员都是通过四六级英语考试的牛人, 可他们都很谦虚, 说要请一个专业的人士来写不可。于是求了一个专业人士 , 求了好几次(专业人士很忙的), 在上市之前才得到专业的文案, 于是, copy/paste 几次之后, 软件就向全世界发布了.

　　这个文案第一句就是热情洋溢的设问句： "have you ever think about ..." 随后还有几处非常明显的语法错误. 这个软件吸引了不少评论文章, 有旁观者说， 从介绍文字的几处典型中国式语法错误来看, 这个软件是由在中国的某分部搞出来的…

　　即使有专业人士扮演各种角色, 还得有专人独立地检查验证质量。

　　我们回头来看, 可以问两个问题:

　　· 这件事真的要专业人士来做么?

　　· 专业人士做完之后, 谁来负责测试?

　　问题: 为了自己角色而做绩效优化

　　分工之后, 每个角色为了自己的绩效而优化, 会出现局部最优, 而全局未必最优的情况。

　　我们团队的另一个wp7 的应用也要发布, 这次专业人士又出手了, 写了175 个英语单词的介绍, 极尽溢美之事, 而且找不到明显的语法问题! 这的确是一种局部最优了。 但是完全没考虑到用户在小小的手机屏幕上有多少耐心读完那么多形容词和状语从句。经过简化, 我们把它减少到 78 个词, 勉强能放进手机的两个屏幕。

　　如果要以 "产出" 来评价某个角色的绩效, 可以看看这个包装设计的视频:

　　http://v.youku.com/v_show/id_XMzQ3NTUxOTU2.html

　　我们回头来看, 可以问:

　　· 这些事真的要交给和项目无关的专业人士来做?

　　· 当我们给专业人士介绍需求的时候, 是否花了足够的时间让对方理解我们要的是什么?

　　· 专业人士做完之后, 我们要做什么样的QA? 光保证没有明显的语法错就够了?

　　很多年前, 当COBOL 还是主流商用语言之一的时候, 我曾在一个在软件团队里负责测试工作。职责之一, 是写各种测试用例, 来保证系统的代码覆盖率到达80% 以上。 做过实际项目的工程师都知道, 程序里很多语句是用来处理种种异常情况的, 这些情况大多数情况下不会发生。 但是这些语句如果没有被覆盖的话, 这个模块的覆盖率就会下降, 我就达不到80% 的目标。 所以我花了很多时间构造各种奇怪的测试数据, 把程序中的那些犄角旮旯都尽可能覆盖掉。 至于这些犄角旮旯在实际中是否会发生, 对用户的影响如何, 程序是否应该这样设计, 我都不太关心。 只要覆盖率达到 80%, 老子的活就干完了!

　　我这几年做了不少内部的技术创新项目, 和许多技术牛人, 领域专家有愉快的合作。有几个项目在演示的时候得到好评, 于是我们就想把它变成实用的工具。 这时，项目的重点从“演示酷技术”转变为 “解决实际问题”。 有时候最酷的技术未必解决了所有问题, 这时我自然就建议用其它技术去补充。 但是有些技术牛人反而不乐意了, 几经讨论， 我理解了原来有人想使用 “纯纯的”， “完全是我自己的” 技术! 至于实用不实用是次要的, 关键是要用 “我的” 技术!

　　问题: 画地为牢的分工

　　在一个长期而复杂的项目中, 我要求所有新来的成员, 包括外包公司的新成员, 在加入团队的时候, 先找到系统当前100 个数据方面的问题, 并用内部工具修复。我认为这能有效地让新人了解系统的复杂性, 弱点, 和维护的流程。 外包公司的员工很爽快地答应了, 但是我们一些专家反而有不同意见。 专家认为, 外包公司的人是来做测试用例的设计, 所以不必做其它事情, 我们期望他们一上手就能设计出高质量的测试用例，不应该给他们那些低级的手工操作任务…

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