浅谈质量管理 - 有关JIRA的那些事儿

2017-09-05 12:00:00 侯凤迎 点融黑帮

软件工程中的质量管理是对流程的管理,当产品交付过程被不断的重复,其性能会趋于稳定,质量得到保证。而在重复的过程中,监测产品指标,优化流程即为质量管理所关心的。

 

在项目中,对产品质量的管理有两个维度:评价改进。其中质量评价以准确的统计数据为基础,流程改进以操作规范为目标。


质量评价基础指标:

  • 每个迭代任务输出量是否稳定

  • 每个迭代有效缺陷量是否稳定


流程改进关注点:

  • 产品线上交付成功率

  • 线上问题修复



本文结合目前的项目实践,描述一下质量管理在JIRA中的一些技巧。

 

项目背景:该项目是Web端的客户管理系统,采用SCRUM流程敏捷方法使用JIRA作为需求管理和缺陷跟踪工具



1从缺陷的基本属性说起




  • Priority/Severity:ISSUE的优先级别和严重级别,通常作为产品发布的一个指标。

  • EnvISSUE的发生环境,任何线上问题都是流程改进的推动者。

  • SprintISSUE的排期点,测试准入条件之一,属于本周迭代的Sprint才予以跟进。

  • Issue Found SprintISSUE的发现版本,通常用来跟踪每个迭代新缺陷量。

  • Assignee:ISSUE的当前所属人,测试准入条件之一,只有当前所属人为测试时,测试人员才予以跟进。

  • Resolution:ISSUE的处理方式,可以作为有效缺陷无效缺陷和三方缺陷等统计指标的数据源。

注:

1Priority/Severity字段的使用需要整理项目的核心功能点,作为定义P0S0级别的标准。

2、有一个共识的规范的测试准入条件是有必要的。

3、有必要定义一个共识的Sprint跟踪未排期需求,目前JIRA中在Backlog中体现。

 


2总结JIRA的操作规范


1、ISSUE的创建

项目中的任何计算人力的的事务均需要有ISSUE跟踪,无ISSUE跟踪的事项不予跟进。


2.、ISSUE的关闭

QA参与的ISSUE,统一由QA进行关闭,避免QA遗漏验证点。


3、ISSUE的备注

JIRA的状态变更需要跟进备注信息。

开发方:任务类的ISSUE,需要描述实现方式以及影响范围,缺陷类的ISSUE,需要描述问题产生原因。

测试方:需要描述验证点,验证数据以及验收结果。


4、ISSUE当前所属人

一个ISSUE如果需要其他人跟进,首先Assign给某某(此处作为某某是否需要跟进的依据),并在备注中提供对方需要的信息。

项目中的协作者均可以通过当前所属人作为自己的任务范围,不在此范围内的工作有理由不予跟进。


5、ISSUE的修复版本

开发方需要在结束一个task或修复一个bug时需要完善该字段。避免开发测试版本不同步问题。


6、Sprint变更

当一个需求延期,需修改该需求Sprint字段,并关联到需求变更Epic”,备注中描述需求变更原因,@干系人。


7、特别事项类

配置类:每个迭代需要创建一个配置类ISSUE,用来跟踪本次迭代的配置变更。

需求变更类:每个项目应有一个Epic 统一跟踪需求变更事项。

线上问题类:每个项目应有一个Epic 统一跟踪线上问题。

目前,需求变更和线上问题是有Epic作为跟踪的,配置变更记录放在Wiki中和LCRM统一跟踪。


有了长期的数据,才可以进一步完善总结。下图是线上问题Epic下的部分关联数据。

 

JIRA的那些事儿到此结束了,有一个共识的基础的操作规范,可以营造更轻松有效的工作环境。