`

主管一席话引发的思考

阅读更多
昨天主管召集开会,讲了一些事情,摘录其中我认为有价值的,在此记录一下:

1、BUG修改之后,在转测试回归之前,开发内部要自行验证。这个是传统了,不过主管建议不要只依赖现有的DTS系统(公司的一个BUG管理系统),因为其内置的流程,只支持一个人审核问题,这样往往不够准确,有可能回归不通过。所以主管建议自行用EXCEL进行跟踪,关键是进行两轮审核,这样可以降低回归不通过的概率。

这里有2点值得总结,首先是2轮审核的流程,其次是不依赖现有的BUG管理系统。这个是有道理的,如果别的公司没有BUG管理系统,BUG是否不跟踪了呢?所以任何系统只是工具,起到辅助的作用,关键还是对BUG进行跟踪管理的意识

2、BUG修改之后,在DTS中填问题单处理过程,要注意规范。

这点我有些不是很认可,因为我还没有认识到规范填写问题单的价值。不过从另外一个角度想,对于已经比较成熟的团队,可能可以不依赖这种管理手段。但是鉴于目前我们开发团队还比较年轻,这些管理手段是必要的。姑且不论规范填写问题单,给BUG管理本身可以带来多大价值,至少通过要求员工规范填写问题单,可以培养员工的执行力,这对促进团队的成熟是很有帮助的。

团队越成熟,配合越默契,管理成本就越小,所需的管理手段就越少。反之,当团队还不成熟,员工普遍能力较弱的时候,这些管理手段也就是必要的

3、关于转测试

主管提到了几个文档,包括“版本说明书”、“安装/升级指导书”、“测试建议”、“冒烟测试结果”、“遗留问题说明”

这些文档,涉及到转测试流程的管理,以后有空单独写一篇帖子来说明

4、版本发布规范

主管提到一点,未经测试的版本,不允许发出。这点很关键,值得单独记下来。

未经测试的版本不能发布,这个原则是很简单的,但是可以引申

4.1、版本A已经转测试了,测试过程中发现了一个问题,这个时候能不能用xxx.class替换掉呢?

肯定不行,所谓的版本,应该是一个完整的包。如果直接替换文件,那么已经不能保证包的完整性,这个替换后的版本,就等于是一个新的未经测试的版本。在替换之前的测试,严格来说等于是无效的。要发出去,就要重新测一遍。

正确的做法,是把这个问题作为一个遗留问题,评估其影响,写在遗留问题列表中。版本还是正常发出去,这个问题可以在之后修改,合入下一个版本进行测试。如果问题很严重,是版本的严重缺陷,不能外发,那么可以增加一轮测试,回归之后再发布

4.2、版本A转测试,测试结束之后,测试可以找开发要一个新的包,发布出去吗?

不可以,因为这个新的包,不能保证和测试的版本完全一致,那么这个新的包,也就是一个未经测试的版本

正确的做法,应该是把测试的版本发出去。即:转测试时是什么版本,测试结束之后就发什么版本

4.3、现场发现了几个问题,开发提供的补丁只有几个文件而已,可以不打标签,直接发出去吗?

不可以,所谓的版本,除了“完整性”之外,还需要一个“可标识性”,就像数据的主键一样,能够唯一标识一个版本。没有“可标识性”,就称不上是一个版本。一个版本只要发布了,就存在需要定位问题、回退的可能。如果没有打标签,当需要定位问题,或者日后需要回退的时候,就做不到了

正确的做法,是只要发了版本,就一定要在代码库上打上标签。可以是用版本号打标签,比如b010,spc001;也可以用时间打标签,比如tag_20120719

打了标签之后,在任何时候,无论是要搭建现场的镜像环境,或者回滚,或者比较两个版本的差异制作升级包,都可以做到了
分享到:
评论

相关推荐

Global site tag (gtag.js) - Google Analytics