问分类缺陷以确定根本原因

EN

有许多不同的方法来获得一个根本原因的清单。而根本原因因我们想要做的accomplish而有所不同。在我的上一家公司，我们的根本原因分析的目的是找出错误的来源( SDLC的阶段是引入的缺陷)。下面是我们的一些分类：

1. 需求问题(模糊/缺失/不明确的需求)
2. 设计问题
3. 编码问题
4. 测试问题
5. 环境问题
6. 部署问题
7. 超出范围(不是需求的一部分)。

注意:获得Testing Issues是一个棘手的部分，因为大部分内容都要经过测试。但是，把所有的东西都放到测试小组上，就会达到这个目的。我们还希望改进在软件被推送给测试人员之前存在的所有检查点。

我建议从没有名单开始。

由于缺陷类别的定义在每个开发中、每个上下文中以及与每个QA工程师都有很大的不同。如果我们在这里讨论缺陷范畴，我们需要对每种缺陷的定义再进行一次长时间的讨论。

立即开始通过会议。当你讨论的根本原因或领域，以改善每一个缺陷，我认为你应该提出正确的类别，特别是你的上下文。它还允许您的团队一起学习每个类别。从500个缺陷中得出的类别应该为您的上下文提供相当好的覆盖率类别。

考虑到目前的技术模式，现在的应用分为以下几个领域：

1. 前端
   • UI化妆品
   • UI设计
   • UI性能
   • UI要求小姐

2. 基础设施
   • CI/CD问题
   • 标度问题
   • 码头集装箱问题
   • 性能问题

3. 后端
   • API函数问题
   • API身份验证问题
   • 性能问题
   • API要求小姐

4. E2E
   • 测试覆盖问题
   • 验证问题
   • 测试设计问题

这500个缺陷可以在上面进行分类，以便与优先级一起规划工件的发布。