你的项目已经发布了！也许这是第一个版本迭代，或者它可能是第10个。然而，作为一个细心的软件工程师，你的工作还没有结束。现在是时候事后分析。所以，你有你的标准：“什么是对的”， “什么是错的”的定义，但你认为你仍可能会错过一些将有助于你项目下一阶段的重要的信息。请尝试一下错误分析。

　　错误分析是什么？

　　你的bug数据库，是那些有用的信息来源之一。一种形式的错误分析是从bug数据库中取数据和“嘎吱嘎吱”的分类（有些人会叫他们区域或类型）的错误，总结出数量最多的错误的原因。这样的想法是要了解这个问题，以减少下一阶段的项目实施过程这些类型的错误。

　　正式或非正式与强化

　　你首先需要确定你想要有多彻底的分析。如下的案例中，错误分析是一种较不密集的或非正式的审查。

　　在这个案例，我们审查了1/4的bug数据库中随机抽取的一个样本。一个更正式的审查将包括审查更多的数据。只有一个QA团队的人在非正式的情况下进行了分析。如果要一个更加正式的审查，你可以包括外部资源其他的审查人员，如一个独立的听众。

　　一个简单的方法

　　对于我们的案例， QA人员审查每一个错误的样品，把它归入下列类别之一：

　　O 需求 - 通常是不存在的，或不明确的需求造成的错误

　　O 代码 - 编码缺陷，代码集成缺陷

　　O 测试 - 这包括不正确地记录的错误，不明确的功能（这也可能是一个需求缺陷） ，

　　不能重现的问题

　　Ø 建议 - 所有新的或改进的功能的建议和要求

　　您可能有不同的分类系统，但大多数问题会以类似的方法分解。

　　一个简单的总结

　　初步调查结果是，开发团队没有执行代码审查的所有功能，一些开发人员忽略或限制了单元测试。下一个项目阶段的范围包括再次交付的单元测试和代码审查。

　　如果有更多的需求错误，那么团队会知道改进下一阶段或项目的需求管理流程。

　　如果发现了更多的测试错误，那么团队就必须确定它是否得到它必须的文档和支持；或是团队成员只是犯太多的错误，需要进一步培训；或者是测试团队的组成或领导必须有改变。

　　大量的建议性的错误可能意味着：该项目并没有真正满足顾客的需求。在这种情况下，你应该向你的客户再次确认这个应用程序的范围和功能。