我不养狗，甚至有点怕狗，但这并不妨碍我体验“吃狗粮”。其实你也可以的，如果你是一名软件开发工作者的话。因为我这里说的“吃狗粮”是指软件开发过程中，某产品或项目相关的所有人员试用自己的产品，从用户角度体验他们对该产品的感受，就像狗的主人体验他买给狗狗的狗粮是什么味道的一样。虽然这个做法始于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）所以对于某些存在的小问题已经形成共识，即使看到也不认为是问题了，因而没有报告