质量保证(QA)包括三个不同的领域:
许多软件公司通过质量关口(Quality Gate,有的翻译为质量门)来分析其软件产品的质量并及时采取行动。
质量关口(Quality Gate)是项目中的重要里程碑和决策点。
在每一个质量关口上,产品都根据预先确定的、以质量为中心的标准进行评估。在满足这些标准的基础上,看门人(Gatekeeper,通常是QA)决定一个项目是否可以进行。因此,项目的质量状况可以向管理层揭示,并及时采取行动。
质量门通常用于某些领域,例如汽车开发或工业品的批量生产。在软件开发领域,质量门在过去的几年中开始不断被使用。
软件公司可以通过两种方式使用质量门(我们将其称为策略):
质量门参考过程封装了特殊的结构、活动、方法、角色和文档,软件公司可以单独实现这些结构、活动、方法、角色和文档,以满足其质量和业务目标。这种质量门参考过程,可以量身定做,以满足特殊项目的需要。行动的结果是一个质量门过程,包含一组标准和一组质量门。
软件公司如何实现质量门(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 |
Sprint开发中,QA进行定期的质量检查,结果发现Scrum团队的开发质量不能满足Quality Gate的要求,大多数度量指标甚至连低水平都不能满足。但是产品交付期已经到了,产品必须在Deadline之前要进行Release。
这个时候整个组织或者团队开始进入“黑色地狱周”,不停的加班,夜以继日的工作。各种管理人员开始关注产品开发质量,各种会议,报告不断。最后实在没有办法时,只能有条件通过产品质量检测,实行上线发布。然后在实施紧急Hot Fixing。
QA是不是需要和管理者、干系人、Scrum团队等一起来分析为什么产品开发质量不能满足要求?
原因到底出现在哪里?从五个维度进行分析:结构、活动、方法、角色和文档。
但是无论怎样,QA作为Gatekeeper,当产品交付产生质量问题时,肯定是存在责任的。为什么不能守好交付质量关口呢?
100个人会有100中说法。QA自身需要首先做出有效的改善