游戏公司有各种的版本控制和软件也有流程管理软件,各种内部分享bbs,OA。
各种的各种也无法取代checklist表的重要性。
首先版本控制和内部分享bbs,OA是无法做缺陷统计的。虽然版本控制可以对应输出bug记录,但面向的是程序,是应对代码入库后自动编译。
穿插1个话题:为什么版本控制首选不用cvs,而用svn。
首先cvs和Svn支持分支(branch)和基线(tag),二者完全一致;
cvs不支持对文件的"重命名"(rename),这个对于版本的过程化管理来说是很重要的一块;
cvs虽然有乐观锁的概念,但是产业间大多实现虚拟服务,工作间已经不是都在版本控制上;
cvs不支持"移动"(move),人为的移动需要更改cvs的存储库位置;
cvs只能是c/s结构的,而svn通过连接Apache,可以用http/https进行安全访问;
继续完成上次的:
随着游戏后期的玩法优化和修补内容,依赖测试用例和常规的测试方法虽然也可以完成测试部内部的工作。
但对于与项目组快速迭代沟通部分来说,无任何帮助。还是需要一项,通过打勾,不通过标红,阻塞则为黄色的checklist(检查表)
checklist表需要由QA提出,然后发给项目组,制定修复的时间。然后根据修复的时间,调整修复项的数量。(修复的时间和修复项有变更怎么办,这个比较正常也是正确的,因为节奏是需要随时调整的,后文有提到)
检查表的用法为:
首次:包含本期[新增][调整][高需求回归],新增项部分由于出场为首次,这个也是用所有缺陷走查一次的bugview所做不到的。
第二次:首次未通过的内容+本期[新增][调整][高需求回归],以上为小里程碑的做法,不适合非单一功能线的需求。
第三次:同第二次的内容,但不能让这个雪球越滚越大,一般滚动这个快1个月了。月底在做一次总结。
关于表单的排序,可以以时间线和优先级别线来制定其中一项,为什么不能二项,试下就明白了。除非只有2条,同1天提的,才可以二项。哪部分需要用表单,应该拆分到哪张表里,按项目组来定。
好吧,让回顾下多个时期的一些buglist的设计。如果是我的同事应该就会知道是哪个期和我共事,而我用的哪种了。(其中测试执行者和测试结果,QA备注这3项是不可缺少的,如果是大公司(这里就是上面修复项变更需要关注的)权级变更推荐需要做,目标域因项目组来定,只支持单向,一个向是由项目对外接口人-非程序对于修复项,一个是测试根据项目组来调整级别。可以使用excel里的函数来帮助)
2010前~~第三方的模板不提供,一些表还是比较幼稚的,毕竟buglist不能取代缺陷报告,而二者内容混淆。
buglist1:包含元素功能模块,开发者,缺陷编号目标%,重新开启项标注,[新增][改进],无法测试记录。
buglist2: 包含元素功能模块,流水号,缺陷编号,缺陷内容,阻塞记录,无法测试记录,[新增][改进]验收。
buglist3: 包含元素功能模块,流水号,修复率,最后验收结果,新增改进,新增缺陷项,[新增][改进]验收。
buglist4:包含元素功能模块,开发者,失效测试,[新增][改进]验收,功能雷达图,无法测试记录,阻塞比例。
... ...
注意并不是功能越多越好。
http://blog.sina.com.cn/s/blog_7d83e45a0100x6nl.html