本故事纯属虚构,如有雷同,纯属巧合
大毛小心翼翼的试着写了一些代码,同事们也帮忙出主意做检查,毕竟领导请吃饭的机会还是要争取的。
然而正当大毛觉得胜利在望之际,领导忽然站到他后面说:“你继续干活,不用管我。”
大毛耸耸肩,继续写代码。这次要完成的是一个单元测试,确保提交代码的质量。大毛实现了一系列行动来模拟用户的一个主要应用场景。要是这个测试通过,应该是可以提交了。
谁知道还没写完,领导就叹了一口气:“好啦,这顿饭没戏了,大家要报仇雪恨的就找大毛吧。”
“啥?”大毛差点从椅子上摔下来,“老大你太赖了,你得给我一个说法!”
同事们也围上来听,当然主要是不甘心到手的请客机会丢了,意图声援大毛。
“好啊,我问你,这个测试的目的是什么,为什么要自动化?”
“这是保证提交质量的,通过了就可以提交。自动化的原因一是短时间来执行大量测试,二是让开发人员不需要了解测试步骤也可以执行这个测试。”
“通过了就可以提交,那么不通过就不能提交是吧?”
“对啊。”
“为什么呢?”
“那还用说吗,你看这些、这些、这些步骤,不通过就是大问题了。”
“那倒数第三个步骤呢?”
“呃,这个,小问题,但是它是功能说明上列出来的主要应用场景的一个步骤啊。”
周围同事也看出来不对了,有人说:“不对吧,这个步骤出问题只影响比较次要的功能的。”
“那我是按照功能说明来做的嘛。”
“大毛啊”领导把话题引回来,“你也觉得有些步骤不通过不代表是严重问题,对吧?”
“嗯,对。”
“而且你的自动化测试的确满足了当初需要达到的目的,执行时间够短,开发人员也不需要了解测试步骤,对吧?”
“对啊,那你当初不是说我会忘记最初的目的……”
“我知道,只是你还不经意的附加了多一个目的,把功能说明上的一个主要应用场景全部实现,对吧?”
“呃,我开始没打算这么做,后来慢慢有这个想法。”
“那么原先的要求是没有大问题就可以提交,现在的结果是需要通过较次要的功能才能提交,对吧?”
“嗯,是这样的。”
“那么你就把提交代码的质量要求提高到一个地步,就是必须全部通过一个主要应用场景的各个步骤。我们可以达到这个地步,但实际上并不需要达到这个地步。”
“提高质量要求不是更好吗?”(见作者注1)
“较次要的功能如果为了准时发布或者达到商业竞争的目的,完全是可以牺牲的,也就是说有可能为实现其他更重要的功能而削掉它。那么你在每次提交都要执行的测试里面去检验这个步骤能否通过,显然没有必要,而且迫使每一个开发人员随时关注这个功能,以及为了提交成功一直照顾这个功能。”
“哦,我懂了。像阿德的代码并不涉及和依赖这个功能,但是他每次提交代码都得确保这个步骤没错,其实没有必要。”
“那认输不认输?”
“我……我要搞明白一个问题,怎样找到不重要的步骤呢?我总是下意识的按着功能说明走。”
领导拉过一个白板,在上面画了一些大写字母并且用箭头连接起来。
“你提到依赖,这很好。看看这些字母代表各个步骤或者子功能,有些步骤取决于另外一些步骤,举个例子,记事本程序的显示文本文件内容功能依赖于文本文件打开功能。我用箭头表示依赖关系,A指向B表示A依赖B;没箭头的线则表示谁先谁后没有关系。
“有些步骤是相当重要的,例如记事本程序的保存功能,写半天字没法保存,是严重的数据丢失问题。我在这些代表重要步骤的字母上画个圈。
“重要的步骤,也就是画圈的步骤,加上它们所直接和间接依赖的所有步骤,也就是从圈开始顺着箭头走遍的所有步骤。其它的步骤都是不重要的,不需要出现在保证提交质量的测试中。如果一个步骤后来被认为是重要的,可以,在这个图上面再走一次。”
“我请你吃饭好了,老大。”大毛说。
作者注:如果有开发人员明明测试通不过,还是要提交代码,这往往是开发和测试团队结下矛盾的开始。先不要激动,听听开发人员怎么说,如果是埋怨通不过的步骤,可以尝试一下依赖图的方法,并且和开发人员分享这个依赖图。因为高标准严要求,不见得是合适的。工程问题要用工程方法解决,不要用哲学方法解决。
作者注1:这个理由可是通杀四方的大道理,谁遇上它都无言以对。只是照这个逻辑,所有测试,——包括整合、性能、可靠性、压力……全部家当加起来都通过才能提交,岂不是最高的质量标准?那质量一定很好了吧?实际上,这样做的话,没人能够顺利提交,或者要花大量时间才能提交。没有做完的产品,或者没法按时做完的产品,何来质量可言?