能够预防缺陷的敏捷测试如何进行缺陷管理

发表于:2023-1-09 09:39

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:Connie尧尧    来源:CSDN

分享:
  1 引言
  敏捷测试原则中有一条是:预防缺陷,而不是关注缺陷的数量。敏捷团队中是整个团队为质量负责,团队追求的是整个产品质量的提升,而非传统的开发人员追求零缺陷,测试人员追求找到更多的缺陷。在敏捷开发中,虽然我们采取各种措施预防缺陷的发生,例如精准的自动化测试、代码检视、故事卡验收等等,但是并不能保证没有缺陷发生,一个零缺陷的产品也不现实。既然无法完全阻止缺陷的出现,那如何管理发生的缺陷,如何利用已有缺陷来指导质量内建过程,是我们需要考虑的。
  本文以博主在实际项目中的经验,讲述缺陷的记录、流转和分析,每个模块的内容会分别讲述迭代内缺陷和生产缺陷的管理。
  2 缺陷记录
  2.1 哪些缺陷该被记录?
  在记录缺陷前,我们要理清楚我们需要记录的缺陷有哪些,是不是每一个缺陷都应该被记录。敏捷项目是以迭代为交付周期,一个迭代周期从两周到一个月甚至2个月不等,每个迭代都会有新功能的上线。一般来讲,缺陷分为两类:一类是迭代内缺陷,即在迭代新功能开发时,故事验收或测试阶段发生的缺陷;另一类则是生产缺陷,我们是允许生产缺陷的存在的,但前提是缺陷影响范围可控,或者可以在用户发现前发现缺陷(测试右移),并且要具备快速修复或者回滚的能力。
  对于迭代内缺陷,一般发现阶段分为故事卡验收阶段,测试阶段,回归测试阶段。对于故事卡验收阶段发现的缺陷,是否需要记录可视情况而定,一般而言,可以不需要记录,因为此时故事卡仍在开发阶段,开发同学仍然工作在这张卡上,其上下文充足,修复缺陷成本较低,可以直接备注在卡片上,等下一次故事卡验收的时候再验证是否修复。对于测试阶段和回归测试阶段的缺陷,建议记录下来,因为此时开发这张卡片功能的开发同学已工作在其他卡片上,没有办法及时修复该缺陷,或者修复该缺陷的或许是其他开发人员,那么就需要将缺陷记录下来便于跟踪。
  2.2 工具
  在选择缺陷记录工具的时候,要考虑以下几点:
  1. 该工具是否支持协同工作?
  缺陷和故事卡一样重要,是各个角色都需要关心的事情,即意味着各个角色都需要能够查看、操作缺陷记录工具,所以缺陷记录工具需要支持协同工作。
  2. 该工具是否容易学习?
  基于第一点,团队成员均需要操作该工具,不管是否有技术背景,所以该工具一定是需要学习成本较低的。
  3. 该工具是否易于跟踪缺陷状态?
  缺陷和故事卡一样,是存在流转状态的,也会有不同的人员工作在该缺陷上(开发人员、测试人员),所以记录工具最好具有状态流转标识,当然你也可以手动记录其状态,但能让工具帮你做的事情为什么不利用工具呢?
  4. 该工具是否清晰记录缺陷?
  下一小节会讲到缺陷记录的要素,选择的工具需要能清晰表达这些要素。
  5. 该工具是否便于统计?
  缺陷管理中很重要的一部分是缺陷分析,缺陷分析当然是基于数据的,这些数据可以手动收集,如果工具能自动帮你做一些统计那是最好的。
  所选择的工具不一定需要具备以上提到的所有特征,但是支持协同工作和清晰记录缺陷是必不可少的,其余特征可根据项目情况而定。
  博主所在的项目选择的工具是jira,jira是一款协同办公软件,在敏捷项目中通常被用来记录故事卡。它支持协同办公,而且我们项目也使用jira记录故事卡,我们在故事卡的泳道下面新建了一个跟踪缺陷卡的泳道,一个缺陷记录一张卡片,这样大家就可以像操作故事卡一样操作缺陷卡。它也支持添加自定义标签的,标注卡片优先级,添加附件,充分满足缺陷关联的内容。它也支持导出卡片数据,对之后的缺陷分析十分有帮助。博主也推荐使用trello,和jira的功能大同小异,当然在线wps的excel也是不错的选择。
  使用jira记录缺陷,主要是为了便于查看缺陷状态,但会随着迭代的完成,缺陷卡片会被归档,每张卡片也是独立的,不利于集中查看和查询。这样的流转方式对迭代内缺陷是没有问题的,因为迭代内缺陷一旦修复,后续基本不会有人再去查看关注。但对生产缺陷却不一样,每一个生产缺陷都应该被认真对待分析,我们可以将其统一记录在某个地方,用于之后回顾。博主项目组的做法是将生产缺陷统一记录在confluence,便于集中查看。
  2.3 模版
  记录缺陷有两个原则:
  1. 描述完整,清晰易读懂
  记录的缺陷卡和故事卡一样,需要给团队成员看,所以缺陷卡需要描述完整清晰。
  2. 规范化,便于缺陷分析
  分析统计总是基于规划的数据结构,所以在记录缺陷的时候就需要考虑之后缺陷分析需要什么,以此去规范户记录缺陷。
  以博主的项目为例,我们记录缺陷的模版主要有以下要素:
  ·标题
  简述缺陷内容,清晰明了。
  ·描述
  缺陷发生环境(DEV/ST/UAT/PRD),相关测试数据(用户名/订单号等),复现步骤,期望结果,实际结果,备注(截图、日志等)。
  ·优先级
  在卡片上(jira/trello)备注缺陷的优先级,可以是高、中、低,可以自定义。
  ·标签
  便于之后的缺陷分析,可以给缺陷打上标签。以博主项目为例,针对生产缺陷,会标注以下标签:所属功能模块(根据系统自定义)、可识别阶段(需求阶段/开发阶段/测试阶段/难以识别)、缺陷类型(功能/性能/安全)、影响范围(大/中/小)。
  3 缺陷流转
  每个缺陷也应该像故事卡一样,有它完整的生命周期,本节以博主项目组为例详解迭代内缺陷和生产缺陷的流转过程,当然每个组情况不一样,读者可视自身项目组情况而定。
  3.1 迭代内缺陷流转过程
  上文讲到,迭代内缺陷和故事卡记录在同一jira面板的不同泳道,那么缺陷卡的生命周期和故事卡自然是一样的,如下图所示:
  针对迭代内的缺陷应该在什么时候修复,我们的处理原则有以下几点:
  1. 如果是阻碍开发/测试进度的缺陷,应该被立即修复;
  2. 如果是本迭代必须交付的功能相关缺陷,且修复成本高或影响范围大的缺陷,应该被立即修复;
  3. 如果是本迭代必须交付的功能相关缺陷,但修复成本或影响范围较小的缺陷,留到迭代后期修复。
  3.2 生产缺陷流转过程
  生产缺陷总是值得被引起重视的,我们对其处理流程如下图所示:
  4 缺陷分析
  敏捷测试原则说我们应该预防缺陷而不是关注缺陷的数量,所以对于缺陷分析,我们的出发点是:对已发生的缺陷进行深入分析,从中找到问题所在,以达到预防缺陷的目的。
  4.1 分析周期
  迭代内缺陷的数量比较多,而且一般大多数都是开发逻辑错误造成的,一般而言分析价值不大。如果每个迭代平稳运行,缺陷数量平稳,建议不用特意分析,毕竟分析缺陷是耗时的。如果某个迭代明显感觉缺陷数量增长,可以针对性对本迭代缺陷进行分析。当然,如果你有充分的时间,可以将缺陷分析作为一项日常工作。而对于生产缺陷,每一个都值得被重视。3.2节讲述的流转过程,其中我们就已经对其进行分析了,分析其问题出在哪儿,然后补充相应的测试。如果想要对生产缺陷进行归类、趋势分析,那么就需要有一定的数据才可以,而生产缺陷不常有。所以其分析周期建议是1个月,或者3个月,甚至6个月,视各个项目组的情况而定。
  4.2 分析角度
  我们项目组常用的分析角度有以下几个,不同的项目侧重点会有所不同。
  (1)缺陷根因
  可以将缺陷一一分析后进行归类,根因可以分类为:需求缺失或者不清晰、技术方案设计问题、代码逻辑错误、测试未覆盖、环境相关(硬件、软件、第三方等)。分类后如果某一类问题较突出,则可以针对性产出改进事项。
  (2)缺陷发现阶段
  缺陷发现阶段可以归类为:故事验收阶段、功能测试阶段、回归测试阶段。我们知道缺陷越早发现修复成本越低,如果分析后发现某一阶段出现的缺陷较多,应该去反思是哪个环节错了,我们是否可以更早的暴露缺陷。
  (3)缺陷所属功能模块
  功能所属模块根据系统不同而不同,这一类分析帮助我们思考,某一块存在的缺陷多是因为存在技术债还是测试覆盖不够,可以帮助我们改进质量策略。
  (4)缺陷数量趋势
  如果可以,对于迭代内缺陷可以维护一份数量趋势图,就不需要我们靠直觉去感受哪个迭代缺陷多,而是有真实的数据作为依据,更具说服力。对于生产缺陷,建议可以维护一份数量趋势图,因为生产缺陷数量走势也是反应我们产品质量的一个重要维度。
  (5)缺陷可识别阶段
  这一分类主要针对生产缺陷,缺陷可识别阶段可以归类为:需求分析阶段、开发阶段、测试阶段、发布阶段,难以识别。这样分类的初衷不在于归过于某一角色,某一人,而是为了进一步分析是哪一阶段的实践有缺失,需要进一步改善。
  (6)缺陷类型
  缺陷类型可以归类为:功能缺陷,性能缺陷,安全缺陷。敏捷项目QA需要关注产品各个方面的质量,包括性能、安全等,将缺陷类型划分清楚,可以指导我们补充我们薄弱的地方。
  4.3 分析工具
  数据有了,就需要将数据可视化出来,便于分析,便于展示给团队。博主曾使用过的可视化工具有:
  ·jira
  jira根据卡片自动生成图标,饼图、趋势图都可以,但好像只有企业定制版才可以。
  ·ppt
  将jira数据导出,然后导入ppt画图。只要记录的缺陷卡片规范,也不是很费时,但没办法展示趋势,只能展示导出阶段的数据。
  ·tableau
  可以画各种图,对于展示趋势图也很方便,但是一款商业工具,而且上手成本并不低,它主要的功能是进行数据分析,画图只是它的九牛一毛,用它做缺陷分析有点大材小用的意思了。

      本文内容不用于商业目的,如涉及知识产权问题,请权利人联系51Testing小编(021-64471599-8017),我们将立即处理
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号