“吃狗粮”背后的事

我不养狗，甚至有点怕狗，但这并不妨碍我体验“吃狗粮”。其实你也可以的，如果你是一名软件开发工作者的话。因为我这里说的“吃狗粮”是指软件开发过程中，某产品或项目相关的所有人员试用自己的产品，从用户角度体验他们对该产品的感受，就像狗的主人体验他买给狗狗的狗粮是什么味道的一样。虽然这个做法始于1988年，也在诸如微软、Facebook等这样的大公司应用了许久，但在我们项目组近期还是第一次尝试这个活动。

我们这样“吃狗粮”：

1.版本已较稳定

我们选择在回归测试之后，产品上线之前这个阶段进行“吃狗粮”活动。此时，我们认为我们开发的软件基本满足用户的需求，缺陷已经不多了。我们想试试此刻看起来已经比较可口的狗粮，吃起来到底是什么滋味。活动时间为45分钟（也许太短了，但因为是第一次，我们不想整个团队耗费太多的时间在一件还没有证明其价值的事情上，所以限定了一个较短的时间）。

2.参与范围

项目组所有成员（除去休假成员）全体参加，包括了项目经理、需求分析人员、开发人员、测试人员等各个角色。测试人员也参与该活动，因为在这个阶段他们发现新缺陷的概率与其他成员相比没有太大的绝对优势。更何况，从体验的角度，测试人员对于用户的代表不容忽视，不是么？

3.缺陷报告

因为是体验，所以我们提倡除了缺陷，也欢迎提出任何疑问和建议。这三类问题都被提交到缺陷管理系统中。

因为参与人员较多，为了避免对大家自由体验时的干扰，所以我们对于可能重复报告的缺陷采用“先报告，再取消”的方式。即活动中每个人自由记录自己发现的问题（即使会和别人重复），活动后由测试人员阅读每个缺陷报告，取消掉重复的问题。

“吃狗粮”背后的事:

45分钟的“吃狗粮”活动结束后，经过统计，23人一共报告了98个缺陷、疑问、建议！这个数字的确出乎很多人的意料！我该高兴么？为这次活动如此大量的“收获”？我该担忧么？为在这个阶段还有这么多的问题？也许，数字背后的分析才能给我一个答案，也给大家一个合理的解答。

在对结果进行分析前，我想到了近期刚刚看过James Bach在Rapid Software Testing中提到的数据分析方法：假设推理(Abductive inference)。通过这个方法可以为数据找到最佳的解释。该方法的步骤为：

1.      收集数据

2.      为该数据找到几种解释

3.      针对每种解释，寻找更多或者与解释一致或者不一致的其它数据

4.      为重要的数据选择最佳的解释，或者继续寻找

这个方法提醒我需要重视第2和第3步。而以前，我往往是从第1步直接跳到第4步的。好的，让我按照这个方法来进行分析。首先，我通读一遍所有的缺陷/问题报告，确保我能够理解它们，并将它们归类到合理的(valid)和无效的(invalid)两大类。在通读的过程中，我感到有些缺陷是有共性的，如有几个似乎都提到了快速切换页面，有几个都提到了系统响应速度太慢等等。因此，我再一次逐个阅读所有的报告，将它们放到我有印象的几个聚集的分类区，因而逐步形成了一个分类视图。

对于每组分类数据，我问自己：这个数字符合我的预期么？很快，我发现了两组数据与我的预期相差甚远。它们分别是误报缺陷数（3）和与数据多样性相关的缺陷数（2）。

1.      误报缺陷数

根据平时测试团队的平均误报率约7%，我预计此次活动的误报数应该要接近甚至超过这个数字。而实际只占了约3%。这说明什么问题呢？假设推理法提醒我要“为该数据找到几种解释”。

（1）      项目组成员对于被测试的功能非常了解，

(1.a)所以很少误报

(1.b)所以对于某些存在的小问题已经形成共识，即使看到也不认为是问题了，因而没有报告

(1.c)所以对于某些问题熟视无睹，看不到这个问题，因而没有报告

(1.d)且如果被测功能是自己开发的，可能想顺手修掉，没写报告

（2）      项目组成员对于被测试的功能并不太了解，

(2.a)因此更倾向于报告那些UI上与逻辑不相关的问题，这类问题误报率本身就低

(2.b)因为报告的(2.a)类问题很多，占用了大量时间，因此没有足够时间去测试那些更为复杂的逻辑，因此误报少

(2.c)心中没有预期的行为，也就没有办法判断是否是缺陷，报告得少，所以误报的也少

针对以上每个解释，我尝试寻找更多与解释一致或者不一致的其它数据。

此次活动我们没有限制大家是试用自己开发的模块还是别人开发的模块，但从缺陷报告人和缺陷所属模块来看大家还是测试自己开发的模块居多。所以从这个数据来看，项目组成员应该对于被测试的功能非常了解。经过和某些开发人员的进一步沟通，他们反馈在自己的模块报告的问题比较少的原因是(1.b)和(1.c)。我想(1.a)应该是不需要数据就能够成立的一个合理猜想。所以只有(1.d)难以得到数据的证实，但根据平时工作的情况，相信即使有，其比例也不高。所以我认为(1.a)(1. b)(1.c)可以视为合理的解释。对于(1.b)和(1.c)，如果想改善的话，我想交叉测试是有益的。另外，对于测试人员，也需要提醒特别小心“杀虫剂”效应，避免对于长期已知的问题丧失了辨别能力。

但是，要如何解释在同一个自己熟悉的模块，测试人员误报率高于非测试人员误报率呢？不是测试人员专业性更高，应该误报率更低么？也许从一个方面来看，除非是明显的程序实现错误，开发人员误解自己程序行为的可能性较小，因而误报率较低。从另一个方面来看，在同样面对一个不确定的问题时，测试人员抱着更强烈的暴露问题的意愿，“宁可错杀一千，不可放过一个”，模棱两可时会选择先报告，而开发人员也许更多地选择先放一放。但这一点还需要找更多的非测试人员去了解是否属实。

当然，我也看到虽然大部分人体验的是自己开发的模块或者是与自己模块联系较紧密的模块，但有些人也在别人的模块报告了不少问题或者建议，符合第2种解释。在第2种解释中，因为此次活动中超过50%的有效缺陷都是UI上与逻辑不相关的问题，所以该数据支持了假设(2.a)。因为活动时间本身不长，报告缺陷又要耗费一定的时间，所以也支持假设(2.b)。根据和一些项目组成员沟通，他们认为按照平日工作中的感觉，假设(2.c)在自己和团队成员中还是成立的。这在一个侧面提醒我们平时要多做跨模块的知识分享和储备。比如，跨模块轮岗、跨模块代码走读、交叉测试、结对测试等。

2.      与数据多样性相关的缺陷数

我预计因为更多的人员参与测试，在数据选择上自然地应该有更多的多样性，所以发现数据相关缺陷的可能性应该较高。但实际结果只有2%。可能的原因有哪些呢？

（1）      数据相关的缺陷已经很少了

（2）      数据相关的缺陷不少，但没有被发现

(2.a)对于最应该能发现与数据多样性相关缺陷的需求分析人员，因为他们中的几人遇到了和环境相关的问题阻碍了测试的进程，所以没有报告出足够多的数据多样性相关的问题

(2.b)对于整个团队，尤其是此次活动中占多数的广大开发人员，可能大家对于数据的敏感度还有待提高。比如，看到一个集装箱号是否能反应到应该显示11位而非10位？

我查找了一下这个版本测试人员在内部测试时在数据多样性方面报告的缺陷比例，为21%。这个数据与这次活动的2%相差很大。因为按照ODC分析法，我相信版本的质量属性不会在短时间内自觉地发生本质改善，所以在数据多样性方面应该还有更多的缺陷有待发现。因此我倾向于相信假设(2)而非假设(1)。因为近期需求分析人员无暇再继续测试，所以没有办法证实假设(2.a)。假设(2.b)与前期内部测试的结果中数据多样性缺陷占到21%比较符合。为了改善这一情况，需求分析人员需要多提供真实业务数据作为参考。比如，需求评审时可以多尝试”Specification by Example”，而这些example不仅仅有逻辑的抽象，更是用真实的数据表达了真实的业务场景。

按照类似的思路，我和小组成员对其它各组数据背后的原因进行了各种假设和进一步的数据分析。明确了主要原因后，也制定了相应的改进计划。有了它们，我感到我更能坦然地面对这98个缺陷、问题和建议了。有了它们，我相信下一次我们的“狗粮”升级版会更好吃的！