敏捷测试指引(4)- 用面向业务的例子支援项目组

　　敏捷测试指引(4)- 用面向业务的例子支援项目组  软件测试

　　为了帮助讨论和理解，我把“敏捷项目中的测试”这一主题分解成4个区分的主题。今天，我讲一下我们怎样使用面向业务的例子来帮助和支援整个项目组的工作(不仅仅是程序员)。

　　我指望项目例子做三件事：激发程序员写出正确的代码，促进技术专家与业务专家之间的对话，帮助业务专家更快地在产品中实现可能的特性。让我们一步步来分析他们。

　　激发出正确的代码

　　这是测试标准的驱动(或例子驱动)设计从内部接口到整个产品接口的直接推导。为了添加一个新的功能特性，先用1个或多个例子来说明它应该怎样工作。然后程序员编写代码来匹配那些例子。编写和维护例子直到需要的代码都得到了。然后功能特性也就完成了(到目前为止)。

　　虽然推断是直接的，但是我们在得到细节之前还有一段路要走，在充分理解实践之前。我在下面会讲更多关于这方面的内容。

　　促进项目交流

　　把例子仍过墙给程序员并期待他写出正确的代码与仍给他需求文档一样是行不通的。程序员需要上下文、背景和关于默认惯例的一些知识。他们通过与业务专家交流得到那些东西。例子可以改善交流，通过提供一些东西给大家讨论。它们把讨论具体化。

　　例子可以提供显著帮助的地方，我想，是得出一个公共的词汇表。我喜欢这个想法：领域方面的术语应该通过转化到代码中的对象来使其“具体化”。不是幼稚地按“写出业务领域并在名词下面划横线”的面向对象的设计方式，而是用Eric Evans的领域驱动设计(Domain-Driven Design)的更完善的方式

　　因此我们必须有一个对领域知识的理解从模糊到具体的过程，转化到0和1的过程。看起来例子是一个中间步骤，逐渐让知识不模糊的过程。但是，使用例子来指引程序员，还有很多需要学习和研究。

　　让可能发生的更加明显

　　我们希望业务专家在他们意识到产品通过A的方式做了B，通过X的方式做了Y，因此有必要做一些新的Z，这些他们以前没有想到的事情的时候，发出“啊哈!”的声音。我们也同样希望项目组的其他人有类似的表现，这样他们可以向业务专家提议一些东西。简而言之，我们需要创造力。

　　可能最佳的释放创造力的方式是让你亲手编写软件并测试。但是另外一种方式是解释例子给其他人听。是否曾经在找bug方面存在困难，然后在开始解释你的代码给别人听的时候蹦出很多错误?对于我来说，在写用户文档的时候也会有类似的效果：我使用例子来解释软件背后的基本概念，它们是如何组合在一起工作的。我会经常发现它们不工作。与碰到bug的感觉是一样的，虽然我要解释的可能不是一个真正坐在我前面的人，而是一个假想的读者。

　　因此，我们创建例子和讨论例子的方式可能会加速产品的进展。

　　我下一年专注的几个研究方向中的其中一个就是面向业务的例子。我已经准备好了$15000用于调查能很好地使用它们的机构。如果你知道有这样的机构，请联系我。在调查了他们之后，我希望能讲关于下面的一些故事：

　　1、 关于例子的进度的故事。什么时候创建它们?在程序员开始编码之前创建了多少例子?什么例子最先创建?

　　2、 关于人们围绕例子的交流的故事。谁参与了?交流的形式是怎样的?谁把例子写下来?业务专家来写的时候是怎样的?程序员来写呢?测试人员呢?(当不同的人之间切换时人们注意到什么了?)在把例子转换到代码的过程中例子变化的情况是怎样的?

　　3、 关于面向业务的例子和面向技术的例子(单元测试)之间的交互的故事。程序员在什么时候、怎样把注意力从一个转到另外一个的?面向顾客的例子是否经常检查?例子是否会从一个分类转到另外一个分类?

　　4、 关于面向业务的例子影响设计和代码结构的故事

　　5、 关于FIT的故事。对于什么样的系统最合适?FIT最好的一个特性之一是它鼓励把说明性的文字环绕着例子 – 大家怎么利用它呢?当人们从其他方法(用脚本语言编写例子)转移到FIT的时候，学到了什么东西?而转向其他方向的人们学到了什么?当开发一个项目的词汇表的时候FIT和脚本语言比较起来会怎样?

　　6、 关于推动代码的例子(“...这里是功能X的另外一个重要的方面”)和排除bug的例子(“…不要忘记产品要在这种情况下工作”)之间的平衡的故事。怎样的bug需要预防，怎样的bug应该留给产品批判的阶段(矩阵表的另外一半)?(参见Bill Wake的"generative" and "elaborative" tests。)

　　7、 关于检查性例子与变化检测者之间的区别的故事。在面向业务和面向技术方面是否存在不同。

　　只有当我们把这些故事都收集起来之后，关于面向业务的例子的实践才能被很好地理解，才能成为惯例，就像面向技术的例子的实践一样。

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