在尽量不影响当前项目活动的情况下，可以对测试过程作部分改进，能够支持建立项目的BUG管理过程，简述如下：
1.配置角色和权限->新建角色：测试人员
(1)主要配置问题跟踪权限
(2)提前规划好再在系统中操作，建议不要赋予角色删除权限，删除应由项目管理人员操作
2.配置跟踪标签->错误
(1)保留错误的基本属性：状态(在工作流程中可以自定义)、指派给、目标版本(如果项目有版本规划)、计划完成日期(测试人员根据任务进度预计修复完成日期，负责修复的开发人员也可以根据任务实际进度修改)
(2)自定义属性：
错误类型
- 需求错误
- 功能错误(影响了重要的特性、用户界面、产品接口、硬件结构接口和全局数据结构。并且设计文档需要正式的变更。如逻辑，指针，循环，递归，功能等缺陷)
- 接口错误(与其他组件、模块或设备驱动程序、调用参数、控制块或参数列表相互影响的缺陷)
- 用户界面错误(屏幕格式，确认用户输入，功能有效性，页面排版等方面的缺陷)
- 提示错误(提示的错误信息，不适当的数据验证等缺陷)
- 版本错误(由于配置库、变更管理或版本控制引起的错误)
- 性能错误(页面呈现时间过慢))
BUG严重等级
- 致命(致命的错误，造成系统崩溃、死机，或造成数据丢失、主要功能完全丧失、页面报错等)
- 严重(指功能模块或特性没有实现，主要功能部分丧失，次要功能全部丧失，或致命的错误声明)
- 一般(次要功能模块丧失、提示信息不够准确、用户界面显示不合理和操作时间长等)
- 细微(一些小问题如有个别错别字、文字排版不整齐等，不符合操作习惯)
3.配置工作流程->字段权限
(1)角色-开发人员、跟踪标签-错误：除"指派给"全部设为只读(配置工作流程->状态转换可以根据需要自定义，比如开发人员只能将新建置为已解决或者已关闭)
4.规范测试人员提交BUG过程
(1)主题：【XX模块】-BUG概述
(2)描述：
测试环境(后续可以根据需要自定义字段-测试环境)
前置条件，比如用户已登录
操作步骤
预期结果
实际结果
其他说明
(3)父任务：需求任务
(4)文件：BUG截图
5.相关影响：
(1)开发人员需要关注被指派的问题，并填写修复说明，开始可能会遭到部分抵触
(2)测试人员也有可能产生不适应，而且BUG后期是要与测试人员的考核(激励为主)结合起来的，不然可能出现有问题不记录，或者记录得过于简单
6.小结：
建议先对测试人员宣讲，收集反馈意见，然后在下一个周期较长的需求试行