bug修改流程？

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

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

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

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

错误流程管理要点 为了保证错误的正确性，需要有丰富测试经验的测试人员验证发现的错误是否是真正的错哗宏误，书写的测试步骤是否准确，可以重复。

每次对错误的处理都要保留处理信息，包括处理姓名，时间，处理方法，处理意见，Bug状态。

拒绝或延期错误不能由程序员单方面决定，应该由项目经理，测试经理和设计经理共同决定。

错误修复后必须由报告错误的测试人员验证后，确认已经修复，才能关闭错误。

加强测试人员与程序员的交流，对于某些不能重复的错误，可以请测试人员补充详细的测试步骤和方法，以及必要的测试用例

笔者搭建过比如JIRA这样的传统项目管理工具，虽然一旦搭建完成，使用起来，无脑且不易出错，但是搭建过程繁琐，学习成本很高，而且需要一定的技术功底和项目管理知识，非常不讨人喜欢。而互联网时代，越来越讲究扁平化管理，小团队化，生物型组织，用来进行严格流程管理的传统项目管理工具已经越来越不适用。

实际上Worktile应该算一个团队协作软件，因为他在设计思路上就不是为了管理而是协作，Worktile没有复杂的流程控制，也没有复杂的权限管理，功能简单，使用灵活，非常重视用户体验。而且Worktile也没有仅仅将目标用户锁定于小团队，他的每个成员都可以创建属于自己的项目，光这一点，就为生物型组织的大公司提供了无限可能。

Worktile可以通过发送网址链接邀请团队成员，只要把链接通过QQ、微信、邮件组等方式分享给团队成员，他们即可点击链接直接加入你的团队。

成员加入后要记得关闭链接防止链接泄露。

创建团队项目，命名为“BUG管理”，在项目中，默认有“要做”，“在做”，“已做”3个任务列表，任务列表其实类似于项目管理中的一个工作流状态，这里我们重命名为“未解决”，“正在解决”，“已解决，待测试”。

在“未解决”任务列表点击“新建任务”，创建新任务需要填写以下内容：

1.主题。

2.分配对象:如果知道是哪个程序的功能可直接指定该程序；如果不知道，可以分配给程序负责人，再由程序负责人分配给相应程序，

3.设置标签:对于BUG，我们只设3级，高优先级的bug添加红色标签，中优先级的bug添加黄色标签，低优先级的bug不添加标签（因为可以自定义标签，除了红黄两色禁止修改之外，可以自由添加其他标签，后续商定）。

4.保存后，点击该任务，选择“添加关注”，选择自己。

相应程序在“工作台”，“我的任务”中可以进行筛选。对应一个刚刚发起的BUG有以下流程：

1.如果是无效BUG：点击任务，添加评论（说明无效理由），移动到“已解决，待测试”任务列表，分配列表中添加BUG发起者。

2.如果是有效BUG：当程序接受BUG后，将该BUG移动到“正在解决”任务列表。并“设置解决日期”。

注：在任务列表中可以直接拖动到其他列表，如图所示：

3.当程序解决好BUG后，再将该任务移动到“已解决，待测试”列表中，分配列表中添加BUG发起者。

BUG发起者，要及时查看项目状态，在项目列表右上侧，任务筛选，可以看到相应的任务变化。

当一个BUG被移动到“已解决，待测试”列表中时，BUG发起者的“待完成”下就会出现，这时候BUG发起者去测试BUG是否解决。

1.如果BUG已经解决：点击“主题”前面的方框，该任务会被自动归档（需要管理员进行设置），BUG流程结束。如果以后该BUG重现，可以到“项目设置”里选“查看归档项目”，找到任务重新“激活”

2.如果BUG没有解决：则再移动到“未解决”列表中。

---