[摘译] 测试与ANT方法

昨天读到一篇朋友推荐过来Brian Marick的博客，很有意思。

博客中主要说了作为一个测试咨询师如何使用ANT这个方法跳脱常规的习惯，帮助客户找到问题所在。

链接如下：
http://www.exampler.com/blog/2007/11/01/latour-1-testing-as-an-example/

如果想省点眼力可以往下看我的翻译，嘿嘿。

ANT就是 Actor Network Theory 的简称，大概也就是说“参与者网络理论”吧。是法国的哲学家/社会学家Bruno Latour 提出来的。

开始原文逐字翻译如下：

“我是一个咨询师，在一个项目中有大概一个星期了。在项目中我跟别人合作 - 结队，测试，还有其他。在这个过程中，我需要做的是发现他们没有发现的问题，给出他们没有尝试过的建议，这一切都是为了帮助他们更好的构建他们的软件。

一个艰苦的工作：这些项目很复杂，很多东西都在变动。对咨询师来说，他们很容易只看到习惯于见到的东西。更糟的是：他们看到不存在的东西，就因为他们这些东西是他们最擅长看到的。
所以，作为一个咨询师，他们需要在找到一些思维上的技巧，这样可以帮他们摆脱常规与习惯。我使用ANT作为一个诀窍。

一个实例：在敏捷项目中的测试角色

ANT群体共同做的一件事情是：把注意力放在事情本身上，看他们是如何变动的。

在70年代中后期，Bruno Latour -- 一个几乎不懂英语的而更是不懂生物化学的哲学家 -- 来到了加利福尼亚圣地亚哥的Salk Institute。他不光是几乎不懂学院里的人们都在干什么，他甚至还故意的忘记他知道的东西。那时候，他只想在学院里像一个人类学家到访一个完全陌生 和未知的部落一样一切从零开始。

正如你可以想象得到的一样，他的观察结果很奇怪。比如说，他看到在实验室里只有一个地方会定期的被放置装订好的被叫做“报纸”的东西。
（为了便于理解，我把图留下了）<o:p></o:p>

<o:p> </o:p>

在其他地方，那些被叫做技师的人们负责管理那些好像是用来在纸上做标记（划线，打点绘图，标识数字等等诸如此类）的机器，机器看上去好像很昂贵并且 结实的说。这两类纸会被送到第三个地方，就是“科学家们”的“办公室”。科学家们会把2这两类纸 -- 报纸和试验结果 -- 放到一块来做比较。在作比较的过程中与结束后，他们会写一些东西到另一批新的纸上，然后送到有“打字员”的地方，这些打字员会“把字打好”（就是格式弄得 好点），然后把他们寄到叫做“出版商”的人那里，出版商会把他们跟其他“纸”在一起装订好，再把这些“报纸”送到。。。 总之接下来还有送到更多的实验室去。<o:p></o:p>

对于Latour来说，这看上去实验室就像是一个把一堆纸变成更多堆纸的地方。<o:p></o:p>

现在Karl Popper, （这个人可能是科学界最具影响力的哲学家） 把Latour的所见描述为“附带现象”，这种附带现象不是科学所要研究的，科学所要研究的是：<o:p></o:p>

1. 一个理论家要提出理论。无独有偶，那些例子好像总是用非常棒的、早已为人所熟知的理论家。<o:p></o:p>

2. 有些人-- 或许是非常厉害的理论家，当然也可能就是别的什么人 -- 从那些理论里得到一些预言：在X情况下，这个世界可能会出现Y。<o:p></o:p>

3. 一个实际动手的人 -- 通常你是不会听过这些人的 -- 就会创造出X状况，并且观察是不是Y出现了。<o:p></o:p>

4. 如果这个Y并没发生，理论学家只好丢弃掉他/她的那个理论，从头来过。<o:p></o:p>

5. 如果Y发生了，那还不足以肯定这个理论的正确性。没有太多被确认确有其事的预言能够符合逻辑的证明一个理论是正确的。然而，如果这个理论还真是经受得住足够多的具有挑战性的测试，科学家们就可以开始在他们的工作做使用这个理论了。<o:p></o:p>

Popper同学的观点对我来说还蛮重要的。因为一些软件测试人员类很明显的在测试中使用了Popper的观点。<o:p></o:p>

1. 程序员是一个理论家，提出了一个类似“对于任何输入到文本框的X值，程序就会计算f(X)”<o:p></o:p>

2 . 测试人员把它当作一种预言。“所以程序应该计算f(X)，如果输入是叫做SQL注入的任何一种的话”<o:p></o:p>

3. 测试人员搭好环境，尝试SQL注入<o:p></o:p>

4. 如果程序不如预期那样工作，那么程序员需要回去改动他们的东西，再来试一试<o:p></o:p>

5. 如果程序通过了测试，这个并不能说明它就完全对了-- 还没有通过足够多的测试来证明它是无bug的。但是如果通过了足够多的测试，经理们就吃了定心丸：“行了，发布吧”。<o:p></o:p>

问题是，这在一个敏捷团队中的效果。有时候，我会想一个问题（大概2002年的时候），在测试人员与敏捷支持这种有很多紧张局面。两边都说了一些比较不经 大脑的话。在当时的背景下，测试人员的惯常的 “由程序员的程序里的缺陷驱动” -- 程序员的自我 -- 对于团队里的团结合作并无益处。然而团结合作灾民解团队中尤其重要。 有些人可能会说程序员需要少些自我，但我更倾向于“结合人类本身的特点，而不是跟它做对”。

科学仿佛不是一个很确切的比喻。（此外，读了Feyerabend和 Lakatos的东西以后，我还是满怀疑那些对于科学的沉溺跟一个真正的科学家是如何接受理论是不是相关）。

在某个时刻，我想起了一本比较详细的Latour的书，里面描述的Salk经历（Laboratory Life, 跟Steven Wooglar一起写的）。在把报纸越变越多的过程中，科学家们也会把“草稿”给别的科学家看。他们会凑在一起讨论那些草稿。交谈的内容可能会如下：

Morin很可能是这个东西的一个评论家，你知道她是怎么看待抗生素治疗的。如果你想通过她这关，你需要加强这方面的论据。
或者
我可以帮你搞定ＳＡＳ的那部分数据，让统计分析看上去更可靠。
或者
如果你把化验Ｘ的结果放进去，会有更多人感兴趣，我可以把我的技师借给你。<o:p></o:p>

那么结果是，其中一个人预见这个论文面世以后可能面临的问题，并且提出意见，使论文能更好的得到接受。然而，我不认为着当时我意识到了，这个方式，是Richard P. Gabriel从创造性写作协会引入设计模式协会的一个合作方式。（Writers’ Workshops and the Work of Making Things.）<o:p></o:p>

我意识到了，这个是一个把测试人员的技能使用到产品与团队团结合作的氛围的方式。所以，我开始在我的咨询工作中运用这个方法。给什么样的建议要看是什么样的团队。我可能会把测试人员放到支持产品owner这个角色里面。他们可能会帮助产 品owner更明晰和全面的了解她想要什么，然后他们就可以把她所表达的那些东西转换成更清晰的测试场景描述，程序员可以在测试驱动开发中使用。或者我会 把测试人员放到帮助程序员了解领域知识这个角色，一次一个测试。（这个会影响到你写的测试的类型，以及使用他们的顺序）。等等。<o:p></o:p>

我想这个思考的方式在敏捷世界中是非常普遍的。没有我，它可能也会这么发生。-- 我绝不是唯一一个这么想的人。这不重要:重要的是如果没有吸收Latour看问题的方式的精髓，我可能不会这么看敏捷团队合作的问题。