bug管理系统都应该考虑什么因素

1、一般Bug管理大致流程是：

1. 测试人员提交新的Bug入库，错误状态为New。

2.  高级测试人员验证错误，如果确认是错误，分配给相应的开发人员，设置状态为Open。如果不是错误，则拒绝，设置为Declined(拒绝)状态。

3. 开发人员查询状态为Open的Bug，如果不是错误，则置状态为Declined；如果是Bug则修复并置状态为Fixed。不能解决的Bug，要留下文字说明及保持Bug为Open状态。对于不能解决和延期解决的Bug，不能由开发人员自己决定，一般要通过某种会议（评审会）通过才能认可。

4. 测试人员查询状态为Fixed的Bug，然后验证Bug是否已解决，如解决置Bug的状态为Closed，如没有解决置状态为Reopen。

2、之前负责BUG管理工作时，从BUG管理系统收到的bug表述很多都是含糊不清，只是说出现了错误，但是错误的现象是什么，提示信息是什么，怎么操作才出现的，都不清楚，这样的bug交给开发人员，只会给开发人员增加负担，因为还要再作测试，以发现更多的信息，去排除bug，或者他会到测试那边其讨论，询问详情，有时要多次反馈才能确定到底是什么问题。 

这冗长的环节和时间等待，非常浪费时间和经理，等到后来同事遇到bug往往直接找我们技术反馈、处理而绕过bug管理系统。这样做肯定会影响到技术人员的开发效率，打断其思路，是非常不好的工作习惯。

3、虽然有自己的管理系统，但是bug管理系统并不是团队每个成员经常登录的系统，这就导致遇到bug时，需要经过“找出收藏的网址→登陆→依照指标输入详情→阶段性查看最新进展”，如果遇到这个bug是用户向你反馈而后你输入到bug系统时，你还需要等几天后给出反馈。所以同事的反馈不好用、不爱用、企业花了大价钱购买的系统无疑没有起到应有的作用。

1、后来经过几次例会的研究和讨论后，领导决定直接在日事清上进行日常的BUG管理。使用日事清的优势是我们一直在日事清进行日常的工作日志管理，所以所有员工对于软件都很熟悉，操作也非常方便，通过看板按照项目、部门、时间等维度组织团队工作清单，梳理团队任务，创建团队工作计划，让团队工作可视化。建立在看板的任务会落实到人，这些任务会自动分解至团队相关成员的个人日程中去，让个人的日程和团队的工作安排打通，实时跟进。

2、这也BUG管理和日常工作管理都在一个工作系统内完成，不增加“提bug人员”、“甄别bug人员”、“处理bug人员”的使用成本；  

而且由产品助理/产品经理/测试工程师集中甄别bug并和技术人员延时沟通，杜绝其他成员直接联系技术人员询问打扰其工作；   

如果bug状态发生改变，比如“已解决”、“评论沟通”等，提bug人员会收到通知，可以实时跟进bug状态，提bug人员更可阶段性点击“bug管理”模块查看实时状态 ；  

这也就无需单独购置一套bug管理系统，直接在办公平台流畅解决，降低企业运营成本； 相比自己开发的bug管理系统，具备更优秀、顺畅的使用体验；  bug管理工作内容一目了然，降低提bug人员上手难度，增强了彼此的沟通，大大提高了Bug管理流程的效率。