沙场秋点兵 阅读(40) 评论(0)
从四代回来发布第一个版本的时候起,四代就意识到了一些严重的问题:
 
第一,测试时验证一个功能的标准是什么?为什么说一个现象是Bug?而另外一个现象是设计成这样的,不是Bug?参与测试的所有人,包括四代,都不知道是对是错。
 
第二,在最近一年日常工作中,四代已经不记得有多少次发生这些的事情了:当客户发现一个软件的使用问题后,四代找遍相关的所有人后,只有极个别的人才知道是怎么回事,并且知道这样改动的历史。
 
第三,团队新人来了如何系统了解软件的功能?如何训练才能成为软件的专家?团队如何传承软件的功能?
 
 
这些问题都在表明,对于整个团队来说,软件功能缺少一个统一的标准。这个标准不能存在于个别人的记忆中,即使是四代也不行。这个标准只能是公开的,团队中所有人都需要知道怎么获得或查阅。
 
文档,文档,谁是最精通软件的那个人?

 
实际上,上述的那些问题描述的都是在各种不同的应用场景下,如何方便获取到软件功能的问题。这个问题的答案总结起来就是一个东西 - 文档!
 
 
只有有了文档,团队的测试才会有对照的基础,这样的测试才有可信度。也只有有了文档,软件的功能才能传承下来,团队中的每个人才有一个途径去了解软件的所有使用细节。
 
敏捷流程不像传统的瀑布流程,它认为能工作的软件比文档重要,所以很多人想的有些简单,就是把繁琐的文档工作直接抛弃,这样确实敏捷了,轻松了,可是传承性没了。
 
还是一句老话,对于团队来说,有什么比传承还重要的吗?没有!所以文档必不可少!
 
 
在众多的文档中,四代经过不断的思考和筛选,最终考虑在团队流程中只加一份文档 - 测试文档。一份文档够吗?四代觉得还是得先试一下。
 
确定了这个思路,四代就把整理完整的测试文档作为一个起点,作为今年最重要的一个工作来慎重对待。虽然很多人并不这么认为,四代还是坚持了自己的意见,逐步展开了整理测试文档的工作。
 
苦逼的文档整理生活

 
四代将整理测试文档的工作分为了三步:
 
第一步,整理一份粗略的测试文档。
 
在这个阶段,四代想去整理一份粗略的文档,这个文档对软件功能的覆盖不要求有多深,但是一定要广,一定要全,这份文档将作为下个阶段文档整理的大纲。
 
第二步,整理一份最为详细的测试文档。
 
在这个阶段,四代会和团队一起基于粗略的那份文档,制定一个比较长的计划,来详细的整理和归类软件的各个功能,力求使得所有的细节都有依据可以查找。
 
 
经过这个步骤,四代希望团队中的所有人都可以深入的了解软件的一部分功能,这样不仅对于测试人员是非常好的,对于开发团队中的每个人也是非常有益的。
 
第三步,划分测试的优先级。
 
完备的测试文档非常庞大和复杂,而团队平时的测试除了集成测试外,还有一些其他只需要覆盖部分功能的测试,于是四代在接下来的整理中,把功能划分为出核心功能和辅助功能,并且把每个功能的测试点进行重要性分级。
 
把功能和测试点按重要性分级,再结合开发人员对于修改范围的跟进,这样,在一些轻量级的覆盖性测试中,能同时达到测试高效和节约成本的目的。
 
 
整理测试文档这件事本来是测试小组的本职工作,四代提出来以后,测试小组的MM们全身心的投入到这个枯燥繁杂的整理工作中,给了四代极大的帮助。想到这里,四代觉得要给并不黑的小黑,并不憨的二狗,并不暴力的美丽点个大大的赞。
 
除了测试组,四代还计划给PC团队的成员分配了一定的整理任务,就从鼬开始吧。他们也需要深入的参与到这个过程中,这是测试文档的初始化过程,也是整个团队对于软件功能的了解和记忆的过程。
 
经过这么艰辛的整理测试文档的过程,团队熟悉了软件的功能,制定了测试的标准;团队终于有了一份正式的文档,团队成员对功能有疑问的可以查阅测试文档相关的部分,新人入职后也可以照着测试文档去熟悉软件所有的功能。
 
 
测试文档有了,那其它的文档呢?四代也不知道是否需要,等着真正需要的时候再说吧。小平同志“摸着石头过河”论大概就是这种做法吧,四代觉得非常务实。
 
文档生死劫 - 更新

 
对于团队文档,历来都有一个严重的问题:更新!什么时候,由谁更新?文档和软件一样,僵化了就会面临死亡。所以完成一个文档仅仅是完成了文档工作的第一步,接下来文档的维护工作才是更重要的。
 
对于这个问题,四代也考虑了很久,最后终于还是在一个时刻,突然有些想法,于是一个试运行的方案终于在四代的脑中形成了。这个方案由两个部分组成:
 
第一个部分是日常维护。
 
这一部分通常是由发现文档有问题的兄弟发起,时间是每次集成测试。
 
 
每次集成测试的过程中,当参与测试的人员发现软件功能和文档描述不符时候,需要辨别这是软件的问题还是文档过时了,软件的问题需要开Bug,文档的问题需要更新文档。发现文档问题后,测试人员需要提出问题,然后测试妹子负责核实和更新对应文档。
 
第二部分是激励式维护。
 
这一部分通常由开发的哥们完成,时间是随时。
 
开发完成一个修改的时候,其实他是最了解细节和改动的人,这个时候由他去完成文档的更新是最合适的,不过有个问题就是他不会有这个意识去做的,这当然不是什么责任心不责任心的问题。
 
为了改善这种情况,四代想到了在考评选项中加入了一项:主动的改善过时的文档。做到了这一项,可以拿到一定的激励分数,这个分数大家都懂的哈。不过,最终由于每个阶段开发任务都比较重,这一项并没有得到太多的重视和投入。
 
好吧,唯一不断维护的文档保证了软件的质量,保证了知识的传承。足够吗?四代不知道,不过软件功能上的传承性问题暂时解决了。
 
那么,下一步呢?