作为Gatekeeper，请守好交付质量关口 （Quality Gate）
质量保证（QA）包括三个不同的领域：
- 分析质量保证：根据标准检查软件产品的质量。如果软件产品不能达到特定的期望值，将采取适当的措施（很可能是返工）。
- 建设性质量保证：建设性质量保证包括为预先构建无错误软件提供帮助的所有方法。
- 组织质量保证：组织质量保证的任务是提供一个可以建立质量保证的环境。组织质量保证包括质量管理组织、培训课程和开发过程。
许多软件公司通过质量关口（Quality Gate，有的翻译为质量门）来分析其软件产品的质量并及时采取行动。
质量关口（Quality Gate）
质量关口（Quality Gate）是项目中的重要里程碑和决策点。
在每一个质量关口上，产品都根据预先确定的、以质量为中心的标准进行评估。在满足这些标准的基础上，看门人（Gatekeeper，通常是QA）决定一个项目是否可以进行。因此，项目的质量状况可以向管理层揭示，并及时采取行动。
质量门通常用于某些领域，例如汽车开发或工业品的批量生产。在软件开发领域，质量门在过去的几年中开始不断被使用。
软件项目使用质量关口的策略（Quality Gate Policy）
软件公司可以通过两种方式使用质量门（我们将其称为策略）：
- 质量关口作为质量指南：相同的质量关口（和标准）适用于所有项目，从而在所有这些项目中产生可比且至少相等的最低质量水平。
- 质量门作为一种灵活的质量策略：在每一个项目中应用一个合适的质量门过程，以精确地满足项目的需要。
质量门参考过程封装了特殊的结构、活动、方法、角色和文档，软件公司可以单独实现这些结构、活动、方法、角色和文档，以满足其质量和业务目标。这种质量门参考过程，可以量身定做，以满足特殊项目的需要。行动的结果是一个质量门过程，包含一组标准和一组质量门。
软件公司如何实现质量门（Quality Gate）概念并不重要，因为实际实现取决于公司的规模和领域。
Scrum 开发常见的Quality Gate
在Scrum开发中，团队或者QA通常会设定一些开发质量检查标准，下面举一个例子：
某一个开发团队和QA协商后，根据公司的质量管理策略，设定的Quality Gate如下表格所示。
但是在实际Sprint迭代中，团队总是按照低水平交付，甚至某些指标的度量结果都达不到低水平的要求。
| Items | 低水平标准值 | 高水平标准值 | 说明 |
| Sprint中 Unit Test Coverage | 50%~60% |
>85 |
使用JUnit或者Sonar检测结果 |
| Sprint Test 测试用例执行通过率 | >90% |
= 100% |
JIRA XRay统计数据或者Excel文件手工管理 |
| Sprint Test 缺陷率 | < 10% | < 5% | 根据缺陷率计算公式实施 |
| Sprint Test 缺陷修复率 | >95% |
= 100% |
JIRA XRay统计数据或者Excel文件手工管理 |
| Sprint中 Code Inspection | Bug数为0 Vulnerabilities少量存在 |
Bug = 0 Vulnerabilities=0 |
检查工具：Sonar、FindBugs等 |
| Sprint中 User Story开发完成率 与Sprint Planning对比无延期的User Story |
> 90% | = 100% | 管理工具：JIRA或者Redmine |
| User Story对于产品需求的覆盖率 | > 90% | = 100% | 管理工具：JIRA或者Redmine |
| Sprint 规定的必要交付物 按照预设标准检查 [文档] |
交付物数量基本满足 交付物内容评审后基本通过 |
交付物数量正确 交付物内容评审后符合要求[达到目标] |
文档管理工具： 文件服务器SVN JIRA或者Confluence |
Gatekeeper 为什么不能守好交付质量关口
Sprint开发中，QA进行定期的质量检查，结果发现Scrum团队的开发质量不能满足Quality Gate的要求，大多数度量指标甚至连低水平都不能满足。但是产品交付期已经到了，产品必须在Deadline之前要进行Release。
这个时候整个组织或者团队开始进入“黑色地狱周”，不停的加班，夜以继日的工作。各种管理人员开始关注产品开发质量，各种会议，报告不断。最后实在没有办法时，只能有条件通过产品质量检测，实行上线发布。然后在实施紧急Hot Fixing。
QA是不是需要和管理者、干系人、Scrum团队等一起来分析为什么产品开发质量不能满足要求？
原因到底出现在哪里？从五个维度进行分析：结构、活动、方法、角色和文档。
- 质量意识薄弱，检查不及时、不到位。
- QA无力推动Scrum团队及时做出必要的改善，话语权不够（在组织中的地位不高，不能得到管理层的支持）
- 组织的开发过程本身存在流程和活动的缺陷，QA没有能够及时发现。
- ……
但是无论怎样，QA作为Gatekeeper，当产品交付产生质量问题时，肯定是存在责任的。为什么不能守好交付质量关口呢？
100个人会有100中说法。QA自身需要首先做出有效的改善
- 做到“两个坚持”：坚持原则，坚持标准
- 做到“三不怕”：不怕问题，不掩盖问题，不怕在工作中“得罪人”
- 按照组织级的Quality Management Plan按时实施Quality Check活动
- 不断改善组织的开发过程和Quality Gate，使其符合组织的实际情况（标准不能降低，要找到达到标准的办法）
- 诊断开发过程，找到问题，逐一提出改善意见
- 及时和相关管理者、干系人、项目团队进行有效的沟通，积极解决问题
- 定期发布质量ISSUE报告
- 参加Scrum团队的Retrospective活动，收集反馈质量管理意见和建议
- 取得管理层的有力支持
- 通过质量改善活动，分析效果，及时形成报告并共享给管理层和相关干系人
