跟踪bug报告类型
为了帮助我们更好的跟踪bug,分析bug，为以后的项目总结经验,我们在TD里增加了QA Tracking，并定义了4个选择值:
Ø New Discovery: 表示这个bug是新发现的，这就意味着这个bug一直存在，但是QA在之前的测试中没有发现
Ø New Feature introduction:表示这个bug是因为新功能的改动而引起的
Ø Regression：表示这个bug不存在以前的测试版本或build,但是存在当前测试的版本或build
Ø Undefined: 如果我们不能确定是否是上面的3种情况的，请选择这项，但是我们要尽量少选这个.
Bug状态
只有Closed才是bug的最后状态,当前我们有7种状态，每种状态的意思为:
Ø New:这是一个bug的初始状态，我们所有的新发现的bug，其状态都是New
Ø Open:项目负责人或者资深的人员review所有的New bug后，认为bug是有效的话，将bug的状态从New改为Open.
Ø Fixed:开发人员把相应的代码修正后，并通过了单元测试，将对应的bug状态改为Fixed,并加一定的注释.
Ø Closed: QA人员拿到新的测试版本后，验证Fixed bug,确实不存在的，把bug的状态改为Closed.并要加注释
Ø Rejected:开发人员认为这个Bug是无效的，将会把bug的状态改为Rejected,这种状态不是最后的状态，QA人员要仔细的分析，如果真的是无效的，那么需要将其状态改为closed;否则改为Reopen
Ø Reopen: QA验证Fixed/Rejected bugs后，bug仍然存在或者有效的，将其状态改为Reopen
Ø Deferred:这是新增加的一种状态，其目的避免开发人员将一些设计的问题改为Rejected状态；当前，一些设计需求已经确定，但是一些设计确实存在不合理的地方，而因为项目周期的原因，当前项目无法做需求上的改动，所以只有在下个版本了做Fixed,我们将会把这些bug放到下个版本里fixed.
Bug fixed/closed/Rejected/Deferred的注释
为了保证QA能够精确的估算因为fixed bug而要测试的范围，开发在fixed bug时候，必须增加注释，包括解决方案，修改的文件名,同样，开发在原代码中，也必须增加一个注释，表明这个代码改动的原因(fixed bug还是新的需求). QA验证一个fixed bug后，无论是re-open还是closed，都要加个注释，表明在那个版本里或者build里验证的.
同样，开发人员在把一个bug的状态改为Rejected or Deferred的时候，也必须加足够的说明，如果没有任何的说明，QA将会直接的把这些bug改为Reopen状态.
