测试人员应该跟踪一个BUG的整个生命周期，从open到closed的所有状态。通常一个bug的状态有：
New 新发现的bug，但是未经评审还没有分配给开发人员进行修正
OPEN 确认是bug 并且确认需要修改，指派给开发人员修改
FIXED 开发修改后更新bug的标识，有待测试人员进行回归测试
REJECTED 认为不是bug被决绝修改
Delay 如果认为暂时不用修改，或者暂时不能修改的，延后再说
Closed 回归测试通过后，即可关闭bug
Reopen 后期有验证bug仍然存在，则需要重新打开这个bug
注意每个项目团队的要求和实际做法不一，需要结合实际的开发流程和协作来使用。
Bug的跟踪以及状态变更应该遵循一些基本的要求
测试人员对每一个缺陷的修改必须重新获取一个包含修改后的代码的新版本进行回归测试，确保相同的问题不会再现，才能关闭问题
对于拒绝的问题和延迟修改的问题，需要经过包括测试人员、开发人员、用户等角色代表的评审。
再与开发沟通一个bug时应让开发了解到bug对用户可能造成的困扰，这样才能促使开发人员更加积极地、高质量的修改bug
在表述一个bug时应该始终抱着客观公正的态度才描述。
BUG评审需要注意的问题
缺陷的评审应该包含两个方面：
1如何处理bug
2分析缺陷产生的原因 找出预防的措施
1如何处理bug
这一方面评审需要项目组上开发代表、测试代表、产品经理代表等各个方面参加
测试代表主要从bug的具体表现、严重程度等方面提供信息，提出修改bug的意见
开发从修改缺陷的难度和预期以及风险出发，考虑修改缺陷的成本和付出的代价，可能造成的影响，如果决定修改，还要讨论修改的初步方案。
产品代表从产品的整体规划，用户要求等方面对缺陷的修改必要性、缺陷修改的时间和版本提出自己的意见。
2分析缺陷产生的原因，找出预措施
评审时还要分析bug产生的原因，尤其时重复出现的bug，并且制定预防措施和彻底解决的办法确保同类bug不再出现。注意有的bug可能是由于编码规范导致的，这是必须严格要求开发人员按照公司编码规范和编程方式执行编码工作。