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

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

　　我们回头来看，可以问：

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

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

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

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

　　问题：画地为牢的分工

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

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

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

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

　　问题：无明确责任的分工

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

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

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

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

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

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

　　。。。

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

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

原文转自：http://www.uml.org.cn/Test/201306061.asp