1、BUG改动之后。在转測试回归之前，开发内部要自行验证。
这个是传统了。只是建议不要仅仅依赖现有的readmine系统（公司的一个BUG管理系统）。由于其内置的流程，仅仅支持一个人审核问题。这样往往不够准确，有可能回归不通过。所以建议自行用EXCEL进行跟踪，关键是进行两轮甚至多人审核，这样能够减少回归不通过的概率。
这里有2点值得总结，首先是2轮审核的流程，其次是不依赖现有的BUG管理系统。
这个是有道理的。假设没有BUG管理系统。BUG是否不跟踪了呢？所以不论什么系统仅仅是工具，起到辅助的作用，关键还是对BUG进行跟踪管理的意识
2、BUG改动之后。在DTS中填问题单处理过程，要注意规范。
这点我有些不是非常认可，由于我还没有认识到规范填写问题单的价值。只是从另外一个角度想，对于已经比較成熟的团队，可能能够不依赖这样的管理手段。
可是鉴于眼下我们开发团队还比較年轻，这些管理手段是必要的。
姑且不论规范填写问题单。给BUG管理本身能够带来多大价值，至少通过要求员工规范填写问题单。能够培养员工的运行力，这对促进团队的成熟是非常有帮助的。
团队越成熟。配合越默契，管理成本就越小。所需的管理手段就越少。
反之，当团队还不成熟。员工普遍能力较弱的时候，这些管理手段也就是必要的
3、关于转測试
測试文档，包含“版本号说明书”、“安装/升级指导书”、“測试建议”、“冒烟測试结果”、“遗留问题说明”
这些文档，涉及到转測试流程的管理。请看 測试驱动开发——我们要的不不过“质量”（转51testing）
4、版本号公布规范
版本号规范中提到一点。未经測试的版本号，不同意发出。这点非常关键。值得单独记下来。
未经測试的版本号不能公布。这个原则是非常easy的，可是能够引申
4.1、版本号A已经转測试了，測试过程中发现了一个问题，这个时候能不能用xxx.class替换掉呢？
肯定不行，所谓的版本号。应该是一个完整的包。
假设直接替换文件，那么已经不能保证包的完整性，这个替换后的版本号，就等于是一个新的未经測试的版本号。在替换之前的測试。严格来说等于是无效的。要发出去，就要又一次測一遍。
正确的做法。是把这个问题作为一个遗留问题。评估其影响，写在遗留问题列表中。
版本号还是正常发出去，这个问题能够在之后改动，合入下一个版本号进行測试。
假设问题非常严重，是版本号的严重缺陷，不能外发。那么能够添加一轮測试。回归之后再公布
4.2、版本号A转測试，測试结束之后，測试能够找开发要一个新的包，公布出去吗？
不能够，由于这个新的包。不能保证和測试的版本号全然一致，那么这个新的包。也就是一个未经測试的版本号
正确的做法，应该是把測试的版本号发出去。即：转測试时是什么版本号，測试结束之后就发什么版本号
4.3、现场发现了几个问题，开发提供的补丁仅仅有几个文件而已。能够不打标签，直接发出去吗？
不可以。所谓的版本号。除了“完整性”之外，还须要一个“可标识性”。就像数据的主键一样。可以唯一标识一个版本号。没有“可标识性”，就称不上是一个版本号。一个版本号仅仅要公布了，就存在须要定位问题、回退的可能。
假设没有打标签，当须要定位问题，或者日后须要回退的时候。就做不到了
正确的做法。是仅仅要发了版本号，就一定要在代码库上打上标签。能够是用版本号号打标签，比方b010。spc001。也能够用时间打标签，比方tag_20120719
打了标签之后。在不论什么时候，不管是要搭建现场的镜像环境，或者回滚，或者比較两个版本号的差异制作升级包。都能够做到了