按照格式上报一下缺陷就叫缺陷管理吗？没有连招怎么行？
问题痛点
软件研发测试过程中的缺陷，是一个特殊的产物，它不会随着研发模型的改变而变化，从一年一发布的瀑布模型，到一周一发布的 DevOps，“缺陷” 无法简化，盲目的追求简化，只不过是掩藏技术债的行为。
- 理想状态下：一提一修复，验完即上线，缺陷永不见
- 实际情况中：知否知否，缺陷修复，又岂只在朝朝暮暮
缺陷流技能乃经验中之精品，无不闻之点头，听之惊叹。
那些我们曾经的痛：
- 修复未修复，傻傻分不清楚
- 踩坑再翻车，打脸没商量
- 敏捷与流程，何以兼得
解决方案
用 JIRA 的好处在于能实现任何想实现的效果，难点在于需要一个很懂业务的 Atlassian 工具人。这里我们以 JIRA 生态为例，推荐解决方案。
JIRA 组合拳：工作流 + 字段配置 + 界面 + Automation for JIRA ，科学理论配合自动化，配置不简单，使用不复杂。
1. 缺陷流 （工作流）
先看工作流实图：
乍一看繁琐且复杂，但实际上对于每一次的状态变更只有两个选择：同意 vs 不同意。
所有状态贯穿缺陷的完整生命周期，直到最终被验收。
每个状态清晰的表现了缺陷所处的阶段及进展，如：修复中 -> 已修复 -> 已验证
2. 专配专用 （字段配置）
信息不对称在工作交流中带来的弊端大家多少有感触，对于缺陷类型的 JIRA 问题，如果也是用常规字段方案明显是不够的，至少新增以下字段，并且添加说明配上默认值，保证大家认知统一且信息齐全。
3. 不同阶段不同界面 （界面）
当然，不能让使用者靠脑力去记忆上报缺陷的时候要填哪些信息，应该是选择不同的问题类型，就展示对应的界面。
除此之外，在状态发生变化的时候，也应该弹出需要的界面，过滤掉那些不需要在当前阶段再去考虑的多余信息，只填必要项。
4. 自动化协助 （Automation for JIRA）
JIRA 问题的标签栏是个随意性较高的字段，但通常我们仍旧有一些约定好的格式和值，比如缺陷的最终状态总会变为验证，那么它到底是个什么结果，我们期望加上一些标签作为标记，以方便一眼就能识别它，这些操作其实是有规律的，所以我们完全可以解放人力，通过自动化手段去完成，还杜绝了标签添加错误的情况。除此之外，还有验证即需要改变解决结果为完成，缺陷重现需要把解决结果改为进行中等等。
总结一下
管理是一系列的组合连招，仅仅会用个工具很难达到效果，这里面包含了很多业务经验，而质量管理之缺陷流，是比较容易落地的一种流派，还可以通过该方法收集一些数据，对质量管理可以起到一些意想不到的效果。
