posts - 193,  comments - 520,  trackbacks - 0

唐僧与 QA MM

在一个典型的项目团队里,包括了以下几种角色(帽子): PM(项目经理)、 BA(业务分析师)、 DEV(程序开发者)和 QA(质量保证人员),整个团队的目标是向客户交付价值。


那么,有一天, QA MM来找我,我是开发人员。 MM说,一张图片没有正常显示,我想知道原因,同时想知道你能否修复。我的第一想法是,这不可能,一定是环境的原因。我说,好的,稍等。接下来,我张大嘴巴看到了 MM给我重现的 BUG:本该显示图片的位置一片空白,就像此时我合不上的嘴。这怎么可能呢?我想,这个功能完成的如此之得意,以至于测试用例里的数据都是以我的名字命名的。


几分钟后,或者更长,我叫来 MM,说,找到原因了。


我打开编辑器,光标在源程序的某一行闪烁,我说,最根本的原因在这里。我看到 MM的眼中闪过一丝迷茫。接下来,我却换到另外一个源文件,光标继续闪烁,我说,这里的程序因此受到影响。看得出, MM有点发晕。终于,当我打开第 N个源文件并试图继续讲解时, MM昏过去了。


当 MM苏醒过来时,我在她清澈的双眼中看到了一只清晰的唐僧。


MM肯定感到了不好意思,因为我的讲解中包含了比喻、类推、排比等我力所能及的各种语文知识,看得出,我很努力,我的语文老师也很努力,所以她委婉地说,能不能简单一点?


我想了想,说,测试驱动时测试数据不全导致程序少考虑一种情况。


MM说,能修复吗?


我说,可以。于是故事结束。


就 是这样,当我们执行一项任务时,围绕这项任务必然会产生许许多多的信息,这些信息对于该任务的执行者是必须的,但是对于其他人则不是,有效的沟通往往来自 于简练的表达即只表达对方需要和可以理解的内容,浩瀚的细节只会将真正想表达的内容淹没。其实这里还有这样一层意思:我之所以用这么多的细节信息来淹没 QA,实际上是不太情愿承认程序里有 BUG。 QA想要的结果很简单,是否是程序 BUG,能否修复。而开发人员则往往把自己的程序与自己关联在了一起,认为程序是自己的扩展,程序有 BUG则意味着自己有缺陷。这一关系明显是矛盾的,可是一些团队里开发人员和 QA能够和平相处,而有些团队却势如水火。


那么,对于单个任务而言,需要定义自己的变量,这些变量数据只与该任务相关,只在该任务里可见。典型的工作流应用于任务执行期间的中间数据存储。在文档处理中,一个重要的功能就是需要提供版本管理,在单个任务实例里,办理者能够管理自己处理过的文档版本。

 

描述

任务能够定义变量,在一个流程实例里,该变量只能被其任务实例所使用。


图 6-2任务级别的数据可见性

如图 6-2所示,我们在任务 B上定义了一个变量 M,此时,在一个流程实例里,只有任务 B的实例才能使用该变量。

 

实现

存在两种实现方式,一种是如图 6-1所示的,在任务节点定义中声明变量,运行期初始化任务实例的同时初始化该变量并使用; 另一种是在流程定义级别统一声明变量,但是各个任务实例都独立初始化并存储该变量。第二种实现方式在各个任务都需要使用同一语义的变量时很常见,例如各个任务实例都会有参与者,我们在流程定义时声明一个名为 userid的变量,在流程实际执行时,各个任务实例都会独自保存有自己的 userid数据。



http://www.blogjava.net/ronghao 荣浩原创,转载请注明出处:)
posted on 2010-03-16 22:05 ronghao 阅读(1605) 评论(0)  编辑  收藏 所属分类: Head First Process-深入浅出流程

只有注册用户登录后才能发表评论。


网站导航:
 
<2010年3月>
28123456
78910111213
14151617181920
21222324252627
28293031123
45678910

关注工作流和企业业务流程改进。现就职于ThoughtWorks。新浪微博:http://weibo.com/ronghao100

常用链接

留言簿(37)

随笔分类

随笔档案

文章分类

文章档案

常去的网站

搜索

  •  

最新评论

阅读排行榜

评论排行榜