一般缺陷的生命周期必然要经历 提交-打开-解决-关闭 三个阶段，但问题是，一些公司对诸如ClearQuest的缺陷管理工具进行了一些定制和二次开发，制定了一套严格的流程，缺陷的生命周期变得更加复杂化了。但是在执行的时候，开发人员往往仅在缺陷提交后，匆匆修正了缺陷，然后置为解决状态，等待测试人员来关闭它。因此，这些情况下，缺陷状态的很多阶段都显得有些多余。但是有人认为，在缺陷生命周期阶段多的情况下，可以让关注该缺陷的人员更准确地了解该缺陷目前的状态。怎样化解矛盾呢？事实上，给缺陷定义过多的生命周期阶段是不必要的。开发人员不愿意在解决缺陷的过程中不断的更新该缺陷的状态，另外，有些缺陷实际上很快就能解决的，过多的步骤反而降低效率，浪费时间。因此，从统计和了解缺陷数量和状态，这样的做法是好的。但是，从现实的角度来看，在实施的过程中缺乏可操作性。